applications segfault systematically with tsocks

[Yann E. MORIN]

On Xenial, when an application is used through tsocks, it will systematically segfqult:

    $ ssh machine
    [connection OK]
    $ wget http://example.com/some/path
    [download succeeds]
    $ tsocks ssh machine
    Segmentation fault
    $ tsocks wget http://example.com/some/path
    Segmentation fault

    $ lsb_release -rd
    Description: Ubuntu 16.04 LTS
    Release: 16.04

    $ apt-cache policy tsocks
    tsocks:
      Installed: 1.8beta5-9.3
      Candidate: 1.8beta5-9.3
      Version table:
     *** 1.8beta5-9.3 500
            500 http://fr.archive.ubuntu.com/ubuntu xenial/universe amd64 Packages
            100 /var/lib/dpkg/status

Expected: connections through tsocks succeed

What happens: connections through tsocks systematically segfault

Here's my tsocks.conf:

    $ cat /etc/tsocks.conf
    local = 192.168.0.0/255.255.0.0
    server = 127.0.0.1
    server_port = 8083
    server_type = 5

Running through gdb:

    $ gdb ssh machine
    [...]
    (gdb) run
    Starting program: /usr/bin/ssh
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

    Program received signal SIGSEGV, Segmentation fault.
    0x0000000000000000 in ?? ()
    (gdb) bt
    #0 0x0000000000000000 in ?? ()
    #1 0x00007ffff7670e77 in poll (__timeout=10, __nfds=1, __fds=0x7fffffffdb70)
        at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
    #2 RAND_poll () at rand_unix.c:325
    #3 0x00007ffff766fbd5 in ssleay_rand_bytes (buf=0x555555804010 "\212\003", num=num@entry=60,
        pseudo=pseudo@entry=0, lock=lock@entry=0) at md_rand.c:398
    #4 0x00007ffff7670603 in drbg_get_entropy (ctx=<optimized out>, pout=0x7fffffffdec0,
        entropy=<optimized out>, min_len=60, max_len=<optimized out>) at rand_lib.c:199
    #5 0x00007ffff76e6278 in fips_get_entropy (dctx=dctx@entry=0x7ffff79a9960 <ossl_dctx>,
        pout=pout@entry=0x7fffffffdf30, entropy=<optimized out>, min_len=<optimized out>,
        max_len=2147483632) at fips_drbg_lib.c:151
    #6 0x00007ffff76e6904 in FIPS_drbg_instantiate (dctx=dctx@entry=0x7ffff79a9960 <ossl_dctx>,
        pers=pers@entry=0x7fffffffdf80 "OpenSSL DRBG2.0", perslen=perslen@entry=32)
        at fips_drbg_lib.c:223
    #7 0x00007ffff7670993 in RAND_init_fips () at rand_lib.c:302
    #8 0x00007ffff75b3f7a in OPENSSL_init_library () at o_init.c:119
    #9 0x00007ffff7de74ea in call_init (l=<optimized out>, argc=argc@entry=1,
        argv=argv@entry=0x7fffffffe078, env=env@entry=0x7fffffffe088) at dl-init.c:72
    #10 0x00007ffff7de75fb in call_init (env=0x7fffffffe088, argv=0x7fffffffe078, argc=1,
        l=<optimized out>) at dl-init.c:30
    #11 _dl_init (main_map=0x7ffff7ffe168, argc=1, argv=0x7fffffffe078, env=0x7fffffffe088)
        at dl-init.c:120
    #12 0x00007ffff7dd7cfa in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
    #13 0x0000000000000001 in ?? ()
    #14 0x00007fffffffe4da in ?? ()
    #15 0x0000000000000000 in ?? ()

Since Xenial does not have debugging symbols for tsocks, I can't provide much more (although
I'd gladly follow a quick and simple tutorial on doing so).

For the record, it was working in Wily (15.10) and all previous versions.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Yann E. MORIN (yann-morin-1998-r)]

Varga,

Please don't replace the description.
Add a comment if you need to.
Thanks. ;-)

[Yann E. MORIN (yann-morin-1998-r)]

There is a (vey old!) related bug in the Debian bug tracker:
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576301

