[tor-dev] REMINDER: Buoyant Otter outreach, training, documentation in an hour.
Tor psyops group, We'll be meeting in #tor-dev in just under an hour to scheme, plan, and otherwise prepare out ongoing outreach, training, and documentation efforts. See y'all in an hour. -Tom ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Torsocks 2.x issue - Need eyes on that
Hi everyone, I stumble upon an issue when testing torsocks[1] with firefox. I'm still wondering how this can be fixed thus I need more eyes on this :). The issue is that torsocks gets into a deadlock during the initialization phase within the libc. Here it is. This new torsocks version hijacks the syscall symbol (syscall(2)) in order to intercept applications that decides to do some network operations with that interface. To do that, the torsocks library constructor (executed before the application main()) lookup the original symbol in the libc (dlopen(3)) and is used for unhandled syscall values (for instance open(2)). Now the issue was detected with firefox which uses a custom malloc hook meaning that it handles its own memory allocation. This hook uses mmap() that firefox redefines to be a direct syscall(__NR_mmap, ...) and remember that this symbol is hijacked by torsocks. Torsocks constructor calls dlsym() to get the original libc syscall symbol. This call locks a loading lock inside the libc: dlfcn/dlsym.c +68: __rtld_lock_lock_recursive (GL(dl_load_lock)); Just after, dlerror_run is called which does a calloc() which then calls the firefox malloc hook and calls syscall() for mmap that torsocks hijacks. In torsocks, syscall() make a check on the original libc syscall pointer to see if it's NULL or not and if NULL, tries to look it up with dlsym(). And there you have the deadlock. dlsym -- LOCK -- dlerror_run -- calloc -- syscall() -- dlsym() -- dlerror_run -- DEADLOCK. It's a bit of a catch 22 because torsocks is basically looking for the libc syscall symbol but then it gets call inside that lookup code path... To be honest, I am not sure what's the right fix here or if there is any way to lookup the symbol in a special way that would help here. Any idea or questions are VERY welcome :). Hope this explanation is clear enough, this is a not that trivial issue. Cheers! David [1] https://github.com/dgoulet/torsocks.git signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Torsocks 2.x issue - Need eyes on that
On 29 Oct (14:58:44), Nick Mathewson wrote: On Tue, Oct 29, 2013 at 2:38 PM, David Goulet dgou...@ev0ke.net wrote: To be honest, I am not sure what's the right fix here or if there is any way to lookup the symbol in a special way that would help here. Any idea or questions are VERY welcome :). My first thought -- and I don't know how good it is -- is that perhaps you could just *not* look at syscalls that occur during the dlsym calls that you launch? In other words, disable the syscall override if the current thread is already inside the dlsym() call inside your syscall override. That would work if there is a way I can differ the hijack of the syscall symbol... Unfortunately, this is done at linking time thus during run time, the syscall symbol is already hijacked by torsocks. Let say we don't try to lookup the syscall symbol, the issue is that the original syscall libc pointer will NOT exists within torsocks code so we can't handle call to syscall() because we can't route it to libc. :S It's really that we get in a kind of infinite loop where dlsym calls syscall that calls dlsym and so on. But in the first place, we at least need the libc syscall symbol so we can handle them. David Would that work? What would it break, if anything? -- Nick ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Torsocks 2.x issue - Need eyes on that
On Tue, Oct 29, 2013 at 2:38 PM, David Goulet dgou...@ev0ke.net wrote: To be honest, I am not sure what's the right fix here or if there is any way to lookup the symbol in a special way that would help here. Any idea or questions are VERY welcome :). My first thought -- and I don't know how good it is -- is that perhaps you could just *not* look at syscalls that occur during the dlsym calls that you launch? In other words, disable the syscall override if the current thread is already inside the dlsym() call inside your syscall override. Would that work? What would it break, if anything? -- Nick ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Torsocks 2.x issue - Need eyes on that
On Tue, Oct 29, 2013 at 03:10:50PM -0400, David Goulet wrote: That would work if there is a way I can differ the hijack of the syscall symbol... Unfortunately, this is done at linking time thus during run time, the syscall symbol is already hijacked by torsocks. Let say we don't try to lookup the syscall symbol, the issue is that the original syscall libc pointer will NOT exists within torsocks code so we can't handle call to syscall() because we can't route it to libc. :S It's really that we get in a kind of infinite loop where dlsym calls syscall that calls dlsym and so on. But in the first place, we at least need the libc syscall symbol so we can handle them. Might it be possible to use objcopy tricks like --prefix-string or --redefine-sym to make the exported version of syscall different from the imported version? Then the torsocks code could just call syscall() as a normal libc function, linked by ld.so, but when firefox called syscall, it would call torsocks's torsocks_syscall(), or something? - Ian ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Torsocks 2.x issue - Need eyes on that
David Goulet: Now the issue was detected with firefox which uses a custom malloc hook meaning that it handles its own memory allocation. This hook uses mmap() that firefox redefines to be a direct syscall(__NR_mmap, ...) and remember that this symbol is hijacked by torsocks. […] It's a bit of a catch 22 because torsocks is basically looking for the libc syscall symbol but then it gets call inside that lookup code path... Wouldn't one way out be to also hook malloc to use a static buffer until dlsym() is done? The code snippet in the following answer is doing just that: http://stackoverflow.com/a/10008252 -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Torsocks 2.x issue - Need eyes on that
On 29 Oct (16:41:02), Ian Goldberg wrote: On Tue, Oct 29, 2013 at 03:10:50PM -0400, David Goulet wrote: That would work if there is a way I can differ the hijack of the syscall symbol... Unfortunately, this is done at linking time thus during run time, the syscall symbol is already hijacked by torsocks. Let say we don't try to lookup the syscall symbol, the issue is that the original syscall libc pointer will NOT exists within torsocks code so we can't handle call to syscall() because we can't route it to libc. :S It's really that we get in a kind of infinite loop where dlsym calls syscall that calls dlsym and so on. But in the first place, we at least need the libc syscall symbol so we can handle them. Might it be possible to use objcopy tricks like --prefix-string or --redefine-sym to make the exported version of syscall different from the imported version? Then the torsocks code could just call syscall() as a normal libc function, linked by ld.so, but when firefox called syscall, it would call torsocks's torsocks_syscall(), or something? I've played a bit with objcopy and redefining dynamic symbols is not possible. And a stripped binary makes things harder also... Unless you know a way to do that, I'll check in an other direction. Big thanks Ian! David - Ian ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [Otter/Buoyant] Tor Documentation Pad
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello everyone, At today's Buoyant Otter meeting, it was determined that we needed a pad to organize our thoughts regarding the current documentation we have, and what we need. I have created a pad at https://zugzug.titanpad.com/3 for this purpose, and will begin adding resources to it tomorrow. - -- - -Phoul -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJScH3pAAoJEJ01Zvx7KO7Y1c0P/39cMM5fSdx5LIVdfuKVctYx 6hde6OPDvmTPzzTI03MlcYMKRSvH60cJUKCah2J7r2nfEGD3gw0uq0hcn/izc1wr +de7y3yAofbygFCT1k9v3KBaPi+nezvglqYu+hia9gsKuXf3+cLSATpymxTtUIDN eOtEIsggCjDv3eD8bs4rSYINI2B+j6V0qj5Lhts0nikbLkoiO/Q34RxELr1DQxot D+19Lvqb+yVCZE3NEsGyeJEu9hbAwRGgYgB2Qv/CSvbJ7c6SYFx4K0PUbG1ZYlHs wQ0MB6PoZ3cub4W4jb0R3HwyT++tBARvzbrbALHGehmKCNsY6wZ1ucx36xJB/p6x ABruNMjzAZhMPAz7yrf9cakOCskqXn10se21yd6EHUlknOKECEwzdCxJxE0Oswph OjISwL+JAkI5aTC52NGelIwd2VPrYY/2RkOgCnybop7wGsBBqNqrY7pGLiT03NJx m7MYE0RqJfZUjH++Ym52KU15ycPG2JhRxjnmym8OrvW1TPw0t24mSjfzIR0x90XI Og7teG9ugxv2rCftdCVMNKLUh8BVOTC7G6GIxeqPlii7IHiHEAqBdxAhXAm945WJ BjrimEQ0E73s/M/j7mDf7dblZegansvlHXuoBEpJSiT9fZHu3DAlAGvTS0dmBIkF aMUcspY2nbhD+zCdI4z2 =OVcv -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
