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

[David Goulet]

On 03 Sep (07:09:53), JS wrote:
> David,
> 
> Thanks for looking at this.
> 
> 
> I've never had a problem running midori with torsocks 1.3, so these segmentation faults are new with 2.0.0.
> After reverting to 1.3, midori and iceweasel work correctly with torsocks.
> 
> Is it possible the problem is related to my version of libc6:
>     Versions of packages torsocks depends on:
>     ii  libc6  2.19-1
> 
> while the newest version is libc6 2.19-9 in jessie?

It's possible but the stacktrace you provided clearly shows torsocks as
the issue so I'm still puzzled.

Is it possible you can provide the full backtrace of the coredump?

Use "bt full" which will help me spot the callsite that segfaults in
tsocks_close().

> 
> thanks,
> --jack
> 
> 
> ----- Original Message -----
> From: David Goulet <dgoulet at ev0ke.net>
> To: intrigeri <intrigeri at debian.org>
> Cc: JS <jshaio at yahoo.com>; 684580 at bugs.debian.org
> Sent: Wednesday, September 3, 2014 9:10 AM
> Subject: Re: Bug#684580: SIGSEGV in torsocks 2.0.0-1
> 
> 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/068f2589/attachment.sig>