There are two patches floating in that bug report, but they were
never made part of any tsocks relase:
    https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;att=1;filename=tsocks_fixpoll.patch;bug=576301
    https://bugs.debian.org/cgi-bin/bugreport.cgi?filename=fix_poll.patch;att=1;bug=576301;msg=15

However, of the two patches, it is not obvious which is the correct
solution; besides, they touch the exact same part of the code...
I'll try to test each and will report back (soonish...)

[Yann E. MORIN (yann-morin-1998-r)]

After testing, it appears that neither patch fix the issue. There still are segfaults...

[eexpress (eexpress)]

I just install tsocks, find this same problem. I remenber it works before.

[Yann E. MORIN (yann-morin-1998-r)]

After a bit more investigation, I hacked tsocks to spit out debug log in its _init() function:

    FILE *f = fopen( "/home/me/tsocks.msg", "a+" );
    fprintf( "[%s] Hello world\n", program_invocation_name );
    fclose( f );

However, when running:

    $ tsocks ssh machine
    Segmentation fault

The .msg file is *not* created at all!

So, it seems something is trying to initialise openSSL before calling the _init() from tsocks...

So, I tried with another program *not* linked with openSSL. I used curl, which is linked with GnuTLS:

    $ curl https://example.com/
    [works!]

Conclusion: openSSL does get initialised before tsocks. That's really weird, as tsocks is in LD_PRELOAD,
so should come before any shared library from a NEEDED tag.

/me is now investigating the linker documentation to understand what's goign on...

[Yann E. MORIN (yann-morin-1998-r)]

I managed to make it work with the attached patch.

This is probably not a correct patch, but it at least makes it work, and can serve as a base for a correct patch.

In the end, it happens that some libraries (like openssl) are initialised before those in LD_PRELOAD (which is really weird as ld.so does not document this behaviour). So, tsocks not being initialised, the wrapper functions were calling functions via un-initialised function pointers.

[Mario Limonciello (superm1)]

Great news thanks! Would you mind submitting upstream as well?

On Mon, May 2, 2016, 15:05 Yann E. MORIN <email address hidden> wrote:

> I managed to make it work with the attached patch.
>
> This is probably not a correct patch, but it at least makes it work, and
> can serve as a base for a correct patch.
>
> In the end, it happens that some libraries (like openssl) are
> initialised before those in LD_PRELOAD (which is really weird as ld.so
> does not document this behaviour). So, tsocks not being initialised, the
> wrapper functions were calling functions via un-initialised function
> pointers.
>
> ** Attachment added: "Be sure to always intialise function pointers"
>
> https://bugs.launchpad.net/ubuntu/+source/tsocks/+bug/1574270/+attachment/4653856/+files/07_init.dpatch
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1574270
>
> Title:
> applications segfault systematically with tsocks
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/tsocks/+bug/1574270/+subscriptions
>

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Be sure to always intialise function pointers" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Yann E. MORIN (yann-morin-1998-r)]

Mario,

The "official" upstream tsocks has not done any release since October 2002, that is almost 14 years ago. Besides, there does nto seem to be any publicly available repository of any kind (no svn, no cvs or anything that was current at the time).

I'm not sure it makes sense to send a patch to a dead project.

If we were to consider Debian as the new upstream, I can't really report a bug there, as I don't use Debian so can't check if the bug also applies to them...

However, the maintainer for this package in Ubuntu is also the maintainer for the same package in Debian. So, hopefully, he'd notice this bug! ;-)

(Cc-ing Tamas now, so he does notice it.)

In the meantime, it would be nice if you could also test on your side with your use-cases, so as to get a bit more confidence in the patch (which I only tested in my own use-case, and only lightly tested at that...).

Cheers!

[PlantDaddy (plantdaddy)]

I'll try this patch in the morning

[Mario Limonciello (superm1)]

Yann. Ah didn't realize upstream was so dead. Yes, i'll give it a shot for my cases then.
Thanks!

[Mario Limonciello (superm1)]

Yeah, just tried with it on my local case. Works properly for me!

[PlantDaddy (plantdaddy)]

Just patched and ran in my environment. It works, but one of the patch hunks failed:

