Lunar:
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.
[…]
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
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
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
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
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
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
