[Pkg-anonymity-tools] Bug#684580: SIGSEGV in torsocks 2.0.0-1

[David Goulet]

On 30 Aug (13:18:33), intrigeri wrote:
> Hi,
> 
> JS wrote (30 Aug 2014 14:59:03 GMT) :
> > I've just upgrade torsocks from 1.3-3 to 2.0.0-1 and have found that
> > it gets SIGSEGV now
> 
> > Below is the backtrace from gdb after running:
> >      . torsocks on
> >      midori                    # but happens with most other apps as well
> 
> I've seen a segfault once when running midori in that context (sid, amd64):
> 
> [Aug 30 13:12:26] ERROR torsocks[5021]: [recvmsg] Inet socket passing detected. Aborting everything! A non Tor socket could be used thus leaking information. (in tsocks_recvmsg() at recv.c:87)

This implies that torsocks stopped the application completely. I was
able to reproduce that once with midori. This is normal behaviour for
now, since the application is about to receive a TCP socket from an
other process that is most probably NOT connected to the tor network, we
abort everything.

Maybe in the future we could simply deny the recvmsg() call and let the
application handle the error. That could be less "hammer-ish" :).

> 
> ... but I cannot reproduce it anymore.
> 
> > Perhaps this is a related problem to #684580?
> 
> I doubt it, as torsocks 2.x is a complete rewrite.
> JS, may you please file a separate bug?
> 
> David, could you please have a look?

I've played around with midori for 10 minutes and I got a lot of
segfaults from libgnutls, libc, libgtk and libsoup. None from
libtorsocks yet so I can't confirm the stacktrace below :S.

Cheers!
David

> 
> > Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".
> 
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x00000000 in ?? ()
> > (gdb) bt
> > #0  0x00000000 in ?? ()
> > #1  0xb7fcd12b in tsocks_close () from /usr/lib/torsocks/libtorsocks.so
> > #2  0xb7fcd1d4 in close () from /usr/lib/torsocks/libtorsocks.so
> > #3  0xb46491a6 in ?? () from /usr/lib/i386-linux-gnu/libGL.so.1
> > #4  0xb464973b in ?? () from /usr/lib/i386-linux-gnu/libGL.so.1
> > #5  0xb462c7c4 in ?? () from /usr/lib/i386-linux-gnu/libGL.so.1
> > #6 0xb7fed86a in call_init (l=0xb46f15a0, argc=argc at entry=1,
> > argv=argv at entry=0xbffff1f4, env=env at entry=0xbffff1fc) at dl-init.c:64
> > #7  0xb7fed9a4 in call_init (env=0xbffff1fc, argv=0xbffff1f4, argc=1, l=<optimized out>) at dl-init.c:36
> > #8  _dl_init (main_map=0xb7fff930, argc=1, argv=0xbffff1f4, env=0xbffff1fc) at dl-init.c:126
> > #9  0xb7fdfd3f in _dl_start_user () from /lib/ld-linux.so.2
> 
> 
> > ~ => /bin/ls -lt /usr/lib/i386-linux-gnu/libGL.so.1 
> > lrwxrwxrwx 1 root root 48 Nov 22 2013 /usr/lib/i386-linux-gnu/libGL.so.1 ->
> > /etc/alternatives/glx--libGL.so.1-i386-linux-gnu
> > ~ => readlink -f /usr/lib/i386-linux-gnu/libGL.so.1 
> > /usr/lib/i386-linux-gnu/nvidia/current/libGL.so.340.24
> 
> Cheers,
> -- 
> intrigeri
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-anonymity-tools/attachments/20140903/242b1809/attachment.sig>