lost@lost-cynic:~/tsocks$ sudo apt-get source tsocks
Reading package lists... Done
Need to get 87.0 kB of source archives.
Get:1 http://us.archive.ubuntu.com/ubuntu xenial/universe tsocks 1.8beta5-9.3 (dsc) [1,455 B]
Get:2 http://us.archive.ubuntu.com/ubuntu xenial/universe tsocks 1.8beta5-9.3 (tar) [85.5 kB]
Fetched 87.0 kB in 0s (276 kB/s)
dpkg-source: info: extracting tsocks in tsocks-1.8beta5
dpkg-source: info: unpacking tsocks_1.8beta5-9.3.tar.gz
W: Can't drop privileges for downloading as file 'tsocks_1.8beta5-9.3.dsc' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
lost@lost-cynic:~/tsocks/tsocks-1.8beta5$ sudo ./07_init.dpatch -patch
patching file tsocks.c
Hunk #1 succeeded at 69 (offset -1 lines).
Hunk #2 succeeded at 102 (offset -2 lines).
Hunk #3 succeeded at 207 (offset -4 lines).
Hunk #4 succeeded at 359 with fuzz 1 (offset -13 lines).
Hunk #5 succeeded at 543 (offset -15 lines).
Hunk #6 succeeded at 699 (offset -15 lines).
Hunk #7 FAILED at 756.
Hunk #8 succeeded at 1181 (offset -63 lines).
1 out of 8 hunks FAILED -- saving rejects to file tsocks.c.rej

Contents of tsocks.c.rej:
lost@lost-cynic:~/tsocks/tsocks-1.8beta5$ cat tsocks.c.rej
--- tsocks-orig.c 2016-05-02 21:07:58.804224930 +0200
+++ tsocks.c 2016-05-02 21:13:00.399657192 +0200
@@ -756,6 +773,8 @@
    struct connreq *conn;
    int rc;

+ tsocks_init();
+
     if (realgetpeername == NULL) {
         show_msg(MSGERR, "Unresolved symbol: getpeername\n");
         return(-1);

lost@lost-cynic:~/tsocks/tsocks-1.8beta5$ sudo apt-get build-dep tsocks
Reading package lists... Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  debhelper dh-strip-nondeterminism libfile-stripnondeterminism-perl po-debconf
0 upgraded, 4 newly installed, 0 to remove and 1 not upgraded.
Need to get 988 kB of archives.
After this operation, 1,823 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 po-debconf all 1.0.19 [234 kB]
Get:2 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 libfile-stripnondeterminism-perl all 0.015-1 [10.3 kB]
Get:3 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 dh-strip-nondeterminism all 0.015-1 [4,864 B]
Get:4 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 debhelper all 9.20160115ubuntu3 [739 kB]
Fetched 988 kB in 0s (1,444 kB/s)
Selecting previously unselected package po-debconf.
(Reading database ... 299037 files and directories currently installed.)
Preparing to unpack .../po-debconf_1.0.19_all.deb ...
Unpacking po-debconf (1.0.19) ...
Selecting previously unselected package libfile-stripnondeterminism-perl.
Preparing to unpack .../libfile-stripnondeterminism-perl_0.015-1_all.deb ...
Unpacking libfile-stripnondeterminism-perl (0.015-1) ...
Selecting previously unselected package dh-strip-nondeterminism.
Preparing to unpack .../dh-strip-nondeterminism_0.015-1_all.deb ...
Unpacking dh-strip-nondeterminism (0.015-1) ...
Selecting previously unselected p...

[Yann E. MORIN (yann-morin-1998-r)]

Brendan,

That's because the attached patch expects the bundled patches are already applied.

Here's how I did (as non-root):

    $ sudo apt-get build-dep tsocks
    [--snip--]
    $ apt-get source tsocks
    [--snip--]
    $ cp 07_init.dpatch tsocks-1.8beta5/debian/patches/
    $ cd tsocks-1.8beta5/
    $ dpkg-buildpacakge -us -uc
    [--snip--]
    $ cd ..
    $ sudo apt-get purge tsocks
    $ sudo dpkg --install tsocks_1.8beta5-9.3_amd64.deb

Also, to avoid tsocks being re-installed from the repository every time I run "make dist-upgrade", I simply uninstalled it before installing my locally-built tsocks (hence the "apt-get purge tsocks in the commands above).

[Yann E. MORIN (yann-morin-1998-r)]

Oh, by the way, I just noticed that the description in the patch itself is wrong. I just copy-pasted the one from an existing patch to get the layout, but forgot to edit it afterward. I'll post an upated version of the patch shortly...

[Martin von Wittich (martin.von.wittich)]

Patch works for me too. Would be nice if this could make it to the official repository.

[Yann E. MORIN (yann-morin-1998-r)]

Dear Tamas,
Dear Ubuntu Review Team,

It's been more than a month that I have posted a proposal to
fix this bug. In the meantime, I have tested this extensively
(as *everything* gets out of my machine via tsocks) and I have
had no issue at all. with the proposed patch.

Can we at least get a status on this bug, even it is just a
"won't fix" or "don't care" or whatever, please? ;-)

Thanks!

Regards,
Yann E. MORIN

PS. Adding Logan, as I see he pushed an update for yakkety not
so long ago...

[Markus Rexhepi-Lindberg (k-markus)]

I can confirm that the patch do in fact resolve the segmentation fault issue. But I were only able to patch it using the method described in comment #14. The method described in comment #15 doesn't seem to have any affect.

Best regards,
Markus Lindberg

[Yann E. MORIN (yann-morin-1998-r)]

Markus, All,

Weird that it did not work for you. I retested it just right now, and it worked for me.

Note however that I did a mistake when typing the command in the report: dpkg-buildpacakge is misspelled, it should be dpkg-buildpackage.

Regards,
Yann E. MORIN.

[Yann E. MORIN (yann-morin-1998-r)]

All,

Thanks to the testers; thanks to the up-voters! It feels good not to be alone! ;-)

