Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T16:10:01Zhttps://gitlab.torproject.org/legacy/trac/-/issues/28627[torsocks] AAAA replies from tor not handled2020-06-13T16:10:01ZTrac[torsocks] AAAA replies from tor not handledAs reported on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895903:
_Tor now returns IPv6 addresses when hostnames are resolved, but torsocks cannot handle this case._
To reproduce:
```
torsocks -d nc v6.ipv6-test.com 80
```
''...As reported on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895903:
_Tor now returns IPv6 addresses when hostnames are resolved, but torsocks cannot handle this case._
To reproduce:
```
torsocks -d nc v6.ipv6-test.com 80
```
''
This makes it tricky to use torsocks on domains that will resolve to an AAAA only causing the program to abort with no error message.''
Indeed, in
```
int socks5_send_resolve_request(const char *hostname, struct connection *conn)
```
I see:
```
/* By default we use IPv4 address. */
msg.atyp = SOCKS5_ATYP_DOMAIN;
```
(I've tested it from the command line with torsocks 2.3.0, and it does not work, while using TBB it works fine.)
I'm not sure if this issue is also related to this bug:
https://trac.torproject.org/projects/tor/ticket/25295
**Trac**:
**Username**: uhttps://gitlab.torproject.org/legacy/trac/-/issues/28539Build breaks on FreeBSD: undefined reference to `handle_mmap'2020-06-13T16:10:00Zyurivict271Build breaks on FreeBSD: undefined reference to `handle_mmap'In version 2.3.0:
```
../../src/lib/.libs/libtorsocks.so: undefined reference to `handle_mmap'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[4]: *** [Makefile:623: test_socks5] Error 1
gmake[4]: *** ...In version 2.3.0:
```
../../src/lib/.libs/libtorsocks.so: undefined reference to `handle_mmap'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[4]: *** [Makefile:623: test_socks5] Error 1
gmake[4]: *** Waiting for unfinished jobs....
libtool: link: cc -I../../include -I../../src -I../../tests/utils/ -I. -I../../src/lib -DTORSOCKS_FIXTURE_PATH=\"/usr/ports/net/torsocks/work/torsocks-2.3.0/tests/unit/fixtures/\" -O2 -pipe -fno-omit-frame-pointer -fstack-protector -fno-strict-aliasing -Wall -fPIE -fwrapv --param ssp-buffer-size=1 -fstack-protector-all -fstack-protector -pie -z relro -z now -o .libs/test_compat test_compat.o ../../tests/utils/tap/.libs/libtap.a ../../src/common/.libs/libcommon.a ../../src/lib/.libs/libtorsocks.so -Wl,-rpath -Wl,/usr/local/lib/torsocks
../../src/lib/.libs/libtorsocks.so: undefined reference to `handle_mmap'
```David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/28538[regression] torsocks uses linux-specific tsocks_libc_accept4 on FreeBSD2020-06-13T16:10:00Zyurivict271[regression] torsocks uses linux-specific tsocks_libc_accept4 on FreeBSDSee src/lib/torsocks.c.
Version 2.3.0
```
torsocks.c:237:2: error: use of undeclared identifier 'tsocks_libc_accept4'; did you mean 'tsocks_libc_accept'?
tsocks_libc_accept4 = dlsym(libc_ptr, LIBC_ACCEPT4_NAME_STR);
^...See src/lib/torsocks.c.
Version 2.3.0
```
torsocks.c:237:2: error: use of undeclared identifier 'tsocks_libc_accept4'; did you mean 'tsocks_libc_accept'?
tsocks_libc_accept4 = dlsym(libc_ptr, LIBC_ACCEPT4_NAME_STR);
^~~~~~~~~~~~~~~~~~~
tsocks_libc_accept
./torsocks.h:411:8: note: 'tsocks_libc_accept' declared here
extern TSOCKS_LIBC_DECL(accept, LIBC_ACCEPT_RET_TYPE, LIBC_ACCEPT_SIG)
^
./torsocks.h:34:9: note: expanded from macro 'TSOCKS_LIBC_DECL'
type (*tsocks_libc_##name)(sig);
^
<scratch space>:55:1: note: expanded from here
tsocks_libc_accept
^
torsocks.c:237:40: error: use of undeclared identifier 'LIBC_ACCEPT4_NAME_STR'
tsocks_libc_accept4 = dlsym(libc_ptr, LIBC_ACCEPT4_NAME_STR);
^
torsocks.c:239:53: error: use of undeclared identifier 'tsocks_libc_accept4'; did you mean 'tsocks_libc_accept'?
!tsocks_libc_syscall || !tsocks_libc_execve || ! tsocks_libc_accept4) {
^~~~~~~~~~~~~~~~~~~
tsocks_libc_accept
```https://gitlab.torproject.org/legacy/trac/-/issues/27920"Resolve destination buffer too small" is unclear2020-06-13T16:10:00Ztraumschule"Resolve destination buffer too small" is unclearDoes torsocks support socks4?
I tried to torify cpan and ran into:
```
$ torsocks cpan instal ...
...
Running make test
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; ...Does torsocks support socks4?
I tried to torify cpan and ran into:
```
$ torsocks cpan instal ...
...
Running make test
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/01_load.t .......... 1/1 IO::Socket::IP v0.38 used as base class
t/01_load.t .......... ok
t/02_new.t ........... ok
t/03_connect.t ....... 1538348508 ERROR torsocks[8443]: [socks5] Resolve destination buffer too small (in socks5_recv_resolve_reply() at socks5.c:707)
t/03_connect.t ....... 1/?
# Failed test 'Socks 4 connect'
# at t/03_connect.t line 22.
# Non-recoverable failure in name resolution
Can't call method "version" on an undefined value at t/03_connect.t line 23.
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 22 just after 1.
```
Related: #25599, #26339https://gitlab.torproject.org/legacy/trac/-/issues/26889torsocks: option to disable all network traffic2020-06-13T16:09:59ZTractorsocks: option to disable all network trafficI've already talked to dgoulet about this:
I would love an option to make torsocks disable all network traffic. There are many good use cases to run applications without Internet communication. For example, commands in mailcap(4) to dis...I've already talked to dgoulet about this:
I would love an option to make torsocks disable all network traffic. There are many good use cases to run applications without Internet communication. For example, commands in mailcap(4) to display non-text.
This is a classic job for (application) firewalls, but torsocks has all the functionality already, f.e. if used with an invalid --port where no Tor or proxy is actually listening. But this is an ugly hack.
A --disable-network option would be very easy for torsocks, and very useful. Of course, it's low priority.
**Trac**:
**Username**: ilfhttps://gitlab.torproject.org/legacy/trac/-/issues/26888torsocks: --quiet option2020-06-13T16:09:59ZTractorsocks: --quiet optionIMHO, torsocks could use a --quiet option.
Interactively, torsocks errors and warnings regularly interfere with ncurses rendering, which create annoying display issues in applications like Mutt.
In scripts, torsocks errors and warnings...IMHO, torsocks could use a --quiet option.
Interactively, torsocks errors and warnings regularly interfere with ncurses rendering, which create annoying display issues in applications like Mutt.
In scripts, torsocks errors and warnings make STDERR more verbose. Filtering Torsocks STDERR also takes away the STDERR of the actual applications I torify. I might be interested in applications STDERR but not torsocks STDERR. There's probably a way to achieve that, but torsocks --quiet would be really simple.
Since torsocks fails closed, I would feel comfortable to use torsocks in a --quiet mode in these cases.
**Trac**:
**Username**: ilfDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/26831Feature: conditionally allow non-localhost inbound connections with command-l...2020-06-13T16:09:58ZTracFeature: conditionally allow non-localhost inbound connections with command-line flagI am able to run ZNC without torsocks. Here's my attempt to proxy ZNC via torsocks:
```
foo@foo:~$ torsocks -d znc
1531790543 DEBUG torsocks[2727]: Logging subsytem initialized. Level 5, file (null), time 1 (in init_logging() at torsocks...I am able to run ZNC without torsocks. Here's my attempt to proxy ZNC via torsocks:
```
foo@foo:~$ torsocks -d znc
1531790543 DEBUG torsocks[2727]: Logging subsytem initialized. Level 5, file (null), time 1 (in init_logging() at torsocks.c:303)
1531790543 DEBUG torsocks[2727]: Config file not provided by TORSOCKS_CONF_FILE. Using default /etc/tor/torsocks.conf (in config_file_read() at config-file.c:543)
1531790543 DEBUG torsocks[2727]: Config file setting tor address to 127.0.0.1 (in conf_file_set_tor_address() at config-file.c:298)
1531790543 DEBUG torsocks[2727]: Config file setting tor port to 9050 (in conf_file_set_tor_port() at config-file.c:254)
1531790543 DEBUG torsocks[2727]: [config] Onion address range set to 127.42.42.0/24 (in set_onion_info() at config-file.c:108)
1531790543 DEBUG torsocks[2727]: Config file /etc/tor/torsocks.conf opened and parsed. (in config_file_read() at config-file.c:572)
1531790543 DEBUG torsocks[2727]: [fclose] Close caught for fd 3 (in tsocks_fclose() at fclose.c:45)
1531790543 DEBUG torsocks[2727]: [onion] Pool init with subnet 127.42.42.0 and mask 24 (in onion_pool_init() at onion.c:104)
1531790543 DEBUG torsocks[2727]: [onion] Pool initialized with base 0, max_pos 255 and size 8 (in onion_pool_init() at onion.c:132)
1531790543 DEBUG torsocks[2727]: [fclose] Close caught for fd 5 (in tsocks_fclose() at fclose.c:45)
[ .. ] Checking for list of available modules...
[ >> ] ok
[ .. ] Opening config [/home/foo/.znc/configs/znc.conf]...
[ >> ] ok
[ .. ] Loading global module [webadmin]...
[ >> ] [/usr/lib/znc/webadmin.so]
[ .. ] Binding to port [+21212]...
1531790543 DEBUG torsocks[2727]: [socket] Creating socket with domain 10, type 1 and protocol 6 (in tsocks_socket() at socket.c:33)
1531790543 DEBUG torsocks[2727]: [listen] Non localhost inbound connection are not allowed. (in tsocks_listen() at listen.c:64)
1531790543 DEBUG torsocks[2727]: [close] Close caught for fd 6 (in tsocks_close() at close.c:33)
[ !! ] Unable to bind [Operation not permitted]
[ ** ] Unrecoverable config error.
1531790543 DEBUG torsocks[2727]: [close] Close caught for fd 5 (in tsocks_close() at close.c:33)
1531790543 DEBUG torsocks[2727]: [onion] Destroying onion pool containing 0 entry (in onion_pool_destroy() at onion.c:148)
1531790543 DEBUG torsocks[2727]: [fclose] Close caught for fd 2 (in tsocks_fclose() at fclose.c:45)
foo@foo:~$
```
**Trac**:
**Username**: dbkaplunhttps://gitlab.torproject.org/legacy/trac/-/issues/26821[torsocks] configure script from the tarball breaks2020-06-13T16:09:58Zyurivict271[torsocks] configure script from the tarball breaksTarball: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.2.0.tar.xz
Build breaks in the FreeBSD port after the configure script run:
```
config.status: executing libtool commands
===> Building for torsocks-2.2.0_1
gmake[2]: ...Tarball: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.2.0.tar.xz
Build breaks in the FreeBSD port after the configure script run:
```
config.status: executing libtool commands
===> Building for torsocks-2.2.0_1
gmake[2]: Entering directory '/usr/ports/net/torsocks/work/torsocks-2.2.0'
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /usr/ports/net/torsocks/work/torsocks-2.2.0/config/missing aclocal-1.15 -I config
/usr/ports/net/torsocks/work/torsocks-2.2.0/config/missing: aclocal-1.15: not found
WARNING: 'aclocal-1.15' is missing on your system.
You should only need it if you modified 'acinclude.m4' or
'configure.ac' or m4 files included by 'configure.ac'.
The 'aclocal' program is part of the GNU Automake package:
<http://www.gnu.org/software/automake>
It also requires GNU Autoconf, GNU m4 and Perl in order to run:
<http://www.gnu.org/software/autoconf>
<http://www.gnu.org/software/m4/>
<http://www.perl.org/>
gmake[2]: *** [Makefile:411: aclocal.m4] Error 127
```
Autoreconf though generates the non-breaking configure script.
Something is wrong with this configure, or something is missing, not sure.https://gitlab.torproject.org/legacy/trac/-/issues/26794tsocks_gethostbyname_r does not assign result2020-06-13T16:09:57ZTractsocks_gethostbyname_r does not assign resultFrom the manual, gethostbyname_r result argument must be assigned,
"After the call, result will point to the result on success. In case of an error or if no entry is found result will be NULL."
attached patchfile
**Trac**:
**...From the manual, gethostbyname_r result argument must be assigned,
"After the call, result will point to the result on success. In case of an error or if no entry is found result will be NULL."
attached patchfile
**Trac**:
**Username**: cHBWyJuHDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/26580torsocks complains about unknown system call #417 on FreeBSD2020-06-13T16:09:57Zyurivict271torsocks complains about unknown system call #417 on FreeBSDCommand:
```
torify telnet {some-onion}.onion {some port}
```
When it connects, pressing Ctrl-C prints this error:
```
^C1530319165 WARNING torsocks[69407]: [syscall] Unsupported syscall number 417. Denying the call (in tsocks_syscall(...Command:
```
torify telnet {some-onion}.onion {some port}
```
When it connects, pressing Ctrl-C prints this error:
```
^C1530319165 WARNING torsocks[69407]: [syscall] Unsupported syscall number 417. Denying the call (in tsocks_syscall() at syscall.c:496)
```
and telnet doesn't exit.
torsocks-2.2.0 on FreeBSD 11.1https://gitlab.torproject.org/legacy/trac/-/issues/25884add support for exitmap requirements2020-06-13T16:09:56Zcypherpunksadd support for exitmap requirementsphw wrote a patch for torsocks a long time ago,
it would be great if this could be adapted to a current version of torsocks and merged
<https://github.com/NullHypothesis/torsocks/commit/e8b3fe64a5b2c324086a16615be38736addb94f9>phw wrote a patch for torsocks a long time ago,
it would be great if this could be adapted to a current version of torsocks and merged
<https://github.com/NullHypothesis/torsocks/commit/e8b3fe64a5b2c324086a16615be38736addb94f9>https://gitlab.torproject.org/legacy/trac/-/issues/25785Torsocks error. Symbol res_query, res_search, res_domain, res_querydomian not...2020-06-13T16:09:56ZTracTorsocks error. Symbol res_query, res_search, res_domain, res_querydomian not found.Hello,
I used to happily do torsocks ssh to connect to a remote server. But now I get the error pasted below. What can I do? Thank you!
maru@gnulaptop:~$ torsocks ssh user@host.net
12:05:39 libtorsocks(16139): WARNING: The symbol res_q...Hello,
I used to happily do torsocks ssh to connect to a remote server. But now I get the error pasted below. What can I do? Thank you!
maru@gnulaptop:~$ torsocks ssh user@host.net
12:05:39 libtorsocks(16139): WARNING: The symbol res_query() was not found in any shared library with the reported error: Not Found!
Also, we failed to find the symbol __res_query() with the reported error: Not Found
12:05:39 libtorsocks(16139): WARNING: The symbol res_search() was not found in any shared library with the reported error: Not Found!
Also, we failed to find the symbol __res_search() with the reported error: Not Found
12:05:39 libtorsocks(16139): WARNING: The symbol res_send() was not found in any shared library with the reported error: Not Found!
Also, we failed to find the symbol __res_send() with the reported error: Not Found
12:05:39 libtorsocks(16139): WARNING: The symbol res_querydomain() was not found in any shared library with the reported error: Not Found!
Also, we failed to find the symbol __res_querydomain() with the reported error: Not Found
12:05:39 libtorsocks(16140): WARNING: The symbol res_query() was not found in any shared library with the reported error: Not Found!
Also, we failed to find the symbol __res_query() with the reported error: Not Found
12:05:39 libtorsocks(16140): WARNING: The symbol res_search() was not found in any shared library with the reported error: Not Found!
Also, we failed to find the symbol __res_search() with the reported error: Not Found
12:05:39 libtorsocks(16140): WARNING: The symbol res_send() was not found in any shared library with the reported error: Not Found!
Also, we failed to find the symbol __res_send() with the reported error: Not Found
12:05:39 libtorsocks(16140): WARNING: The symbol res_querydomain() was not found in any shared library with the reported error: Not Found!
Also, we failed to find the symbol __res_querydomain() with the reported error: Not Found
**Trac**:
**Username**: MaruDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/25627tsocks_gethostbyaddr_r scribbles garbage over data->hostname and then relies ...2020-06-13T16:09:55ZTractsocks_gethostbyaddr_r scribbles garbage over data->hostname and then relies on itHere's an edited version of the implementation with extraneous portions removed in an effort to make the mistake more clear:
```
struct data {
char *hostname;
char *addr_list[2];
c...Here's an edited version of the implementation with extraneous portions removed in an effort to make the mistake more clear:
```
struct data {
char *hostname;
char *addr_list[2];
char padding[];
} *data;
// ...
data = (struct data *) buf;
// ...
ret_str = inet_ntop(type, addr, buf, buflen);
// ...
if (data->hostname) {
```
Specifically, notice that `data` is an alias for `buf` and therefore the underlying memory is given to `inet_ntop` to write on as a `char*` but then `tsocks_gethostbyaddr_r` tries to interpret that same memory through the `data` struct to retrieve the `hostname` field. The result is garbage which provokes a crash shortly afterwards:
```
he->h_length = strlen(he->h_name);
```
This case is triggered by an error response to the resolve_ptr request (`\5\1\0\0`) when the IP address is valid (so that `inet_ntop` writes the garbage to `buf`).
I can imagine a couple fixes. The simplest overall would seem to be to stack allocated a new buffer for `inet_ntop`. This makes calling `tsocks_gethostbyaddr_r` a little more expensive (in terms of stack space) but greatly simplifies the code be removing the surprising aliasing.
**Trac**:
**Username**: exarkunDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/25586gethostbyaddr_r doesn't populate h_addrtype field of output hostent struct2020-06-13T16:09:55ZTracgethostbyaddr_r doesn't populate h_addrtype field of output hostent structThe glibc implementation of gethostbyaddr_r will set h_addrtype to the address family that was passed in as an argument. Some programs depend on this (CPython is the one I noticed) for correct operation.
The current behavior leaves the...The glibc implementation of gethostbyaddr_r will set h_addrtype to the address family that was passed in as an argument. Some programs depend on this (CPython is the one I noticed) for correct operation.
The current behavior leaves the field unchanged and likely provides an undefined value to the caller. In the case of CPython, this results in `socket.gethostbyaddr` always raising EAFNOSUPPORT.
**Trac**:
**Username**: exarkunDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/24979torsocks could support ptrace sandboxing2020-06-13T16:09:54ZAlex Xutorsocks could support ptrace sandboxingpros:
- 'fixes' SIP, suid, caps
- fixes static binaries
cons:
- kind of a pain to implement
- DNS would require actual parsing, which is apparently a hard problem even for 'minimal' implementations: https://security.googleblog.com/201...pros:
- 'fixes' SIP, suid, caps
- fixes static binaries
cons:
- kind of a pain to implement
- DNS would require actual parsing, which is apparently a hard problem even for 'minimal' implementations: https://security.googleblog.com/2017/10/behind-masq-yet-more-dns-and-dhcp.html. I think an initial hybrid implementation could punt on this, and it would still fix the ugly hack of hardcoding SIP paths.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/24967torsocks fails to check SIP if the path itself is a symlink2020-06-13T16:09:54ZAlex Xutorsocks fails to check SIP if the path itself is a symlinksuppose /a -> /usr/bin, and /b -> /usr/bin/b. torsocks will error on /a/b, but /b will simply fail to apply torsocks (I think). I have a patch for this, will clean up and submit some time in the next few days hopefully.suppose /a -> /usr/bin, and /b -> /usr/bin/b. torsocks will error on /a/b, but /b will simply fail to apply torsocks (I think). I have a patch for this, will clean up and submit some time in the next few days hopefully.Alex XuAlex Xuhttps://gitlab.torproject.org/legacy/trac/-/issues/24960Torsocks not builds on old kernels where epoll_pwait isn't implemented2020-06-13T16:09:53ZTracTorsocks not builds on old kernels where epoll_pwait isn't implementedWhen I tried to compile Torsocks v2.2.0 on an embedded device (with Linux 2.6.31.8 kernel), it gave me this error:
```
CC test_socks5.o
CCLD test_socks5
../../src/lib/.libs/libtorsocks.so: undefined reference to `epoll_pw...When I tried to compile Torsocks v2.2.0 on an embedded device (with Linux 2.6.31.8 kernel), it gave me this error:
```
CC test_socks5.o
CCLD test_socks5
../../src/lib/.libs/libtorsocks.so: undefined reference to `epoll_pwait'
collect2: error: ld returned 1 exit status
Makefile:606: recipe for target 'test_socks5' failed
make[2]: *** [test_socks5] Error 1
```
Because the epoll_pwait and the epoll system call has been implemented in the 2.6.32 AFAIK.
**Trac**:
**Username**: Mr DiniDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/24140When I "torify ssh root@abcdefghijklmnop.onion" I get a error2020-06-13T16:09:53ZTracWhen I "torify ssh root@abcdefghijklmnop.onion" I get a errorWhen I torify ssh root@abcdefghijklmnop.onion I get a error "/usr/local/bin/torify: torsocks not found in your PATH. Perhaps it isn't installed? (tsocks is no longer supported, for security reasons.)"
1. install tor using brew or macp...When I torify ssh root@abcdefghijklmnop.onion I get a error "/usr/local/bin/torify: torsocks not found in your PATH. Perhaps it isn't installed? (tsocks is no longer supported, for security reasons.)"
1. install tor using brew or macports
2. in terminal enter torify ssh <your-username>@abcdefghijklmnop.onio
3. you should get this error every time
macOS 10.13.1 (17B48)
**Trac**:
**Username**: DbryrtfbcbhgfDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/24116Torsocks deadlocks every Rust program2020-06-13T16:09:52ZTracTorsocks deadlocks every Rust programAny Rust program that is run with torsocks will deadlock. This has nothing to do with networking, even the program 'fn main() { }' compiled with a recent rustc will deadlock when run as 'torsocks ./rust_torsocks'.
This is a backtrace I ...Any Rust program that is run with torsocks will deadlock. This has nothing to do with networking, even the program 'fn main() { }' compiled with a recent rustc will deadlock when run as 'torsocks ./rust_torsocks'.
This is a backtrace I got when attaching to the deadlocked process:
```
#0 0xb7713cf9 in __kernel_vsyscall ()
#1 0xb76b9d92 in __lll_lock_wait ()
at ../sysdeps/unix/sysv/linux/i386/lowlevellock.S:144
#2 0xb76b38de in __GI___pthread_mutex_lock (mutex=0xb770d024)
at ../nptl/pthread_mutex_[lock.c:80 lock.c:80]
#3 0xb77001ed in tsocks_mutex_lock ()
from /usr/lib/i386-linux-gnu/torsocks/libtorsocks.so
#4 0xb7700334 in tsocks_once ()
from /usr/lib/i386-linux-gnu/torsocks/libtorsocks.so
#5 0xb76fa25e in tsocks_initialize ()
from /usr/lib/i386-linux-gnu/torsocks/libtorsocks.so
#6 0xb76fd02d in syscall ()
from /usr/lib/i386-linux-gnu/torsocks/libtorsocks.so
#7 0x004a5049 in os_overcommits_proc ()
at /checkout/src/liballoc_jemalloc/../jemalloc/src/pages.c:252
#8 je_pages_boot ()
at /checkout/src/liballoc_jemalloc/../jemalloc/src/pages.c:297
#9 0x004745dd in malloc_init_hard_a0_locked ()
at /checkout/src/liballoc_jemalloc/../jemalloc/src/jemalloc.c:1366
#10 0x00474768 in malloc_init_hard ()
at /checkout/src/liballoc_jemalloc/../jemalloc/src/jemalloc.c:1493
#11 0x00489b95 in malloc_init ()
at /checkout/src/liballoc_jemalloc/../jemalloc/src/jemalloc.c:317
#12 ialloc_body (slow_path=true, usize=<synthetic pointer>,
tsdn=<synthetic pointer>, zero=true, size=20)at /checkout/src/liballoc_jemalloc/../jemalloc/src/jemalloc.c:1583
#13 calloc (num=1, size=20)
at /checkout/src/liballoc_jemalloc/../jemalloc/src/jemalloc.c:1824
#14 0xb76d23ec in _dlerror_run (
operate=operate@entry=0xb76d1b80 <dlopen_doit>, args=args@entry=0xbfb8cd10)
#15 0xb76d1c9e in __dlopen (file=0xb7703345 "libc.so.6", mode=1) at dlopen.c:87
#16 0xb76fa44f in ?? () from /usr/lib/i386-linux-gnu/torsocks/libtorsocks.so
#17 0xb7700352 in tsocks_once ()__
from /usr/lib/i386-linux-gnu/torsocks/libtorsocks.so
#18 0xb76fa25e in tsocks_initialize ()
from /usr/lib/i386-linux-gnu/torsocks/libtorsocks.so
#19 0xb7724c65 in call_init (l=<optimized out>, argc=argc@entry=1,
argv=argv@entry=0xbfb8ce74, env=0xbfb8ce7c) at dl-init.c:72
#20 0xb7724d8e in call_init (env=0xbfb8ce7c, argv=0xbfb8ce74, argc=1,
l=<optimized out>) at dl-init.c:30
#21 _dl_init (main_map=<optimized out>, argc=1, argv=0xbfb8ce74,
env=0xbfb8ce7c) at dl-init.c:120
#22 0xb7715a5f in _dl_start_user () from /lib/ld-linux.so.2
```
It looks like tsocks_initialize() is called when libtorsocks is loaded, it calls tsocks_once() which locks a mutex and then calls dlopen() to get the libc symbols, dlopen() tries to allocate some memory which leads jemalloc (the default allocator for Rust programs) to try to call syscall() (it wants to open a proc file to see if the system overcommits memory or not), which is intercepted by libtorsocks, which leads to another call to tsocks_initialize()... and since the mutex is already locked, it deadlocks.
One way to fix this might be to just let through any syscall() calls that happen during bootstrapping, but i don't know the torsocks code well enough to know if this could cause any dangerous leaks.
**Trac**:
**Username**: larslhttps://gitlab.torproject.org/legacy/trac/-/issues/24081Torsocks logging to a file can cause a crash or corrupt application files.2020-06-13T16:09:51ZTracTorsocks logging to a file can cause a crash or corrupt application files.I ran into problems using torsocks with OpenSSH and tracked down several bugs in torsocks related to logging to a file. Here's a description, a test program to demonstrate the problem, and a patch.
The initial problem was triggered by O...I ran into problems using torsocks with OpenSSH and tracked down several bugs in torsocks related to logging to a file. Here's a description, a test program to demonstrate the problem, and a patch.
The initial problem was triggered by OpenSSH closing all file descriptors above the first three when it starts up. Some programs do that for good programming hygiene and security. See the BSD closefrom() function for background. When a program that does that is run with torsocks configured to log to a file, the log file descriptor is closed but torsocks doesn't notice. It keeps trying to write to the closed descriptor via the log file pointer as the program runs and doesn't detect the resulting write errors. If the file descriptor isn't reused then the log messages are silently lost. But if the descriptor is later opened for writing by the program then the torsocks log messages are written to the program's file!
There is code intended to detect log write errors in log.c function _log_write(), but it doesn't work. The code looks at the return value from fprintf(), but fprintf() always returns success because the file is opened in buffered mode and the return value from a subsequent fflush() is ignored. So the write errors aren't detected.
I added a call to setbuf() in log_init() to set the log file to unbuffered mode and that exposed further problems. Then log_write() sees fprintf() return an error and calls log_destroy() to clean up. log_destroy() calls fclose() to close the logconfig.fp file pointer and frees the malloced logconfig.filepath but doesn't zero them out, so subsequent logging calls still try to write to the closed fp, log_destroy() gets called again, the filepath is free()'d again (double free). Also the fclose() call goes to torsocks_fclose() which may generate another log message, causing a call loop and crash (SEGV due to stack overrun).
The attached test_log_fd_close.c demonstrates the problem and file corruption. It simply closes file descriptors 3-5, creates some test files and closes them without writing to them, then verifies that they are in fact empty. Compile and link the program with the torsocks library and run it with:
test_log_fd_close
to see normal non-failing behavior, or run it with torsocks logging to a file:
TORSOCKS_LOG_FILE_PATH=./log TORSOCKS_LOG_LEVEL=5 test_log_fd_close
to activate the bugs and see application file corruption.
The attached log_fd_close_notify.patch fixes the problems. The changes are:
- Add a function log_fd_close_notify() that can be called to notify the log system when an fd is being closed, so it can gracefully close out the log if necessary. Call it from torsocks_close().
- Add a call to setbuf() in log_init() to make the torsocks log file unbuffered.
- Don't call fclose() in log_destroy() and instead simply zero out the file pointer to stop future accesses to it. Also zero out the filepath pointer after freeing it to eliminate the potential for references to the freed pointer.
- Eliminate another call to fclose() in log_init() just by reordering the existing code. A loop there is unlikely but it seems like a good change to make.
I don't understand the torsocks test system to well enough to add test_log_fd_close.c to it. If it's worthwhile maybe someone else can do that.
**Trac**:
**Username**: cpwcDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org