However, I'm not sure what to do with this bug report now...

The maintainer is in Cc, the Ubuntu Review Team is in Cc, the last uploader is in Cc. Yet, no reply so far.

I know the tsocks code base is, to say the least, not the best I had to deal with; yet the reasons are pretty well explained and the patch itself pretty simple. It's a wonder the bug did not get exposed until only recently; it's been latent for all those years.

I *am* ready to rework the patch if it is deemed to be not correct, but I can't do that without feedback. Heck, I would even consider volunteering to handle this package for the foreseable future if that would help (but I am not used to packaging; I'd need directions quite often).

Quid?

Regards,
Yann E. MORIN.

[GospoGied (gospogied)]

@Markus Lindberg (k-markus)
There is one more step required in #15, which is edit file debian/patches/00list

    $ sudo apt-get build-dep tsocks
    [--snip--]
    $ apt-get source tsocks
    [--snip--]
    $ cp 07_always_init_function_pointers.dpatch tsocks-1.8beta5/debian/patches/
    $ echo -e "\n07_always_init_function_pointers.dpatch" >> tsocks-1.8beta5/debian/patches/00list
    $ cd tsocks-1.8beta5/
    $ dpkg-buildpackage -us -uc
    [--snip--]
    $ sudo apt-get purge tsocks
    $ sudo dpkg --install ../tsocks_1.8beta5-9.3_amd64.deb

[Markus Rexhepi-Lindberg (k-markus)]

@GospoGied (gospogied)
Thanks, that did it.

Best regards
Markus Lindberg
IT Helpdesk

[Johan Ramm-Ericson (johanre)]

Additional confirmation; the patch works for me as well - thanks all!

[Martin von Wittich (martin.von.wittich)]

I just stumbled over this bug again. What do we have to do so that the patch gets included in the official package...?

[IC Raibow (icrbow)]

Btw, the fix is still not in yakkety. Who can we grill to speed up the process?

[Chris Samuel (chris-csamuel)]

Just confirming that this patch once again lets me again use tsocks successfully!

Thanks so much for this work.

Now if only the Ubuntu folks were listening..

[Markus Rexhepi-Lindberg (k-markus)]

This seems to be fixed now. I can use tsocks (1.8beta5-9.3) without it seg faulting.

Can anyone else confirm this?

[Sébastien Dinot (sebastien-dinot)]

I can confirm this, it works for me!