Torsocks issueshttps://gitlab.torproject.org/tpo/core/torsocks/-/issues2021-07-09T18:32:02Zhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/801Torify+dsocks: A listener connection returned a socket with a mismatched family2021-07-09T18:32:02ZTracTorify+dsocks: A listener connection returned a socket with a mismatched familyWhen i try to torify something trought dsocks-torify.sh it doesn't works.
Example:
dsocks-torify.sh nmap -P0 -v -n 1.2.3.4 -p21 -sV
Starting Nmap 4.50 ( http://insecure.org ) at 2008-08-16 13:45 CEST
Initiating Connect Scan at 13:45
Sc...When i try to torify something trought dsocks-torify.sh it doesn't works.
Example:
dsocks-torify.sh nmap -P0 -v -n 1.2.3.4 -p21 -sV
Starting Nmap 4.50 ( http://insecure.org ) at 2008-08-16 13:45 CEST
Initiating Connect Scan at 13:45
Scanning 87.29.167.157 [1 port]
nmap: (dsocks) couldn't connect to proxy at 127.0.0.1:9050
Discovered open port 21/tcp on 87.29.167.157
Completed Connect Scan at 13:45, 0.14s elapsed (1 total ports)
Host 87.29.167.157 appears to be up ... good.
Interesting ports on 87.29.167.157:
PORT STATE SERVICE
21/tcp open ftp
Nmap done: 1 IP address (1 host up) scanned in 0.204 seconds
this is the entry in the Tor debub log
[info] connection_handle_listener_read(): Bug: A listener connection returned a socket with a mismatched family. Socks listener for addr_family 2 gave us a socket with address family 0. Dropping.
i've the last version of dsocks aviable from darwinports.
Thanks to all!
bye
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: m4rco-David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/6155Import torsocks from google code to torproject.org trac2021-07-09T18:32:02ZproperImport torsocks from google code to torproject.org tracReasons:
* You can not post anonymously to the google code tracker.
* You can not have an anonymous google account, since it requires verification.
* Google code is not accessible from some countries.
* It's Tor standard software, in...Reasons:
* You can not post anonymously to the google code tracker.
* You can not have an anonymous google account, since it requires verification.
* Google code is not accessible from some countries.
* It's Tor standard software, in the torproject.org repository, and you can't really keep track of it there.Robert HoganRobert Hoganhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/6542curl 7.27.0 doesn't work with torsocks2021-07-09T18:32:02Zcypherpunkscurl 7.27.0 doesn't work with torsocksAfter upgrading curl to version 7.27.0, various programs that depend on libcurl (including curl itself) no longer work with torsocks.
All requests are replied to with the "501 Tor is not an HTTP proxy" message. Curiously, the first two ...After upgrading curl to version 7.27.0, various programs that depend on libcurl (including curl itself) no longer work with torsocks.
All requests are replied to with the "501 Tor is not an HTTP proxy" message. Curiously, the first two bytes of the response are 0x05 0x00 as you would expect from a valid SOCKS5 reply.
Perhaps there's some poor buffer management lurking around.
Thanks.
Software versions:
Linux 3.4.7-1-ARCH i686
curl 7.27.0
torsocks 1.2
tor 0.2.2.37David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/7564[PATCH] Use libdir instead of prefix in torsocks wrapper2021-07-09T18:32:02ZTrac[PATCH] Use libdir instead of prefix in torsocks wrapperUse the autotools configure standard for assigning the library directory.
**Trac**:
**Username**: robinsonUse the autotools configure standard for assigning the library directory.
**Trac**:
**Username**: robinsonhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/8006Unnecessary test in torsocks script2021-07-09T18:32:02ZTracUnnecessary test in torsocks scriptTorsocks suggests running with no arguments to start a shell, however the launcher script errors when no arguments are passed. Attached patch fixes this.
**Trac**:
**Username**: dmaTorsocks suggests running with no arguments to start a shell, however the launcher script errors when no arguments are passed. Attached patch fixes this.
**Trac**:
**Username**: dmahttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/8038Allow torsocks to interact with TBB in a useful way2021-07-09T18:32:02ZMatthew FinkelAllow torsocks to interact with TBB in a useful wayTBB will select a random SOCKS port, torsocks should provide a way to find/be given this port number. Asking users to retrieve it from Data/Tor/port.conf and modify torsocks.conf is nonobvious.TBB will select a random SOCKS port, torsocks should provide a way to find/be given this port number. Asking users to retrieve it from Data/Tor/port.conf and modify torsocks.conf is nonobvious.https://gitlab.torproject.org/tpo/core/torsocks/-/issues/8043various torsocks/ttdnsd errors and discrepancies2021-07-09T18:32:02ZTracvarious torsocks/ttdnsd errors and discrepanciesFor the past two weeks I have been trying to integrate ttdnsd/torsocks combo into my system, allowing for proper DNS resolution to take place over Tor - all this was prompted by my report on bug legacy/trac#7797. Unfortunately, I've hit ...For the past two weeks I have been trying to integrate ttdnsd/torsocks combo into my system, allowing for proper DNS resolution to take place over Tor - all this was prompted by my report on bug legacy/trac#7797. Unfortunately, I've hit a brick wall.
In a nutshell, I have found a few discrepancies/errors in both torsocks and ttdnsd and I also have a problem trying to force torsocks to talk to tor.
Since in the "Component" section on this report form there is no place to select ttdnsd, I am doing this report for torsocks, as well as ttdnsd.
1. Torsocks config file environment variable: ttdnsd expects that to be defined in TSOCKS_CONF_FILE, while torsocks also have 2 different definitions of it: TORSOCKS_CONFFILE (torsocks.8) and TORSOCKS_CONF_FILE (the binary .so file). The latter, when specified, works.
Also, that environment variable is only honoured BEFORE chroot (so the full path to this file MUST be specified) - something not mentioned in either of torsocks or ttdnsd man pages.
2. Even though I am using all 3 environment variables, pointing to the right torsocks.conf file, I still can't make it work. Here is my config:
torsocks.conf
=============
local = 127.0.0.0/255.0.0.0
local = 10.0.0.0/255.0.0.0
server = 127.0.0.1
server_port = 19050
ttdnsd.conf
===========
8.8.8.8
torrc (relevant parts only are included)
========================================
SocksPort 19050
SocksListenAddress 127.0.0.1:19050
DNSPort 53
DNSListenAddress 127.0.0.3:53
SocksPolicy accept 127.0.0.1:* # localhost
SocksPolicy accept 127.0.0.2:* # localhost
SocksPolicy accept 127.0.0.3:* # localhost
SocksPolicy accept 10.0.0.0/8:*
SocksPolicy reject *:*
My tor proxy service is running on 127.0.0.1:19050. TTDNSD is running on 127.0.0.2:53, while tor's own DNS is running on 127.0.0.3:53.
When not using TORSOCKS_DEBUG during ttdnsd start, after the initial setup I get the following message when a DNS request is sent to ttdnsd from the command line (using dig):
07:37:32 libtorsocks(2507): Call to connect received on completed request 4
07:37:32 libtorsocks(2507): sendto: Connection is a UDP or ICMP stream, may be a DNS request or other form of leak: rejecting.
When TORSOCKS_DEBUG=1 is used, I get this:
libtorsocks: Got connection request
libtorsocks: Intercepted call to getpeername
libtorsocks: Intercepted call to poll
libtorsocks: Intercepted call to poll
libtorsocks: Got connection request
libtorsocks: Call to connect received on completed request 4
libtorsocks: Got sendto request
libtorsocks: sendto: Connection is a UDP or ICMP stream, may be a DNS request or other form of leak: rejecting.
libtorsocks: Got sendto request
libtorsocks: sendto: Connection is a UDP or ICMP stream, may be a DNS request or other form of leak: rejecting.
[...ad nauseum...]
When I increase the debug level (TORSOCKS_DEBUG=255) I get a different message, though the effect is the same:
07:40:43 libtorsocks(2611): No requests waiting, calling real close
07:40:43 libtorsocks(2611): No requests waiting, calling real close
07:41:01 libtorsocks(2611): Got connection request
07:41:01 libtorsocks(2611): sin_family: 2
07:41:01 libtorsocks(2611): sockopt: 1
07:41:01 libtorsocks(2611): checking if address: 8.8.8.8 is local
07:41:01 libtorsocks(2611): localnet addr: 255.255.0.0
07:41:01 libtorsocks(2611): localip addr: 192.168.0.0
[...]
07:41:01 libtorsocks(2611): address: 8.8.8.8 is not local
07:41:01 libtorsocks(2611): Intercepted call to getpeername
07:41:01 libtorsocks(2611): Call to getpeername for fd 4
07:41:01 libtorsocks(2611): Got connection request for socket 4 to 8.8.8.8
07:41:01 libtorsocks(2611): Picking appropriate server for 8.8.8.8
07:41:01 libtorsocks(2611): Picked server 127.0.0.1 for connection
07:41:01 libtorsocks(2611): checking if address: 127.0.0.1 is local
[...]
07:41:01 libtorsocks(2611): address: 127.0.0.0 is local
07:41:01 libtorsocks(2611): Beginning handle loop for socket 4
07:41:01 libtorsocks(2611): In request handle loop for socket 4, current state of request is 0
07:41:01 libtorsocks(2611): Connecting to 127.0.0.1 port 19050
07:41:01 libtorsocks(2611): Connect returned -1, errno is 115
07:41:01 libtorsocks(2611): Error 2 attempting to connect to SOCKS server (No such file or directory)
07:41:01 libtorsocks(2611): Handle loop completed for socket 4 in state 14, returning 2
connect status: No such file or directory
We've loaded 8.8.8.8 as a nameserver.
1 nameservers loaded
tsocks_conf: torsocks.conf
log init...
log file opened: ttdnsd.log
log file opened as fd: 4
duping fds... check ttdnsd.log from here on out...
dup2 says: 1
dup2 says: 2
closing original fd: 4...
starting server...
watching 1 file descriptors
1 file descriptors became ready
received request of 37 bytes, id = 4927
adding new request (id=4927)
new request added at pos: 436
using request slot 436
updating id: 16147
selecting peer
peer selected: -1
connecting to 8.8.8.8 on port 53
watching 2 file descriptors
1 file descriptors became ready
peer 8.8.8.8 in bad state 0
watching 2 file descriptors
1 file descriptors became ready
peer 8.8.8.8 in bad state 0
watching 2 file descriptors
[...ad nauseum...]
I have absolutely no idea what the above errors mean exactly!
The connection attempts were made from 127.0.0.1:XXXXX (dig) to 127.0.0.2:53 (ttdnsd) using UDP, and then I could see from /proc/net/nf_conntrack that a separate connection was indeed made (status is ASSURED) to the tor proxy (127.0.0.1:19050) from torsocks (127.0.0.2:XXXXX) using TCP.
**Trac**:
**Username**: mr-4https://gitlab.torproject.org/tpo/core/torsocks/-/issues/8052merge torify trac component with torsocks trac component2021-07-09T18:32:02Zpropermerge torify trac component with torsocks trac componentWhat is the torify trac component good for nowadays? Merge it with the torsocks trac component?
[[TicketQuery(component=Torify,order=status,format=table,col=id|summary|status|priority|keywords|owner|)]]What is the torify trac component good for nowadays? Merge it with the torsocks trac component?
[[TicketQuery(component=Torify,order=status,format=table,col=id|summary|status|priority|keywords|owner|)]]https://gitlab.torproject.org/tpo/core/torsocks/-/issues/8063torsocks on doesn't work.2021-07-09T18:32:03ZTractorsocks on doesn't work.Hi,
The "torsocks on" subcommand exports the LD_PRELOAD (Linux) or DYLD_INSERT_LIBRARIES (OSX), but as the torsocks script finishes in bash the exports are lost, as the control returns to the parent process (the bash shell) of the torso...Hi,
The "torsocks on" subcommand exports the LD_PRELOAD (Linux) or DYLD_INSERT_LIBRARIES (OSX), but as the torsocks script finishes in bash the exports are lost, as the control returns to the parent process (the bash shell) of the torsocks script.
The easiest fix is to start a new shell from the "torsocks on" subcommand execution.
Oscar
**Trac**:
**Username**: okoeroohttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/8066usewithtor + irssi + ssl = "Socks version 22 not recognized"2020-06-27T14:12:16ZRoger Dingledineusewithtor + irssi + ssl = "Socks version 22 not recognized"Set up your ~/.irssi/config with
```
servers = (
{
address = "irc.oftc.net";
chatnet = "oftc";
#port = "6667";
port = "6697";
use_ssl = "yes";
# ssl_cert = "~/.irssi/certs/[NICK].pem";
# ssl_verify = "yes";
...Set up your ~/.irssi/config with
```
servers = (
{
address = "irc.oftc.net";
chatnet = "oftc";
#port = "6667";
port = "6697";
use_ssl = "yes";
# ssl_cert = "~/.irssi/certs/[NICK].pem";
# ssl_verify = "yes";
# ssl_cafile = "~/.irssi/certs/CAs.pem";
autoconnect = "yes";
}
);
```
and then run
```
usewithtor irssi
```
Your Tor client will log something like
```
Jan 27 17:43:52.000 [warn] Socks version 22 not recognized. (Tor is not an http proxy.)
Jan 27 17:43:52.000 [warn] Fetching socks handshake failed. Closing.
```
and your irssi will complain with something like
```
18:06 -!- Irssi: Looking up irc.oftc.net
18:06 -!- Irssi: Connecting to irc.oftc.net [140.211.166.64] port 6697
18:06 -!- Irssi: warning SSL handshake failed: Connection reset by peer
18:06 -!- Irssi: Connection lost to irc.oftc.net
```
What's happening behind the scenes is that your irssi is attempting a connect, getting an einprogress (presumably since it's non-blocking), sending the ssl handshake right then, and then later torsocks tries to inject the socks handshake. Oops.
```
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4
fcntl(4, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
setsockopt(4, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(4, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
getsockopt(4, SOL_SOCKET, SO_TYPE, [1], [4]) = 0
getpeername(4, 0x7fff04186010, [16]) = -1 ENOTCONN (Transport endpoint is not connected)
connect(4, {sa_family=AF_INET, sin_port=htons(9050), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
fstat(4, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0
fcntl(4, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
...
write(4, "\26\3\1\1;\1\0\0017\3\3Q\5\253\315\302\4\246F_\255\232\205\206h\24\345\351\310e'\r"..., 320) = 320
read(4, 0x19a9770, 7) = -1 EAGAIN (Resource temporarily unavailable)
...
sendto(4, "\4\1\32)\0\0\0\1arma\0irc.oftc.net\0", 26, 0, NULL, 0) = 26
recvfrom(4, "", 8, 0, NULL, NULL) = 0
...
close(4) = 0
```https://gitlab.torproject.org/tpo/core/torsocks/-/issues/8067Three harmless compiler warnings in 1.2 and 1.32020-06-27T14:12:16ZRoger DingledineThree harmless compiler warnings in 1.2 and 1.3```
torsocks.c: In function ‘torsocks_select_guts’:
torsocks.c:428:9: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable]
torsocks.c: In function ‘torsocks_poll_guts’:
torsocks.c:613:9: warning: variable ‘rc’ set but not ...```
torsocks.c: In function ‘torsocks_select_guts’:
torsocks.c:428:9: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable]
torsocks.c: In function ‘torsocks_poll_guts’:
torsocks.c:613:9: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable]
...
test_torsocks.c:144:14: warning: ‘txtquery’ defined but not used [-Wunused-function]
```
(on debian wheezy)Jacob AppelbaumJacob Appelbaumhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/8068Missing symbol namespacing2020-06-27T14:12:16ZDavid Gouletdgoulet@torproject.orgMissing symbol namespacingBy doing this command we can see a bunch of symbols that torsocks should *not* try to overload:
```
$ nm .libs/libtorsocks.so | grep " T "
```
Here is the list that I think should be hidden:
```
0000000000007190 T count_netmask_bits
0...By doing this command we can see a bunch of symbols that torsocks should *not* try to overload:
```
$ nm .libs/libtorsocks.so | grep " T "
```
Here is the list that I think should be hidden:
```
0000000000007190 T count_netmask_bits
0000000000009fa0 T find_socks_request
0000000000009320 T get_next_dead_address
00000000000095d0 T get_pool_entry
0000000000007050 T get_uint16
0000000000007060 T get_uint32
0000000000006a70 T getipnodebyname
0000000000009ff0 T handle_request
00000000000090e0 T init_pool
0000000000009300 T is_dead_address
0000000000007470 T is_local
0000000000009f30 T kill_socks_request
0000000000009e70 T new_socks_request
0000000000009950 T our_getaddrinfo
00000000000096a0 T our_gethostbyaddr
0000000000009860 T our_gethostbyname
0000000000009a40 T our_getipnodebyname
00000000000075d0 T pick_server
0000000000007d90 T read_config
0000000000007090 T resolve_ip
0000000000009350 T search_pool_for_name
0000000000007130 T set_log_options
0000000000007070 T set_uint16
0000000000007080 T set_uint32
00000000000071c0 T show_msg
00000000000093c0 T store_pool_entry
0000000000007700 T strsplit
```
These symbols should at least have a torsocks_* prefix or else they might clash with existing symbols linked to the binary called with torsocks altering its behavior which is real *BAD*.
The quickest way of fixing that would be to add the GCC hidden attribute to each function call or else try to make them static in the code base.
I've notice that with the "read_config" symbol that was overloaded in my software with the current git head (519d3be56348c3d965c286a7c04adce3dd556411).
Thanks!
DavidJacob AppelbaumJacob Appelbaumhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/8070Memory leaks on error in dead_pool.c2020-06-27T14:12:16ZDavid Gouletdgoulet@torproject.orgMemory leaks on error in dead_pool.cIn parse_socks5_resolve_ptr_response() (dead_pool.c +325), the **result_hostname is allocated then passed to recv(). On error (r < 0) or with an orderly shutdown (r = 0) the memory is not freed causing the memory leak.
Here is a small p...In parse_socks5_resolve_ptr_response() (dead_pool.c +325), the **result_hostname is allocated then passed to recv(). On error (r < 0) or with an orderly shutdown (r = 0) the memory is not freed causing the memory leak.
Here is a small patch fixing the leak.Jacob AppelbaumJacob Appelbaumhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/8137add option to allow connections to local addresses2020-06-27T14:12:16Zproperadd option to allow connections to local addresses> libtorsocks(11014): connect: Connection is to a local address (192.168.0.10), may be a TCP DNS request to a local DNS server so have to reject to be safe. Please report a bug to http://code.google.com/p/torsocks/issues/entry if this is...> libtorsocks(11014): connect: Connection is to a local address (192.168.0.10), may be a TCP DNS request to a local DNS server so have to reject to be safe. Please report a bug to http://code.google.com/p/torsocks/issues/entry if this is preventing a program from working properly with torsocks.
Please add an option to allow connections to local addresses. Tor doesn't always run on 127.0.0.1, sometimes it's run on a machine on local LAN. This is also the case for Whonix, which is a two machine approach, where Tor runs by design on another machine on local LAN.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/8272torsocks.c warning says to file bugs at code.google.com2020-06-27T14:12:15ZRoger Dingledinetorsocks.c warning says to file bugs at code.google.comhttps://gitweb.torproject.org/torsocks.git/blob/HEAD:/src/torsocks.c#l280 says
```
show_msg(MSGERR, "connect: Connection is to a local address (%s), may be a "
"TCP DNS request to a local DNS server so have...https://gitweb.torproject.org/torsocks.git/blob/HEAD:/src/torsocks.c#l280 says
```
show_msg(MSGERR, "connect: Connection is to a local address (%s), may be a "
"TCP DNS request to a local DNS server so have to reject to be safe. "
"Please report a bug to http://code.google.com/p/torsocks/issues/entry if "
"this is preventing a program from working properly with torsocks.\n", buf);
```
This is the wrong place to file torsocks bugs now, right?Jacob AppelbaumJacob Appelbaumhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/8316cvs via torsocks causes a segfault in libtorsocks.so2020-06-27T14:12:15Zintrigericvs via torsocks causes a segfault in libtorsocks.soTrying to run cvs via torsocks causes a segfault in libtorsocks.so.
Reproduced with Debian's torsocks 1.2-3 and 1.3-1 this way:
`torsocks cvs -d :pserver:anonymous@anonscm.debian.org:/cvs/webwml checkout webwml/english/doc`.
More infor...Trying to run cvs via torsocks causes a segfault in libtorsocks.so.
Reproduced with Debian's torsocks 1.2-3 and 1.3-1 this way:
`torsocks cvs -d :pserver:anonymous@anonscm.debian.org:/cvs/webwml checkout webwml/english/doc`.
More information, including a backtrace, can be found on the original bug report: http://bugs.debian.org/684580Jacob AppelbaumJacob Appelbaumhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/8495Please remove "Call to connect received on completed request 3"2020-06-27T14:12:14ZproperPlease remove "Call to connect received on completed request 3"Please get ride of "Call to connect received on completed request 3", perhaps only show it when TORSOCKS_DEBUG=1. (non-fatal error)
Debian Wheezy 32 bit.
(sudo apt-get install mixmaster)
```
root@host:~# export TORSOCKS_DEBUG=1
root@ho...Please get ride of "Call to connect received on completed request 3", perhaps only show it when TORSOCKS_DEBUG=1. (non-fatal error)
Debian Wheezy 32 bit.
(sudo apt-get install mixmaster)
```
root@host:~# export TORSOCKS_DEBUG=1
root@host:~# export TORSOCKS_CONF_FILE=/etc/torsocks.conf
root@host:~# torsocks /usr/bin/mixmaster-update
11:49:04 libtorsocks(21188): WARNING: The symbol getipnodebyname() was not found in any shared library with the reported error: Not Found!
Also, we failed to find the symbol __getipnodebyname() with the reported error: Not Found
11:49:04 libtorsocks(21189): WARNING: The symbol getipnodebyname() was not found in any shared library with the reported error: Not Found!
Also, we failed to find the symbol __getipnodebyname() with the reported error: Not Found
11:49:04 libtorsocks(21186): WARNING: The symbol getipnodebyname() was not found in any shared library with the reported error: Not Found!
Also, we failed to find the symbol __getipnodebyname() with the reported error: Not Found
11:49:04 libtorsocks(21186): Call to connect received on completed request 3
```
```
root@host:~# export TORSOCKS_DEBUG=0
root@host:~# torsocks /usr/bin/mixmaster-update
11:49:15 libtorsocks(21190): Call to connect received on completed request 3
```
```
# This is the configuration for libtorsocks (transparent socks) for use
# with tor, which is providing a socks server on port 9050 by default.
#
# Lines beginning with # and blank lines are ignored
#
# The basic idea is to specify:
# - Local subnets - Networks that can be accessed directly without
# assistance from a socks server
# - Paths - Paths are basically lists of networks and a socks server
# which can be used to reach these networks
# - Default server - A socks server which should be used to access
# networks for which no path is available
# Much more documentation than provided in these comments can be found in
# torsocks.conf(5) and usewithtor(1) manpages.
# We specify local as 127.0.0.0 - 127.191.255.255 because the
# Tor MAPADDRESS virtual IP range is the rest of net 127.
# Torsocks also treats as local all the subnets that Tor does.
#local = 127.0.0.0/255.128.0.0
#local = 127.128.0.0/255.192.0.0
#local = 169.254.0.0/255.255.0.0
#local = 172.16.0.0/255.240.0.0
#local = 192.168.0.0/255.255.0.0
# Default server
# For connections that aren't to the local subnets
# the server at 127.0.0.1 should be used (again, hostnames could be used
# too, see note above)
server = 192.168.0.10
# SOCKS server type defaults to 4
server_type = 5
# The port defaults to 1080 but I've stated it here for clarity
server_port = 9155
# Username and password (if required on a SOCKSv5 server)
#default_user =
#default_pass =
# Paths
# For this example this machine needs to access 150.0.0.0/255.255.0.0 as
# well as port 80 on the network 150.1.0.0/255.255.0.0 through
# the socks 5 server at 10.1.7.25 (if this machines hostname was
# "socks.hello.com" we could also specify that, unless --disable-hostnames
# was specified to ./configure).
#path {
# reaches = 150.0.0.0/255.255.0.0
# reaches = 150.1.0.0:80/255.255.0.0
# server = 10.1.7.25
# server_type = 5
# default_user = delius
# default_pass = hello
#}
#
```Jacob AppelbaumJacob Appelbaumhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/8585Figure out why weechat+ssl don't play nice with torsocks2020-06-27T14:12:14ZMatthew FinkelFigure out why weechat+ssl don't play nice with torsocksweechat is socks aware, but it should also be usable with torsocks. On initial testing, weechat's irc plugin closes its connections and attempts to continue the ssl handshake on newly established conns. This could be a misinterpretation,...weechat is socks aware, but it should also be usable with torsocks. On initial testing, weechat's irc plugin closes its connections and attempts to continue the ssl handshake on newly established conns. This could be a misinterpretation, though.
```
00:00:47 irc.oftc.net -- | irc: connecting to server irc.oftc.net/6697 (SSL)...
00:01:20 irc.oftc.net =!= | irc: TLS handshake failed
00:01:20 irc.oftc.net =!= | irc: error: The TLS connection was non-properly terminated.
00:01:20 irc.oftc.net -- | irc: reconnecting to server in 10 second
```
```
Mar 25 00:00:48.000 [debug] connection_ap_handshake_process_socks(): entered.
Mar 25 00:00:48.000 [debug] parse_socks(): socks5: checking request
Mar 25 00:00:48.000 [debug] parse_socks(): socks5: fqdn address type
Mar 25 00:00:48.000 [debug] connection_ap_handshake_rewrite_and_attach(): Client asked for irc.oftc.net:6697
...
Mar 25 00:00:49.600 [info] connection_ap_handshake_send_begin(): Sending relay cell 0 to begin stream 24137.
...
Mar 25 00:00:50.160 [debug] relay_lookup_conn(): found conn for stream 24137.
Mar 25 00:00:50.160 [debug] circuit_receive_relay_cell(): Sending to origin.
Mar 25 00:00:50.160 [debug] connection_edge_process_relay_cell(): Now seen 926 relay cells here (command 4, stream 24137).
Mar 25 00:00:50.160 [info] connection_edge_process_relay_cell_not_open(): 'connected' received after 1 seconds.
Mar 25 00:00:50.160 [info] addressmap_register(): Temporary addressmap ('irc.oftc.net' to '140.211.166.64') not performed, since it's already mapped to '50.197.126.29'
...
Mar 25 00:01:20.280 [debug] connection_or_process_cells_from_inbuf(): 12: starting, inbuf_datalen 512 (0 pending in tls object).
Mar 25 00:01:20.280 [debug] channel_queue_cell(): Directly handling incoming cell_t 0x38e973ff140 for channel 0x1e0c141140 (global ID 2)
Mar 25 00:01:20.280 [debug] circuit_get_by_circid_channel_impl(): circuit_get_by_circid_channel_impl() returning circuit 0x1e0c22fcd0 for circ_id 3495, channel ID 2 (0x1e0c141140)
Mar 25 00:01:20.280 [debug] relay_lookup_conn(): found conn for stream 24137.
Mar 25 00:01:20.280 [debug] circuit_receive_relay_cell(): Sending to origin.
Mar 25 00:01:20.280 [debug] connection_edge_process_relay_cell(): Now seen 929 relay cells here (command 3, stream 24137).
Mar 25 00:01:20.280 [info] connection_edge_process_relay_cell(): 13: end cell (closed normally) for stream 24137. Removing stream.
Mar 25 00:01:20.280 [debug] connection_or_process_cells_from_inbuf(): 12: starting, inbuf_datalen 0 (0 pending in tls object).
Mar 25 00:01:20.280 [debug] conn_close_if_marked(): Cleaning up connection (fd 13).
Mar 25 00:01:20.280 [debug] connection_remove(): removing socket 13 (type Socks), n_conns now 5
Mar 25 00:01:20.280 [debug] connection_free_(): closing fd 13.
...
Mar 25 00:01:30.560 [debug] connection_handle_listener_read(): Connection accepted on socket 13 (child of fd 6).
Mar 25 00:01:30.560 [debug] connection_add_impl(): new conn type Socks, socket 13, address 127.0.0.1, n_conns 5.
Mar 25 00:01:30.560 [debug] connection_ap_handshake_process_socks(): entered.
Mar 25 00:01:30.560 [debug] parse_socks(): socks5: accepted method 0 (no authentication)
Mar 25 00:01:30.560 [debug] connection_ap_handshake_process_socks(): socks handshake not all here yet.
Mar 25 00:01:30.560 [debug] connection_ap_handshake_process_socks(): entered.
Mar 25 00:01:30.560 [debug] connection_ap_handshake_process_socks(): socks handshake not all here yet.
Mar 25 00:01:30.560 [debug] connection_ap_handshake_process_socks(): entered.
Mar 25 00:01:30.560 [debug] parse_socks(): socks5: checking request
Mar 25 00:01:30.560 [debug] parse_socks(): socks5: fqdn address type
Mar 25 00:01:30.560 [debug] conn_write_callback(): socket 13 wants to write.
Mar 25 00:01:30.560 [debug] conn_read_callback(): socket 13 wants to read.
Mar 25 00:01:30.560 [debug] connection_ap_handshake_rewrite_and_attach(): Client asked for irc.oftc.net:6697
Mar 25 00:01:31.000 [debug] conn_write_callback(): socket 13 wants to write.
...
Mar 25 00:01:31.000 [info] connection_edge_process_relay_cell_not_open(): 'connected' received after 1 seconds.
Mar 25 00:01:31.000 [info] addressmap_register(): Temporary addressmap ('irc.oftc.net' to '140.211.166.64') not performed, since it's already mapped to '50.197.126.29'
...
Mar 25 00:01:31.000 [debug] conn_write_callback(): socket 13 wants to write.
Mar 25 00:01:33.440 [debug] conn_read_callback(): socket 13 wants to read.
Mar 25 00:01:33.440 [debug] read_to_chunk(): Encountered eof on fd 13
Mar 25 00:01:33.440 [info] connection_edge_reached_eof(): conn (fd 13) reached eof. Closing.
Mar 25 00:01:33.440 [debug] connection_edge_end(): Sending end on conn (fd 13).
Mar 25 00:01:33.440 [debug] append_cell_to_circuit_queue(): Made a circuit active.
Mar 25 00:01:33.440 [debug] channel_flush_from_first_active_circuit(): Made a circuit inactive.
Mar 25 00:01:33.440 [debug] conn_close_if_marked(): Cleaning up connection (fd 13).
Mar 25 00:01:33.440 [debug] connection_remove(): removing socket 13 (type Socks), n_conns now 5
Mar 25 00:01:33.440 [debug] connection_free_(): closing fd 13.
```
The tcpdump output is interesting too. Six of these sent less than a second apart without response from Tor before failing
```
0x0020: 8018 0156 fef2 0000 0101 080a 01ea d3d5 ...V............
0x0030: 01ea d3d4 1603 0000 c501 0000 c103 0351 ...............Q
0x0040: 4e50 49b3 f165 b434 0a72 0e07 dafe da5f NPI..e.4.r....._
0x0050: e0ab 06fb 1d07 c153 1cf4 7445 6c03 0700 .......S..tEl...
0x0060: 0050 c02b c009 c023 c02c c00a c024 c008 .P.+...#.,...$..
0x0070: c02f c013 c027 c030 c014 c012 009c 002f ./...'.0......./
0x0080: 003c 0035 003d 0041 0084 000a 0005 0004 .<.5.=.A........
0x0090: 009e 0033 0067 0039 006b 0045 0088 0016 ...3.g.9.k.E....
0x00a0: 00a2 0032 0040 0038 006a 0044 0087 0013 ...2.@.8.j.D....
0x00b0: 0066 0100 0048 0005 0005 0100 0000 00ff .f...H..........
0x00c0: 0100 0100 0023 0000 000a 000c 000a 0013 .....#..........
0x00d0: 0015 0017 0018 0019 000b 0002 0100 000d ................
0x00e0: 001c 001a 0401 0402 0403 0501 0503 0601 ................
0x00f0: 0603 0301 0302 0303 0201 0202 0203 ..............
```Matthew FinkelMatthew Finkelhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/8597Catch res_n* functions on systems that support them2020-06-27T14:12:14ZMatthew FinkelCatch res_n* functions on systems that support themWe should overload the res_n* functions on systems that support them. Currently we catch res_query and it's family, but not the newer res_n* set. They've been around for a while now, there are likely programs that could be trying to perf...We should overload the res_n* functions on systems that support them. Currently we catch res_query and it's family, but not the newer res_n* set. They've been around for a while now, there are likely programs that could be trying to perform dns resolution using udp and failing.Matthew FinkelMatthew Finkelhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/8659INSTALL references obsolete Makefile.cvs2020-06-27T14:12:14ZintrigeriINSTALL references obsolete Makefile.cvsIt was reported to Debian (http://bugs.debian.org/704861) that torsocks' INSTALL file refers to the non-existent Makefile.cvs file.It was reported to Debian (http://bugs.debian.org/704861) that torsocks' INSTALL file refers to the non-existent Makefile.cvs file.Jacob AppelbaumJacob Appelbaumhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/8744The show_msg() does not save correctly the errno value2020-06-27T14:12:13ZDavid Gouletdgoulet@torproject.orgThe show_msg() does not save correctly the errno valueThe "show_msg" function tries to save the errno of the caller but there
are multiple call sites ***before*** that can override the errno value.
This was actually the cause of some other bugs in the past, one being
https://trac.torprojec...The "show_msg" function tries to save the errno of the caller but there
are multiple call sites ***before*** that can override the errno value.
This was actually the cause of some other bugs in the past, one being
https://trac.torproject.org/projects/tor/ticket/8043.
I think the best way to deal with this issue is for the caller to make sure errno is saved. In some situations, we might NOT want this function to restore a previous errno so it should not set it.Jacob AppelbaumJacob Appelbaumhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/8745Add thread safe support with documentation2020-06-27T14:12:13ZDavid Gouletdgoulet@torproject.orgAdd thread safe support with documentationAt the moment, torsocks does not seems to be thread safe so this would be a nice feature to have but in the meantime, it should be documented for the user to understand the limitations.At the moment, torsocks does not seems to be thread safe so this would be a nice feature to have but in the meantime, it should be documented for the user to understand the limitations.Jacob AppelbaumJacob Appelbaumhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/8754Remove mentions of code.google.com2020-06-27T14:12:13ZDavid Gouletdgoulet@torproject.orgRemove mentions of code.google.com./README
./src/torsocks.c
./test/expectedresults.txt./README
./src/torsocks.c
./test/expectedresults.txtJacob AppelbaumJacob Appelbaumhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/9745libtorsocks symbol was not found2020-06-27T14:12:13ZTraclibtorsocks symbol was not foundWhile I am able to establish a connection, I and get the following message when using !`torify` or when I run !`torsocks wget google.com`.
```
$ torify ssh user@domain.com
16:01:03 libtorsocks(5407): The symbol res_query() was not found...While I am able to establish a connection, I and get the following message when using !`torify` or when I run !`torsocks wget google.com`.
```
$ torify ssh user@domain.com
16:01:03 libtorsocks(5407): The symbol res_query() was not found in any shared library. The error reported was: not found!
16:01:03 libtorsocks(5407): The symbol res_search() was not found in any shared library. The error reported was: not found!
16:01:03 libtorsocks(5407): The symbol res_send() was not found in any shared library. The error reported was: not found!
16:01:03 libtorsocks(5407): The symbol res_querydomain() was not found in any shared library. The error reported was: not found!
16:01:03 libtorsocks(5408): The symbol res_query() was not found in any shared library. The error reported was: not found!
16:01:03 libtorsocks(5408): The symbol res_search() was not found in any shared library. The error reported was: not found!
16:01:03 libtorsocks(5408): The symbol res_send() was not found in any shared library. The error reported was: not found!
16:01:03 libtorsocks(5408): The symbol res_querydomain() was not found in any shared library. The error reported was: not found!
user@domain.com's password:
```
```
$ torsocks wget google.com
15:59:02 libtorsocks(5392): The symbol res_query() was not found in any shared library. The error reported was: not found!
15:59:02 libtorsocks(5392): The symbol res_search() was not found in any shared library. The error reported was: not found!
15:59:02 libtorsocks(5392): The symbol res_send() was not found in any shared library. The error reported was: not found!
15:59:02 libtorsocks(5392): The symbol res_querydomain() was not found in any shared library. The error reported was: not found!
15:59:02 libtorsocks(5393): The symbol res_query() was not found in any shared library. The error reported was: not found!
15:59:02 libtorsocks(5393): The symbol res_search() was not found in any shared library. The error reported was: not found!
15:59:02 libtorsocks(5393): The symbol res_send() was not found in any shared library. The error reported was: not found!
15:59:02 libtorsocks(5393): The symbol res_querydomain() was not found in any shared library. The error reported was: not found!
15:59:02 libtorsocks(5390): The symbol res_query() was not found in any shared library. The error reported was: not found!
15:59:02 libtorsocks(5390): The symbol res_search() was not found in any shared library. The error reported was: not found!
15:59:02 libtorsocks(5390): The symbol res_send() was not found in any shared library. The error reported was: not found!
15:59:02 libtorsocks(5390): The symbol res_querydomain() was not found in any shared library. The error reported was: not found!
--2013-09-14 15:59:02-- http://google.com/
Resolving google.com (google.com)... 74.125.226.132
Connecting to google.com (google.com)|74.125.226.132|:80... connected.
HTTP request sent, awaiting response...
```
```
$ uname -a
Linux linuxServer 3.8.0-29-generic #42-Ubuntu SMP Tue Aug 13 23:12:18 UTC 2013 i686 athlon i686 GNU/Linux
```
**Trac**:
**Username**: x000111Jacob AppelbaumJacob Appelbaumhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/10119libtorsocks, torify, __res__query() (and a few others) symbol not found ERROR2020-06-27T14:12:13ZTraclibtorsocks, torify, __res__query() (and a few others) symbol not found ERRORRunning torify on anything I try results in a successful connection, but lots of warnings.
Input:
`torify curl icanhazip.com`
Results:
`17:29:06 libtorsocks(21277): WARNING: The symbol res_query() was not found in any shared library wi...Running torify on anything I try results in a successful connection, but lots of warnings.
Input:
`torify curl icanhazip.com`
Results:
`17:29:06 libtorsocks(21277): 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`
`17:29:06 libtorsocks(21277): 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`
`17:29:06 libtorsocks(21277): 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`
`17:29:06 libtorsocks(21277): 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`
`17:29:06 libtorsocks(21278): 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`
`17:29:06 libtorsocks(21278): 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`
`17:29:06 libtorsocks(21278): 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`
`17:29:06 libtorsocks(21278): 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`
`<expected output from curl here>`
It does this with `torify ssh` also, except the errors are spewed out twice.
I've tried to updating to the dev-release, hoping it would fix this but it didn't help. It has the same output.
**Trac**:
**Username**: cjwelbornDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/11090torsocks should log errors to stderr and not stdout2020-06-27T14:12:13ZXimin Luotorsocks should log errors to stderr and not stdouttorsocks 2.0.0-rc3
I get stuff like this on stdout:
```
[Feb 28 14:05:16] WARNING torsocks[22952]: Non TCP inet socket denied. Tor network can't handle it. (in tsocks_socket() at socket.c:40)
```
Logging to stdout interferes with the ...torsocks 2.0.0-rc3
I get stuff like this on stdout:
```
[Feb 28 14:05:16] WARNING torsocks[22952]: Non TCP inet socket denied. Tor network can't handle it. (in tsocks_socket() at socket.c:40)
```
Logging to stdout interferes with the output of the underlying program, and is generally a bad idea.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/11205[PATCH] gethostbyname2 needs to be supported in addition to gethostbyname2020-06-27T14:12:13Zyurivict271[PATCH] gethostbyname2 needs to be supported in addition to gethostbynameRepost of the bug from the old bug repotring system: https://code.google.com/p/torsocks/issues/detail?id=60
On some systems, like FreeBSD, function gethostbyname2(3) is defined in addition to gethostbyname(3). Here is its signature:
...Repost of the bug from the old bug repotring system: https://code.google.com/p/torsocks/issues/detail?id=60
On some systems, like FreeBSD, function gethostbyname2(3) is defined in addition to gethostbyname(3). Here is its signature:
struct hostent *
gethostbyname2(const char *name, int af);
If the process uses gethostbyname2 instead of gethostbyname for the name resolution, it doesn't go through SOCKS5 and connection fails.
Need to support it.
Particularly, mplayer configures itself to use gethostbyname2 on FreeBSD, and therefore by default doesn't work with libtorsocks.
Implemented gethost by name in case of tcp v4, v6 is not yet implemented.
Tested with the streams played by mplayer. DNS resolution works fine.
torsocks-1.2_1Jacob AppelbaumJacob Appelbaumhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/11456'make test' should run the tests2020-06-27T14:12:12ZRoger Dingledine'make test' should run the teststorsocks appears to have tests in its tests/ directory. There's even a tests/run.sh that, when I run it, gives me a cryptic statement about testlists, but no hint about where I can find a testlist. How do I run them?
And can we hook tha...torsocks appears to have tests in its tests/ directory. There's even a tests/run.sh that, when I run it, gives me a cryptic statement about testlists, but no hint about where I can find a testlist. How do I run them?
And can we hook that up to a 'make test' in the main directory?
Thanks!David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/11541torsocks Does Not Work with dig on Fedora 202020-06-27T14:12:12ZTractorsocks Does Not Work with dig on Fedora 20I am trying to follow the nmap-ncat instructions here https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/ssh for connecting to a tor hidden service over SSH. I can't seem to get it working. This is what I execute "torsocks d...I am trying to follow the nmap-ncat instructions here https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/ssh for connecting to a tor hidden service over SSH. I can't seem to get it working. This is what I execute "torsocks dig @213.73.91.35 +tcp +short www.google.com" which returns ";; communications error to 213.73.91.35#53: end of file". When I execute "dig @213.73.91.35 +tcp +short www.google.com" without torsocks, IP addresses are returned. I have verified I am connected to tor via setting up my Firefox (not tor browser bundle) proxy settings and going to check.torproject.org.
I am on Fedora 20. I am using tor version tor.x86_64-0.2.4.21-tor.1.rh20 and torsocks version torsocks.x86_64-1.3-2.fc20. You can contact me at eviljoel@linux.com if you have any questions.
**Trac**:
**Username**: eviljoelDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/40002Assertion 'fclose_nointr(f) != -EBADF' failed at src/basic/fd-util.c:125, fun...2022-05-24T20:03:16ZilfAssertion 'fclose_nointr(f) != -EBADF' failed at src/basic/fd-util.c:125, function safe_fclose()torsocks crashes Mutt. Mutt does this fine without torsocks.
```
% mutt -v
Mutt 1.14.7 (2020-08-29)
% torsocks --version
Torsocks 2.3.0
% torsocks --quiet mutt
-> c (change-folder)
-> ~f <enter>
Open mailbox: ~f
Assertion 'fclose_no...torsocks crashes Mutt. Mutt does this fine without torsocks.
```
% mutt -v
Mutt 1.14.7 (2020-08-29)
% torsocks --version
Torsocks 2.3.0
% torsocks --quiet mutt
-> c (change-folder)
-> ~f <enter>
Open mailbox: ~f
Assertion 'fclose_nointr(f) != -EBADF' failed at src/basic/fd-util.c:125, function safe_fclose(). Aborting.
zsh: abort (core dumped) torsocks --quiet mutt
```
https://github.com/systemd/systemd/blob/master/src/basic/fd-util.c#L125https://gitlab.torproject.org/tpo/core/torsocks/-/issues/11810Connection through torsocks(1) impossible2020-06-27T14:12:12ZTracConnection through torsocks(1) impossibleAfter installing the recent Ubuntu 14.04 AMD64 desktop release (LTS) I went about testing tor(1) and torsocks(1) and saw this:
WITHOUT TOR
$svn co http://svn.apache.org/repos/asf/subversion/trunk subversion
A subversion/notes
A s...After installing the recent Ubuntu 14.04 AMD64 desktop release (LTS) I went about testing tor(1) and torsocks(1) and saw this:
WITHOUT TOR
$svn co http://svn.apache.org/repos/asf/subversion/trunk subversion
A subversion/notes
A subversion/notes/commit-access-templates
A subversion/notes/api-errata
A subversion/notes/api-errata/1.7
A subversion/notes/api-errata/1.8
[...]
WITH TOR
$torsocks svn co http://svn.apache.org/repos/asf/subversion/trunk subversion
svn: E120108: Unable to connect to a repository at URL 'http://svn.apache.org/repos/asf/subversion/trunk'
svn: E120108: Error running context: The server unexpectedly closed the connection.
Since the OS installation is brand new and plain vanilla (no network bridges, VPNs, custom routing, or even a single service configured except for Tor) it seems a problem lies in the Tor software (either the service itself or the Socks wrapper.)
IMPORTANT CLUE
The svn(1) symptom above does not appear when replacing with git(1).
DIAGNOSIS
Running commands through torsocks(1) showing the symptom while inspecting with strace(1) reveals typical socket(2), fcntl(2), fstat(2), setsockopt(2), getpeername(2), and connect(2) to a tor(1) service running on localhost:9050 as usual. What might be atypical is that ENOTCONN and EINPROGRESS are returned in the way indicated by bug legacy/trac#8066 [1]. A late comment in legacy/trac#8066 refers in turn to legacy/trac#3711 [2], which are both leads.
[1] https://trac.torproject.org/projects/tor/ticket/8066/
[2] https://trac.torproject.org/projects/tor/ticket/3711/
LINUX DISTROS
Due to time constraints, I wasn't able to build tor(1) and torsocks(1) from source (at git.torproject.org) so there's a small chance that the bug has been fixed although no bug report exists to support this theory. It doesn't solve the problem of integrating whichever solution exists into leading Linux distributions however, which are still bundling the flawed version.
**Trac**:
**Username**: michaelDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/13256torsocks 1.3 possibly leaks username2020-06-27T14:12:11ZTractorsocks 1.3 possibly leaks usernameHi!
Disclaimer:
Not sure if I should have opened this bug report since it's for an old version and torsocks is now on 2.0, but 1.3 is the current version of torsocks in the Ubuntu 14.04 (LTS) repositories, which means it will still be s...Hi!
Disclaimer:
Not sure if I should have opened this bug report since it's for an old version and torsocks is now on 2.0, but 1.3 is the current version of torsocks in the Ubuntu 14.04 (LTS) repositories, which means it will still be so for some time.
Recently while playing with torsocks, wget and wireshark, I discovered something that looks like the name of the user running torsocks is leaked somehow. It's reproducible always that https is not used and torsocks is configured to use SOCKS4 (SOCKS5 unaffected). Please see the attached a screenshot for easier explanation.
Thankfully, these bytes won't leave the loopback interface hardly ever thanks to the default configuration of Tor, but in some configurations it could be considered dangerous. Furthermore, doc/socks/socks-extensions.txt says that usernames are ignored in SOCKS4 and SOCKS4A. Isn't it better to send random characters then instead of the user running it?
I haven't had a deep look at the torsocks code but I think these calls are the key :
src/socks.c: user = getpwuid(getuid());
These calls seem that were there since the beginning of the project but are not anymore in the latest version.
If you considered this is a bug, we should notify distributions. Otherwise if this behaviour is expected, just close this report ;)
**Trac**:
**Username**: p4blogDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/13294futex support2020-06-27T14:12:11ZTracfutex supporttorsocks v2.0.0 with irssi-0.8.17-head 20140731 works on first connect, but whines syscall 202 (futex on x86_64) is not supported; on reconnect it goes into infinite loop.
```
Thread 2 (Thread 0x7f959ae1c700 (LWP 10592)):
#0 0x00007f95...torsocks v2.0.0 with irssi-0.8.17-head 20140731 works on first connect, but whines syscall 202 (futex on x86_64) is not supported; on reconnect it goes into infinite loop.
```
Thread 2 (Thread 0x7f959ae1c700 (LWP 10592)):
#0 0x00007f95a18b07cd in poll () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007f95a27089f4 in g_main_context_poll (priority=2147483647, n_fds=1, fds=0x7f95940008e0, timeout=-1, context=0x1d932d0) at gmain.c:4076
#2 g_main_context_iterate (context=context@entry=0x1d932d0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3776
#3 0x00007f95a2708afc in g_main_context_iteration (context=0x1d932d0, may_block=may_block@entry=1) at gmain.c:3842
#4 0x00007f95a2708b39 in glib_worker_main (data=<optimized out>) at gmain.c:5589
#5 0x00007f95a2736d05 in g_thread_proxy (data=0x1d9b400) at gthread.c:764
#6 0x00007f95a2c11f35 in start_thread (arg=0x7f959ae1c700) at pthread_create.c:309
#7 0x00007f95a18bac3d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Thread 1 (Thread 0x7f95a42c2740 (LWP 10589)):
#0 0x00007f95a2c18bdb in __libc_recv (fd=fd@entry=4, buf=buf@entry=0x7fff37e591d0, n=n@entry=10, flags=-1, flags@entry=0) at ../sysdeps/unix/sysv/linux/x86_64/recv.c:33
#1 0x00007f95a3f5ac44 in recv_data_impl (fd=4, buf=0x7fff37e591d0, len=<optimized out>) at socks5.c:45
#2 0x00007f95a3f5b66d in socks5_recv_connect_reply (conn=conn@entry=0x22444a0) at socks5.c:498
#3 0x00007f95a3f5638f in tsocks_connect_to_tor (conn=conn@entry=0x22444a0) at torsocks.c:441
#4 0x00007f95a3f56d13 in tsocks_connect (sockfd=sockfd@entry=4, addr=addr@entry=0x7fff37e59280, addrlen=<optimized out>) at connect.c:190
#5 0x00007f95a3f56f1d in connect (sockfd=sockfd@entry=4, addr=addr@entry=0x7fff37e59280, addrlen=<optimized out>) at connect.c:225
#6 0x000000000049465d in net_connect_ip (ip=ip@entry=0x7fff37e593a0, port=port@entry=6697, my_ip=<optimized out>, my_ip@entry=0x0) at network.c:212
#7 0x00000000004a50af in net_connect_ip_ssl (ip=ip@entry=0x7fff37e593a0, port=6697, my_ip=my_ip@entry=0x0, server=server@entry=0x1d99d30) at network-openssl.c:559
#8 0x0000000000499666 in server_real_connect (server=server@entry=0x1d99d30, ip=ip@entry=0x7fff37e593a0, unix_socket=unix_socket@entry=0x0) at servers.c:227
#9 0x0000000000499b2f in server_connect_callback_readpipe (server=0x1d99d30) at servers.c:317
#10 0x0000000000490943 in irssi_io_invoke (source=<optimized out>, condition=<optimized out>, data=<optimized out>) at misc.c:54
#11 0x00007f95a27086cb in g_main_dispatch (context=0x1c61a40) at gmain.c:3111
#12 g_main_context_dispatch (context=context@entry=0x1c61a40) at gmain.c:3710
#13 0x00007f95a2708a58 in g_main_context_iterate (context=context@entry=0x1c61a40, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3781
#14 0x00007f95a2708afc in g_main_context_iteration (context=0x1c61a40, context@entry=0x0, may_block=may_block@entry=1) at gmain.c:3842
#15 0x0000000000416bf2 in main (argc=<optimized out>, argv=0x7fff37e596c8) at irssi.c:373
[pid 20316] 15:47:04.684643 recvfrom(4, 0x7fff1a57a880, 10, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) <0.000009>
[pid 20316] 15:47:04.684681 recvfrom(4, 0x7fff1a57a880, 10, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) <0.000009>
[pid 20316] 15:47:04.684718 recvfrom(4, 0x7fff1a57a880, 10, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) <0.000009>
[pid 20316] 15:47:04.684756 recvfrom(4, 0x7fff1a57a880, 10, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) <0.000010>
```
**Trac**:
**Username**: SafariDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/13571torsocks doesnt compile under MacOSX 10.10 (SO_DOMAIN linux only?)2020-06-27T14:12:11ZTractorsocks doesnt compile under MacOSX 10.10 (SO_DOMAIN linux only?)Making all in lib
CC recv.lo
clang: warning: argument unused during compilation: '-fno-strict-overflow'
recv.c:73:39: error: use of undeclared identifier 'SO_DOMAIN'
ret = getsockopt(sockfd, SOL_SOCKET, SO_DOMAIN, &sock_d...Making all in lib
CC recv.lo
clang: warning: argument unused during compilation: '-fno-strict-overflow'
recv.c:73:39: error: use of undeclared identifier 'SO_DOMAIN'
ret = getsockopt(sockfd, SOL_SOCKET, SO_DOMAIN, &sock_domain, &optlen);
^
1 error generated.
make[2]: *** [recv.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
**Trac**:
**Username**: olegbDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/13896torsocks prints wrong error messages about setuid/setgid executables2020-06-27T14:12:11ZTractorsocks prints wrong error messages about setuid/setgid executablesTest case:
$ touch foo
$ chmod u+xs foo
$ torsocks ./foo bar
ERROR: ./foo is setbarid. torsocks will not work on a setbarid executable.
“setbarid” is nonsense. The message should read “setuid” instead.
A patch is attached.
**Trac**: ...Test case:
$ touch foo
$ chmod u+xs foo
$ torsocks ./foo bar
ERROR: ./foo is setbarid. torsocks will not work on a setbarid executable.
“setbarid” is nonsense. The message should read “setuid” instead.
A patch is attached.
**Trac**:
**Username**: mitya57David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/13909Torsocks GitHub and Track failed usage2020-06-27T14:12:11ZTracTorsocks GitHub and Track failed usageI try to make working openSUSE RPM with newest Versions
I get failed usage with GitHub or Tor Git version
https://github.com/dgoulet/torsocks
and
https://gitweb.torproject.org/torsocks.git/
I have too tried with mine files to insta...I try to make working openSUSE RPM with newest Versions
I get failed usage with GitHub or Tor Git version
https://github.com/dgoulet/torsocks
and
https://gitweb.torproject.org/torsocks.git/
I have too tried with mine files to install newest Torsocks
```
cat /home/bin/git-/git-Torsocks
#!/bin/sh
echo ""
echo "$0"
echo ""
GIT_Torsocks="/paketi/Net/Sigurnost/Tor/Torsocks/Source/GIT/torsocks"
if [ -d "$GIT_Torsocks" ]
then
cd "$GIT_Torsocks"
echo " -=/\=- Updateing Torsocks -=/\=- "
git pull
else
mkdir -p "$GIT_Torsocks"
cd "$GIT_Torsocks"
cd ..
echo " -=/\=- Download new Torsocks -=/\=- "
git clone https://git.torproject.org/torsocks.git
fi
echo ""
echo " |||+++++----> Done with Torsocks <----+++++||| "
```
And install newest Torsocks with
```
cat /home/bin/install-Torsocks
#!/bin/sh
echo ""
echo "$0"
echo ""
echo ""
/home/bin/git-/git-Torsocks
echo ""
Torsocks=/paketi/Net/Sigurnost/Tor/Torsocks
if [ ! -d $Torsocks/Torsocks ]
then
echo "Copy GIT to $Torsocks/Torsocks"
cd $Torsocks
cp -a ./Source/GIT/torsocks ./Torsocks
echo ""
fi
cd $Torsocks/Torsocks
echo "make uninstall"
make uninstall
echo ""
echo "./autogen.sh"
./autogen.sh
echo ""
echo "./configure"
./configure
echo ""
echo "make"
make
echo "make install"
make install
```
```
which torsocks
/usr/local/bin/torsocks
```
I have too tried with mine files to install newest Tor
```
cat /home/bin/git-/git-Tor
#!/bin/sh
echo ""
echo "$0"
echo ""
GIT_Tor="/paketi/Net/Sigurnost/Tor/Tor/Source/GIT/tor"
if [ -d "$GIT_Tor" ]
then
cd "$GIT_Tor"
echo " -=/\=- Updateing Tor -=/\=- "
git pull
else
mkdir -p "$GIT_Tor"
cd "$GIT_Tor"
cd ..
echo " -=/\=- Download new Tor -=/\=- "
git clone https://git.torproject.org/tor.git
fi
echo ""
echo " |||+++++----> Done with Tor <----+++++||| "
```
And install newest Tor with
Must use with --disable-asciidoc or get 1600 new packages to install :(
```
cat /home/bin/install-Tor
#!/bin/sh
echo ""
echo "$0"
echo ""
echo ""
/home/bin/git-/git-Tor
echo ""
Tor=/paketi/Net/Sigurnost/Tor/Tor
if [ ! -d $Tor/Tor ]
then
echo "Copy GIT to $Tor/Tor"
cd $Tor
cp -a ./Source/GIT/tor ./Tor
echo ""
fi
cd $Tor/Tor
echo "make uninstall"
make uninstall
echo ""
echo "./autogen.sh"
./autogen.sh
echo ""
echo "./configure"
./configure --disable-asciidoc
echo ""
echo "make"
make
echo "make install"
make install
```
```
which tor
/usr/local/bin/tor
```
I try to use my RPM, Source is dowloaded from
https://github.com/dgoulet/torsocks/releases
```
cd var/tmp/build-root/openSUSE_Factory-x86_64/.build.packages/RPMS/x86_64/
```
```
zypper in torsocks-2.0.0-0.x86_64.rpm
```
torsocks-2.0.0-0
```
which torsocks
/usr/bin/torsocks
```
Torsocks newer Versions are not usable at all
```
slogin-tokyoshells-tunnel
[1] 21728 segmentation fault torsocks slogin tokyoshells
```
And all other Applications
```
torsocks smplayer
[1] 22327 segmentation fault torsocks smplayer
```
```
torsocks psi-plus
[1] 22395 segmentation fault torsocks psi-plus
```
...
With older Versions (1.1 and 1.2) from Google Code I not have this failures
https://code.google.com/p/torsocks/
Here are installed working Versions
```
zypper in tor
```
tor-0.2.5.10-70.1
```
which tor
/usr/bin/tor
```
```
zypper in torsocks
```
torsocks-1.1-2.1
```
which torsocks
/usr/bin/torsocks
```
```
zypper in curl
```
curl-7.38.0-1.2
Please correct usage and release one working Torsocks Version.
**Trac**:
**Username**: nemysisDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/14166torsock's configure.ac: avoid tests which have both -pie and -static2020-06-27T14:12:10ZAnthony Basiletorsock's configure.ac: avoid tests which have both -pie and -staticBuilding and linking with both -pie and -static is not supported for some toolchain combinations (eg. glibc or binutil's gold). Yet this combination is hit if the check for gcc hardening is done before AC_PROG_LIBTOOL and AC_ENABLE_STAT...Building and linking with both -pie and -static is not supported for some toolchain combinations (eg. glibc or binutil's gold). Yet this combination is hit if the check for gcc hardening is done before AC_PROG_LIBTOOL and AC_ENABLE_STATIC. We avoid the issue by moving the gcc hardening check to after AC_PROG_LIBTOOL and friends.
See:
https://sourceware.org/bugzilla/show_bug.cgi?id=17826
https://sourceware.org/bugzilla/show_bug.cgi?id=16428
https://bugs.gentoo.org/show_bug.cgi?id=533862David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/14265Torsocks works badly with default VirtualAddrNetworkIPv4 ranges2020-06-27T14:12:10ZNick MathewsonTorsocks works badly with default VirtualAddrNetworkIPv4 rangesIn comment:9:ticket:7555 , aagbsn notes that you get the following warning when you use a default AutoMap configuration with IPv4:
```
05:53:37 libtorsocks(13692): connect: Connection is to a local address (127.192.0.1),
may be a TCP DN...In comment:9:ticket:7555 , aagbsn notes that you get the following warning when you use a default AutoMap configuration with IPv4:
```
05:53:37 libtorsocks(13692): connect: Connection is to a local address (127.192.0.1),
may be a TCP DNS request to a local DNS server so have to reject to be safe.
Please report a bug to http://code.google.com/p/torsocks/issues/entry if this is
preventing a program from working properly with torsocks.
```
When AutomapHostsOnResolve is enabled, then Tor returns phony DNS addresses in the "Virtual range" (VirtualAddrNetworkIPv4, VirtualAddrNetworkIPv6) in response to requests for hosts listed in AutomapHostsSuffixes. For example, foobar.onion might resolve into 127.192.66.55, and subsequent connection attempts to 127.192.66.55 will cause Tor to make a connection to foobar.onion.
By default, VirtualAddrNetworkIPv4 is 127.192.0.0/10 and VirtualAddrNetworkIPv6 is [FE80::]/10 . It looks like torsocks rejects the IPv4 one because it's a local address? There should probably be some way to make it not do that, or to make an exception for a certain range, or something.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/14268torsocks "make check" target broken in out of tree builds2020-06-27T14:12:10ZYawning Angeltorsocks "make check" target broken in out of tree buildsShould be obvious from the summary, but this fails, when it shouldn't:
```
$ sh autogen.sh
$ mkdir build
$ cd build
$ ../configure; make; make check
```
The failures happen because the build system assumes that the following files are p...Should be obvious from the summary, but this fails, when it shouldn't:
```
$ sh autogen.sh
$ mkdir build
$ cd build
$ ../configure; make; make check
```
The failures happen because the build system assumes that the following files are present under the location that make was run from:
* tests/run.sh
* tests/test_list
* tests/unit/fixtures
Copying the files manually to the right places under "build" fixes things, so this should be easy to fix.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/15497torsock's getpeername() implementation is broken.2020-06-27T14:12:10ZYawning Angeltorsock's getpeername() implementation is broken.This is incredibly wrong and breaks well written applications:
```
/*
* Extra check for addrlen since we are about to copy the connection
* content into the given address.
*/
if (*addrlen > sizeof(struct ...This is incredibly wrong and breaks well written applications:
```
/*
* Extra check for addrlen since we are about to copy the connection
* content into the given address.
*/
if (*addrlen > sizeof(struct sockaddr)) {
/* Ref to the manpage for the returned value here. */
errno = EINVAL;
ret = -1;
goto end;
}
```
http://pubs.opengroup.org/onlinepubs/9699919799/functions/getpeername.html
>The address_len argument points to a socklen_t object which on input specifies the length of the supplied sockaddr structure, and on output specifies the length of the stored address. If the actual length of the address is greater than the length of the supplied sockaddr structure, the stored address shall be truncated.
This does not mean "reject `address_len` that's larger than `sizeof(struct sockaddr)`", and it is common to pass in a `sockaddr_in6` or `sockaddr_storage` both which are larger than `sockaddr`.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/15504torsocks's getaddrinfo() is broken.2020-06-27T14:12:09ZYawning Angeltorsocks's getaddrinfo() is broken.torsocks's getaddrinfo() implementation does not respect `AI_NUMERICHOST`.
This is wrong because it will do the resolution anyway, and things that expect to be able to use `getaddrinfo()` as a super `inet_pton()` break.
The correct thi...torsocks's getaddrinfo() implementation does not respect `AI_NUMERICHOST`.
This is wrong because it will do the resolution anyway, and things that expect to be able to use `getaddrinfo()` as a super `inet_pton()` break.
The correct thing to do is to check if the string is an address and return `EAI_NONAME` if it's not, without doing the tor resolution.
With this, `#15497` and `#13294` all fixed, `aria2c` actually works with torsocks again, as long as async dns is disabled. Yay.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/15584Linking libtorsocks with libtcmalloc results in SIGSEGV2021-07-09T18:32:02ZTracLinking libtorsocks with libtcmalloc results in SIGSEGVAny application that is linked against libtcmalloc gets SISEGV if it's being run with libtorsocks preloaded. However, it depends on preloading order.
If libtorsocks is preloaded first, app segfaults:
```
[~]$ LD_PRELOAD="/usr/lib64/tor...Any application that is linked against libtcmalloc gets SISEGV if it's being run with libtorsocks preloaded. However, it depends on preloading order.
If libtorsocks is preloaded first, app segfaults:
```
[~]$ LD_PRELOAD="/usr/lib64/torsocks/libtorsocks.so /usr/lib64/libtcmalloc_debug.so" uname -a
[1] 7817 segmentation fault (core dumped) LD_PRELOAD= uname -a
```
If, instead, libtcmalloc is preloaded first, everything is OK:
```
[~]$ LD_PRELOAD="/usr/lib64/libtcmalloc_debug.so /usr/lib64/torsocks/libtorsocks.so" uname -a
Linux spock 3.19.0-pf3 #1 SMP PREEMPT Tue Mar 24 17:14:04 EET 2015 x86_64 GNU/Linux
```
The problem is that if an app in question is linked against libtcmalloc, torifying it via "torify" or "torsocks" wrapper always leads to segfault because libtorsocks is loaded before libtcmalloc.
Attempt made to debug any app leads to non-informative backtrace:
```
#0 0x0000000000000000 in ?? ()
#1 0x00007ffff725e40c in ?? () from /usr/lib/libtcmalloc_debug.so.4
#2 0x00007ffff725ed3f in ?? () from /usr/lib/libtcmalloc_debug.so.4
#3 0x00007ffff725ef49 in NumCPUs() () from /usr/lib/libtcmalloc_debug.so.4
#4 0x00007ffff723b439 in ?? () from /usr/lib/libtcmalloc_debug.so.4
#5 0x00007ffff7dea1fa in call_init.part () from /lib64/ld-linux-x86-64.so.2
#6 0x00007ffff7dea30b in _dl_init () from /lib64/ld-linux-x86-64.so.2
#7 0x00007ffff7ddbdba in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#8 0x0000000000000003 in ?? ()
#9 0x00007fffffffe47a in ?? ()
#10 0x00007fffffffe4aa in ?? ()
#11 0x00007fffffffe4af in ?? ()
#12 0x0000000000000000 in ?? ()
```
I use torsocks v2.0.0 and libtcmalloc v2.4.
So my questions are:
1. should this be libtorsocks or libtcmalloc issue?
2. how should I get more info on this bug?
3. what should be done to fix the issue?
**Trac**:
**Username**: post-factumDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/16183torsocks upgrade broke OpenSSH connection sharing2020-06-27T14:12:09ZTractorsocks upgrade broke OpenSSH connection sharingAfter upgrading torsocks, I found that OpenSSH connection sharing did not work correctly anymore. It turned out that the master process (when running using torsocks) keeps file descriptors open which it received from the slave processes....After upgrading torsocks, I found that OpenSSH connection sharing did not work correctly anymore. It turned out that the master process (when running using torsocks) keeps file descriptors open which it received from the slave processes.
It turned out that the fd passing check introduced in commit eecc1152a9c8645 is responsible for the issue.
**Trac**:
**Username**: zeunerDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/16223Torsocks v2.1.0 fails to build on RHEL/CentOS 5.x2020-06-27T14:12:09ZTracTorsocks v2.1.0 fails to build on RHEL/CentOS 5.xThe newly-released torsocks v2.1.0 does not build in RHEL/CentOS v5.11 (all updates applied.)
This is the first error:
In file included from ref.h:23,
from connection.h:28,
from defaults.h:21,
...The newly-released torsocks v2.1.0 does not build in RHEL/CentOS v5.11 (all updates applied.)
This is the first error:
In file included from ref.h:23,
from connection.h:28,
from defaults.h:21,
from log.c:27:
compat.h:133:25: error: sys/eventfd.h: No such file or directory
make[2]: *** [log.lo] Error 1
This is due to the fact that eventfd.h really does not exist on this system. If I change the include from sys/eventfd.h to sys/syscall.h the compile finishes without error, but then the link fails:
../../src/lib/.libs/libtorsocks.so: undefined reference to `eventfd'
../../src/lib/.libs/libtorsocks.so: undefined reference to `inotify_init1'
../../src/lib/.libs/libtorsocks.so: undefined reference to `epoll_create1'
../../src/lib/.libs/libtorsocks.so: undefined reference to `epoll_pwait'
collect2: ld returned 1 exit status
No problems seen when building on a CentOS6 system, just on CentOS5.
The prior v2.0.0 does build on CentOS5 with the help of some function attribute trickery (prepending ATTR_HIDDEN to several function and data definitions).
**Trac**:
**Username**: tmpname0901David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/16308Attempts to resolve local hostname using tor2020-06-27T14:12:09ZTracAttempts to resolve local hostname using torWhen using torsocks 2.1.0 built from tarball, torsocks attempts to resolve the local machine's hostname using tor.
To reproduce: clone a git repository using torsocks
Result: clone is successful, but produces an error in torsocks after...When using torsocks 2.1.0 built from tarball, torsocks attempts to resolve the local machine's hostname using tor.
To reproduce: clone a git repository using torsocks
Result: clone is successful, but produces an error in torsocks after an attempt to resolve the machine's hostname:42 using tor.
`ERROR torsocks[pid]: Unable to resolve. Status reply: 4 (in socks5_recv_resolve_reply() at socks5.c:666)`
**Trac**:
**Username**: leeroyDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/16349Need to merge GigHub pull requests2020-06-27T14:12:09Zyurivict271Need to merge GigHub pull requestsPlease merge all GitHub pull requests: https://github.com/dgoulet/torsocks/pulls
And please close pull request section on GitHub if this isn't the proper location for requests to be filed.Please merge all GitHub pull requests: https://github.com/dgoulet/torsocks/pulls
And please close pull request section on GitHub if this isn't the proper location for requests to be filed.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/16432patches for NetBSD2020-06-27T14:12:09Zcypherpunkspatches for NetBSDThe attached patches fix several issues on NetBSD:
* The cpp conditionals for mmap goo in syscall.c don't match and break on NetBSD.
* NetBSD <7 incorrectly declared the obsolete `gethostbyaddr` function to take `char *` rather than `vo...The attached patches fix several issues on NetBSD:
* The cpp conditionals for mmap goo in syscall.c don't match and break on NetBSD.
* NetBSD <7 incorrectly declared the obsolete `gethostbyaddr` function to take `char *` rather than `void *`.
* In NetBSD >=4, the ELF symbol for the `socket` routine in libc is named `__socket30`; the symbol named `socket` is a compatibility routine implementing older semantics in terms of the symbol `__socket30`.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/16433infinite recursion in torsocks log timestamps2020-06-27T14:12:08Zcypherpunksinfinite recursion in torsocks log timestampsIf libc calls `open` and `close` in order to deal with time zones for `localtime`, the torsocks interception of `close` may lead to infinite recursion: torsocks `close` tries to print a log message, which needs a timestamp, which it form...If libc calls `open` and `close` in order to deal with time zones for `localtime`, the torsocks interception of `close` may lead to infinite recursion: torsocks `close` tries to print a log message, which needs a timestamp, which it formats with `localtime`, which opens the tz database and calls `close` when done, which tries to print a log message, which needs a timestamp...
(NetBSD's libc is an example of such a libc. Note `gmtime` has the same property.)
The attached patch changes timestamps to be seconds since epoch minus leap seconds, i.e. a standard POSIX clock, in order to avoid this recursion.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/16434fix miscellaneous compiler warnings2020-06-27T14:12:08Zcypherpunksfix miscellaneous compiler warningsThe attached patch tweaks things to avoid miscellaneous compiler warnings, from GCC and from the Clang static analyzer:
- Avoid signed/unsigned comparison with judicious casts, justified by asserts.
- Use the same type for indices into ...The attached patch tweaks things to avoid miscellaneous compiler warnings, from GCC and from the Clang static analyzer:
- Avoid signed/unsigned comparison with judicious casts, justified by asserts.
- Use the same type for indices into an array as are used for the size of the array.
- Make sure variables are initialized even for error branches.
- Avoid possible null pointer dereference in case of test failure.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/16435torsocks needlessly depends on perl for test suite2020-06-27T14:12:08Zcypherpunkstorsocks needlessly depends on perl for test suiteThe attached patch replaces the Perl tap driver by the shell-only automake tap driver, so that users need not have Perl installed in order to run the torsocks tests (nor do anything else with torsocks). This has the side effect of fixin...The attached patch replaces the Perl tap driver by the shell-only automake tap driver, so that users need not have Perl installed in order to run the torsocks tests (nor do anything else with torsocks). This has the side effect of fixing an issue with out-of-tree builds, and reducing local actions in tests/Makefile.am.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/16627torsocks 2.1 doesn't work with Oracle Java 8 (Mac OS X 10.9.5)2020-06-27T14:12:08ZTractorsocks 2.1 doesn't work with Oracle Java 8 (Mac OS X 10.9.5)torsocks 2.1 works OK with all applications except Oracle Java 8
For example:
```
$ torsocks telnet 184.105.238.114
Trying 184.105.238.114...
Connected to 184.105.238.114.
Escape character is '^]'.
This is the telnet autoresponder at v6...torsocks 2.1 works OK with all applications except Oracle Java 8
For example:
```
$ torsocks telnet 184.105.238.114
Trying 184.105.238.114...
Connected to 184.105.238.114.
Escape character is '^]'.
This is the telnet autoresponder at v6address.com.
You have connected over IPv4.
Your IP address is 82.X.Y.Z
Connection closed by foreign host.
```
With java:
```
$ torsocks java -jar utm_admin.jar
[Jul 21 11:35:33] WARNING torsocks[11015]: [syscall] Unsupported syscall number 180. Denying the call (in tsocks_syscall() at syscall.c:465)
[Jul 21 11:35:36] WARNING torsocks[11015]: [syscall] Unsupported syscall number 180. Denying the call (in tsocks_syscall() at syscall.c:465)
dyld: lazy symbol binding failed: Symbol not found: _JRSUIGetKey
Referenced from: /Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre/lib/libosxui.dylib
Expected in: flat namespace
dyld: Symbol not found: _JRSUIGetKey
Referenced from: /Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre/lib/libosxui.dylib
Expected in: flat namespace
Trace/BPT trap: 5
```
Versions:
```
$ torsocks --version
Torsocks 2.1.0
$ torsocks java -version
java version "1.8.0_31"
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
```
**Trac**:
**Username**: s.lobanovDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/16991I think I've figured out why torsocks-ci-linux is failing on Jenkins!2020-06-27T14:12:07ZNick MathewsonI think I've figured out why torsocks-ci-linux is failing on Jenkins!So, the tests seem to assume that there is a tor process running that can receive their queries, and that it's on the internet, and that while on the internet it can connect to the Tor network.
Not crazy I guess!
But FWICT the Jenkins...So, the tests seem to assume that there is a tor process running that can receive their queries, and that it's on the internet, and that while on the internet it can connect to the Tor network.
Not crazy I guess!
But FWICT the Jenkins builder hasn't launched a Tor process, or has shut off access to the network. I guess that's why it's failing in test_dns.c
So, the question:
Q1. Does torsocks really require for its tests that there exist a Tor process on port 9050 with access to the internet?
If the answer to Q1 is no, there is a bug in torsocks.
If the answer to Q1 is yes, there are three possible solutions I see:
S1. Change torsocks so that no tests require a running Tor with access to the internet.
S2. Change the Jenkins configuration so that it launches a tor client process for the torsocks test to use.
S3. Divide the torsocks tests into the ones that need a Tor connected to the network, and the ones that do not. Only run the ones that do not when we're running under Jenkins.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/17475Overflow when parsing config lines with many arguments2020-06-27T14:12:07ZTracOverflow when parsing config lines with many argumentsIt is possible to overflow tokens with a configuration that contains many
arguments in one line.
At first, the upper limit is specified as sizeof(tokens), which is
wrong. It has to be DEFAULT_MAX_CONF_TOKEN or sizeof(tokens) /
sizeof(to...It is possible to overflow tokens with a configuration that contains many
arguments in one line.
At first, the upper limit is specified as sizeof(tokens), which is
wrong. It has to be DEFAULT_MAX_CONF_TOKEN or sizeof(tokens) /
sizeof(tokens[0]). The former is shorter, therefor I took that one.
The next issue is in utils_tokenize_ignore_comments, which verifies that
enough space is available only with the ' ' separator. Later in the code,
'\t' is also allowed as a separator, which means that more arguments could
show up than previously taken into account during size checks.
This is an unlikely case, so the check will be done while parsing. When
the limit is reached, previously allocated memory is released again and
error value is returned.
**Trac**:
**Username**: junglefowlDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/17478Fix typos in comments2020-06-27T14:12:06ZTracFix typos in commentsThere are some typos in comments.
**Trac**:
**Username**: junglefowlThere are some typos in comments.
**Trac**:
**Username**: junglefowlDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/17479Allow port 655352020-06-27T14:12:06ZTracAllow port 65535Port 65535 is a valid port among the tor code base. In fact, in_port_t
type will guarantee a valid port number. The only special value is "0",
so drop the 65535 check completely.
**Trac**:
**Username**: junglefowlPort 65535 is a valid port among the tor code base. In fact, in_port_t
type will guarantee a valid port number. The only special value is "0",
so drop the 65535 check completely.
**Trac**:
**Username**: junglefowlDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/17618Segfault in tsocks_accept4() if called through syscall()2020-06-27T14:12:06ZTracSegfault in tsocks_accept4() if called through syscall()Hello,
There is a segfault in tsocks_accept4() when it is called through syscall() and accept4() isn't called first.
It's because tsocks_libc_accept4 is only initialized through accept4() and not syscall().
From what I can tell this i...Hello,
There is a segfault in tsocks_accept4() when it is called through syscall() and accept4() isn't called first.
It's because tsocks_libc_accept4 is only initialized through accept4() and not syscall().
From what I can tell this is not only a problem with tsocks_accept4() but many other calls made through syscall().
My suggested fix is to replace the native tsocks calls in syscall.c with their libc equivalents. E.g. instead of calling tsocks_accept4(), calling accept4().
Whatever the best fix, I can provide a patch for it given the right direction.
**Trac**:
**Username**: crystalmakerDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/17743[torsocks] Detect elevated capability executables2020-06-27T14:12:06ZTrac[torsocks] Detect elevated capability executablesBefore:
$ torsocks ping torproject.org
PING torproject.org (154.35.132.70) 56(84) bytes of data.
64 bytes from archeotrichon.torproject.org (154.35.132.70): icmp_seq=1 ttl=52 time=235 ms
64 bytes from archeotrichon.torproject.org (154.3...Before:
$ torsocks ping torproject.org
PING torproject.org (154.35.132.70) 56(84) bytes of data.
64 bytes from archeotrichon.torproject.org (154.35.132.70): icmp_seq=1 ttl=52 time=235 ms
64 bytes from archeotrichon.torproject.org (154.35.132.70): icmp_seq=2 ttl=52 time=166 ms
64 bytes from archeotrichon.torproject.org (154.35.132.70): icmp_seq=3 ttl=52 time=155 ms
After:
$ torsocks /bin/ping
ERROR: /bin/ping gains the following elevated capabilities. torsocks will not work with privledged executables.
/bin/ping = cap_net_raw+ep
**Trac**:
**Username**: shawnlDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/17760Torsocks doesn't quote variables, will choke on spaces and special characters...2020-06-27T14:12:06ZteorTorsocks doesn't quote variables, will choke on spaces and special characters in pathsThe script that launches a command using torsocks checks a lot of paths without quoting them.
This means that paths with spaces will cause errors, and paths with special characters may have unintended effects.The script that launches a command using torsocks checks a lot of paths without quoting them.
This means that paths with spaces will cause errors, and paths with special characters may have unintended effects.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/17936torsocks fails open on Mac OS X 10.112020-06-27T14:12:06ZArturo Filastòtorsocks fails open on Mac OS X 10.11I am running OSX 10.11 and since the update I just noticed that torsocks is failing to torify connections.
Here are the details of my system:
```
$ torsocks --version
Torsocks 2.1.0
$ uname -a
Darwin XXX 15.0.0 Darwin Kernel Version 1...I am running OSX 10.11 and since the update I just noticed that torsocks is failing to torify connections.
Here are the details of my system:
```
$ torsocks --version
Torsocks 2.1.0
$ uname -a
Darwin XXX 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64
$ sw_vers -productVersion
10.11.1
```
Doing a cursory search into what may be the causes for this problem it seems like a security "feature" introduced in OSX 10.11 is to blame for this behaviour called System Integrity Protection [1]. Looking around there are other people complaining about the fact that `DYLD_INSERT_LIBRARIES` doesn't work in OSX 10.11 [2].
This stackoverflow article does a nice summary of what can be done and can't be done due to SIP: http://apple.stackexchange.com/questions/193368/what-is-the-rootless-feature-in-el-capitan-really.
I am not sure what can be done to overcome this limitation in the latest version of OSX, but I think that at least torsocks should implement a check for the OSX version and if it's greater than 10.10 it fails closed (without doing the non-torified request).
[1] https://developer.apple.com/library/mac/documentation/Security/Conceptual/System_Integrity_Protection_Guide/Introduction/Introduction.html
[2] https://groups.google.com/a/chromium.org/forum/#!topic/crashpad-dev/MafauT4BHSYDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/17980Torify/Torsocks - Possible bug with OSX's default curl binary2020-06-27T14:12:05ZTracTorify/Torsocks - Possible bug with OSX's default curl binaryOSX default curl binary is not being torified when using _torify_ or _torsocks_. Using: ` curl --proxy socks5h://curl:curl@127.0.0.1:9050/` works fine, however, running ` torify/torsocks curl <url> ` does not work.
Example:
` $ torify ...OSX default curl binary is not being torified when using _torify_ or _torsocks_. Using: ` curl --proxy socks5h://curl:curl@127.0.0.1:9050/` works fine, however, running ` torify/torsocks curl <url> ` does not work.
Example:
` $ torify curl ifconfig.co/all.json # returns original IP `
` $ curl --proxy socks5h://curl:curl@127.0.0.1:9050/ ifconfig.co/all.json # returns the expected output `
` $ torify curl https://check.torproject.org/ | grep -i congratulations # returns nothing`
Torify does work on the Homebrew's curl version with the torify command, but it does not work when running a torify --shell (nor does the default OSX's curl):
{{{
$ torify --shell
/usr/local/bin/torsocks: New torified shell coming right up...
$ /usr/local/opt/curl/bin/curl ifconfig.co/all.json # returns my real IP
$ /usr/bin/curl ifconfig.co/all.json # returns my real IP
$ wget ifconfig.co/all.json # returns my real IP too (using homebrew's wget version 1.17.1)
}}}
OSX default curl:
```
$ curl --version
curl 7.43.0 (x86_64-apple-darwin15.0) libcurl/7.43.0 SecureTransport zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz UnixSockets
```
Homebrew's curl version:
```
$ /usr/local/opt/curl/bin/curl --version
curl 7.46.0 (x86_64-apple-darwin15.0.0) libcurl/7.46.0 SecureTransport zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: IPv6 Largefile NTLM NTLM_WB SSL libz UnixSockets
```
Apple makes this difficult to debug and find out why, due it's Security Integrity Protection (executables signed with restricted entitlements), so I copied OSX's default curl binary to /tmp, ran [1] then I was able to run btruss on the default curl, however I wasn't able run torify with btruss , since [1] didn't work, btruss output didn't have anything interesting as far as I know.
Attachments: with-torify.txt for the output of `sudo torify dtruss ./curl ifconfig.co/all.json` and no-torify.txt for `sudo dtruss ./curl ifconfig.co/all.json`
I am willing to help debug this if needed, but I would like some help to make this easier, since disabling OSX's System Integrity Protection is not a good idea, and apparently code-signing didn't work with me.
[1] ` codesign -f -s `whoami` curl `
'''OSX version: 10.11.2 (15C50)
Torsocks version: Torsocks 2.1.0
Tor version: 0.2.7.6
'''
**Trac**:
**Username**: z0xcdDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/19376Fix a few torsocks bugs caused by unquoted variables2020-06-27T14:12:05ZcypherpunksFix a few torsocks bugs caused by unquoted variablesFor such a short script, the torsocks wrapper has a fair few bugs, almost entirely caused by unquoted variables. This patch fixes it by quoting them where they need to be. A shell session showing just one example of a bug caused by faili...For such a short script, the torsocks wrapper has a fair few bugs, almost entirely caused by unquoted variables. This patch fixes it by quoting them where they need to be. A shell session showing just one example of a bug caused by failing to quote variables, followed by intended behavior after applying a patch:
```
$ torsocks --version
Torsocks 2.1.0
$ mkdir foo\ bar
$ echo echo hello\ world > foo\ bar/hello.sh
$ chmod 700 foo\ bar/hello.sh
$ ./foo\ bar/hello.sh
hello world
$ torsocks ./foo\ bar/hello.sh
/usr/bin/torsocks: 103: [: ./foo: unexpected operator
ERROR: ./foo bar/hello.sh cannot be found.
$ (cd / && sudo patch -p0) < quote.patch
patching file /usr/bin/torsocks
$ torsocks ./foo\ bar/hello.sh
hello world
```
The patch to fix it is attached.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/20871Regression in Torsocks 2.2.0 breaks wget, among others2021-07-09T18:32:02ZcypherpunksRegression in Torsocks 2.2.0 breaks wget, among othersVarious applications no longer work due to a regression in the latest Torsocks update, such as tlsdate and wget, whereas curl and youtube-dl work. I've tested this by compiling both 2.1.0 and 2.2.0 and exporting the library with LD_PRELO...Various applications no longer work due to a regression in the latest Torsocks update, such as tlsdate and wget, whereas curl and youtube-dl work. I've tested this by compiling both 2.1.0 and 2.2.0 and exporting the library with LD_PRELOAD, and trying wget with both.
The problem is not with name resolution, as would be suggested in the wget error, or with the TLS handshake, as tlsdate suggests, because the strace output does not even get to socket() and connect(). However, when an IP address is passed directly to wget rather than a hostname, 2.2.0 works. It appears to me like the problem, at least in wget's case, is with the hostname resolution code being hooked incorrectly by Torsocks. That's just a guess though.
With wget and curl:
```
$ LD_PRELOAD=libtorsocks-2.1.0.so curl https://www.torproject.org/ >/dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 15868 100 15868 0 0 6158 0 0:00:02 0:00:02 --:--:-- 8369
$ LD_PRELOAD=libtorsocks-2.1.0.so wget --spider https://www.torproject.org/
Spider mode enabled. Check if remote file exists.
--2016-12-03 10:08:57-- https://www.torproject.org/
Resolving www.torproject.org... 38.229.72.16
Connecting to www.torproject.org|38.229.72.16|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 15868 (15K) [text/html]
Remote file exists and could contain further links,
but recursion is disabled -- not retrieving.
$ LD_PRELOAD=libtorsocks-2.2.0.so curl https://www.torproject.org/ >/dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 15868 100 15868 0 0 7227 0 0:00:02 0:00:02 --:--:-- 10494
$ LD_PRELOAD=libtorsocks-2.2.0.so wget --spider https://www.torproject.org/
Spider mode enabled. Check if remote file exists.
--2016-12-03 10:09:20-- https://www.torproject.org/
Resolving www.torproject.org... failed: Unknown error.
wget: unable to resolve host address www.torproject.org
$ LD_PRELOAD=libtorsocks-2.2.0.so wget --spider $(tor-resolve torproject.org)
Spider mode enabled. Check if remote file exists.
--2016-12-03 10:11:12-- http://138.201.14.197/
Connecting to 138.201.14.197:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 496 [text/html]
Remote file exists and could contain further links,
but recursion is disabled -- not retrieving.
```
And with tlsdate:
```
$ LD_PRELOAD=libtorsocks-2.1.0.so tlsdate -n -V
Sat Dec 3 10:11:57 UTC 2016
$ LD_PRELOAD=libtorsocks-2.2.0.so tlsdate -n -V
SSL connection failed
child process failed in SSL handshake
```David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/21022Add several syscalls to src/lib/syscall.c (Torsocks breaks seccomp)2020-06-27T14:12:04ZcypherpunksAdd several syscalls to src/lib/syscall.c (Torsocks breaks seccomp)It looks like Torsocks whitelists calls that are allowed to be made via the glibc `syscall()` function, but unfortunately the whitelist is too restrictive. For example `seccomp()` is not permitted, and that results in the syscall being d...It looks like Torsocks whitelists calls that are allowed to be made via the glibc `syscall()` function, but unfortunately the whitelist is too restrictive. For example `seccomp()` is not permitted, and that results in the syscall being denied (new kernels use that rather than `prctl()` to enable sandboxes). This results in any program that uses a seccomp sandbox being unsandboxed when used in combination with Torsocks!
Ideally, `gettimeofday()` and `clock_gettime()` would also be whitelisted, because they are harmless and calling them as syscalls directly is a handy way to avoid them being used as vDSOs. The same goes with `fork()`, where calling it directly is a handy way to avoid having to use the glibc wrapper, which uses `clone()` instead.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/21626Make error: undefined reference to 'helper_is_default_tor_running'2020-06-27T14:12:04ZTracMake error: undefined reference to 'helper_is_default_tor_running'Build of torsocks @ HEAD (`0b199d9e173a7c88adbf804a484c8320a802d74e`) fails with:-
```
CC test_dns.o
CCLD test_dns
test_dns.o: In function `main':
/code/projects/torsocks/tests/test_dns.c:141: undefined reference to
`help...Build of torsocks @ HEAD (`0b199d9e173a7c88adbf804a484c8320a802d74e`) fails with:-
```
CC test_dns.o
CCLD test_dns
test_dns.o: In function `main':
/code/projects/torsocks/tests/test_dns.c:141: undefined reference to
`helper_is_default_tor_running'
collect2: error: ld returned 1 exit status
make[2]: *** [test_dns] Error 1
```
**Trac**:
**Username**: jahDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/22068Make it explicit that Torsocks won't work correctly in certain scenarios in t...2020-06-27T14:12:04ZTracMake it explicit that Torsocks won't work correctly in certain scenarios in the READMEAs far as I understand, Torsocks works by setting LD_PRELOAD, so an application that doesn't uses libc, and instead uses syscalls directly will be able to bypass torsocks and connect directly to the Internet.
I think a warning about it ...As far as I understand, Torsocks works by setting LD_PRELOAD, so an application that doesn't uses libc, and instead uses syscalls directly will be able to bypass torsocks and connect directly to the Internet.
I think a warning about it on the README file, and MAN page is needed, besides making it explicit that using Torsocks is not 100% safe as the README might make you think, for example:
> _Torsocks allows you to use most applications in a safe way with Tor. It ensures that DNS requests are handled safely and explicitly rejects any traffic other than TCP from the application you're using._
> Torsocks is an ELF shared library that is loaded before all others. The library overrides every needed Internet communication libc function calls such as connect(2) or gethostbyname(3).
> _This process is transparent to the user and if torsocks detects any communication that can't go through the Tor network such as UDP traffic, for instance, the connection is denied. If, for any reason, there is no way for torsocks to provide the Tor anonymity guarantee to your application, torsocks will force the application to quit and stop everything._
**Trac**:
**Username**: FranciscouzoDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/23667Always send ATYP 0x03 (domain name) with a plain IP address2020-06-27T14:12:04ZDavid Gouletdgoulet@torproject.orgAlways send ATYP 0x03 (domain name) with a plain IP addressNoticed with legacy/trac#22461, torsocks should always send a DOMAIN NAME type for the SOCKS5 request if it gets a plain IP address so tor doesn't warn on the control port and SafeSocks to deny the request.Noticed with legacy/trac#22461, torsocks should always send a DOMAIN NAME type for the SOCKS5 request if it gets a plain IP address so tor doesn't warn on the control port and SafeSocks to deny the request.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/23876Torsocks getpeername() is broken for .onion addresses2020-06-27T14:12:03ZTracTorsocks getpeername() is broken for .onion addressesWhen I connect to a .onion host with ssh using torsocks, ssh connects to the host and completes authentication but then it aborts with this error:
`get_sock_port: getnameinfo NI_NUMERICSERV failed: ai_family not supported`
I built to...When I connect to a .onion host with ssh using torsocks, ssh connects to the host and completes authentication but then it aborts with this error:
`get_sock_port: getnameinfo NI_NUMERICSERV failed: ai_family not supported`
I built torsocks with additional debug messages and found that the failure is due to a bug in torsocks. Ssh calls getpeername() to map the onion IP cookie address it was given by torsocks back to a hostname, and tsocks_getpeername() at getpeername.c:60 returns the sockaddr struct from the connection table expecting it to contain the onion IP cookie. But that struct is actually all 0's because when the connection entry for a .onion address is created in tsocks_connect() at connect.c:162, the address passed to connection_create is null instead of the onion IP cookie address.
Here's a patch to pass the onion IP cookie address to connection_create() instead of null. With this patch, the ssh connection to a .onion host works.
```
--- src/lib/connect.c.orig
+++ src/lib/connect.c
@@ -156,10 +156,11 @@
onion_pool_unlock(&tsocks_onion_pool);
if (on_entry) {
/*
- * Create a connection without a destination address since we will set
+ * Create a connection with the onion IP cookie since getpeername()
+ * might need it, and set connection domain and hostname to use
* the onion address name found before.
*/
- new_conn = connection_create(sockfd, NULL);
+ new_conn = connection_create(sockfd, addr);
if (!new_conn) {
errno = ENOMEM;
goto error;
```
**Trac**:
**Username**: Torsocks_userDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/24081Torsocks logging to a file can cause a crash or corrupt application files.2020-06-27T14:12:03ZTracTorsocks 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.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/24140When I "torify ssh root@abcdefghijklmnop.onion" I get a error2020-06-27T14:12:03ZTracWhen 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/tpo/core/torsocks/-/issues/24960Torsocks not builds on old kernels where epoll_pwait isn't implemented2020-06-27T14:12:02ZTracTorsocks 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/tpo/core/torsocks/-/issues/24967torsocks fails to check SIP if the path itself is a symlink2021-07-09T18:32:02ZAlex 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/tpo/core/torsocks/-/issues/25586gethostbyaddr_r doesn't populate h_addrtype field of output hostent struct2020-06-27T14:12:02ZTracgethostbyaddr_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/tpo/core/torsocks/-/issues/25627tsocks_gethostbyaddr_r scribbles garbage over data->hostname and then relies ...2020-06-27T14:12:02ZTractsocks_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/tpo/core/torsocks/-/issues/25785Torsocks error. Symbol res_query, res_search, res_domain, res_querydomian not...2020-06-27T14:12:02ZTracTorsocks 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/tpo/core/torsocks/-/issues/26794tsocks_gethostbyname_r does not assign result2020-06-27T14:12:01ZTractsocks_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/tpo/core/torsocks/-/issues/28539Build breaks on FreeBSD: undefined reference to `handle_mmap'2020-06-27T14:12:01Zyurivict271Build 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/tpo/core/torsocks/-/issues/28861torsocks: Unsupported syscall number 2172020-06-27T14:12:00ZTractorsocks: Unsupported syscall number 217% torsocks --version
Torsocks 2.3.0
% torsocks mutt
<quit>
1544962729 WARNING torsocks[21365]: [syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() at syscall.c:568)
1544962729 WARNING torsocks[21367]: [syscal...% torsocks --version
Torsocks 2.3.0
% torsocks mutt
<quit>
1544962729 WARNING torsocks[21365]: [syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() at syscall.c:568)
1544962729 WARNING torsocks[21367]: [syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() at syscall.c:568)
1544962729 WARNING torsocks[21369]: [syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() at syscall.c:568)
1544962729 WARNING torsocks[21371]: [syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() at syscall.c:568)
1544962729 WARNING torsocks[21373]: [syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() at syscall.c:568)
https://gitweb.torproject.org/torsocks.git/tree/src/lib/syscall.c#n567
**Trac**:
**Username**: ilfDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/28998torsocks popcon: [syscall] Unsupported syscall number 2882021-07-09T18:32:02Ztraumschuletorsocks popcon: [syscall] Unsupported syscall number 288With torsocks 2.3 popcon gives:
```
# torsocks /etc/cron.daily/popularity-contest --crond
1546700136 WARNING torsocks[6199]: [syscall] Unsupported syscall number 288. Denying the call (in tsocks_syscall() at syscall....With torsocks 2.3 popcon gives:
```
# torsocks /etc/cron.daily/popularity-contest --crond
1546700136 WARNING torsocks[6199]: [syscall] Unsupported syscall number 288. Denying the call (in tsocks_syscall() at syscall.c:568
# torsocks --version
Torsocks 2.3.0
# uname -rmvo
4.9.0-8-686-pae #1 SMP Debian 4.9.130-2 (2018-10-27) i686 GNU/Linux
```
I assume the report is sent nevertheless because it is not reproducible calling it a second time.
This confirms that the [former warnings for syscall 250 and 204](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801224) are gone.
https://sources.debian.org/src/linux/4.9.130-2/arch/x86/entry/syscalls/syscall_32.tbl/#L297
> 288 i386 keyctl sys_keyctl compat_sys_keyctlhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/29236After updating tor to 8.0.5, socks5 started to not work2020-06-27T14:12:00ZTracAfter updating tor to 8.0.5, socks5 started to not workI usually use socks5 in Adium messenger, but when i updated tor to new version Adium start to give the error - Error: Connection failed
In tor logs i found those -
1/30/19, 20:16:31.821 [WARN] Fetching socks handshake failed. Closing.
...I usually use socks5 in Adium messenger, but when i updated tor to new version Adium start to give the error - Error: Connection failed
In tor logs i found those -
1/30/19, 20:16:31.821 [WARN] Fetching socks handshake failed. Closing.
1/30/19, 20:16:31.821 [WARN] socks5: parsing failed - invalid user/pass authentication message.
1/30/19, 20:16:31.821 [WARN] Fetching socks handshake failed. Closing.
1/30/19, 20:16:37.680 [WARN] socks5: parsing failed - invalid user/pass authentication message.
1/30/19, 20:16:37.680 [WARN] Fetching socks handshake failed. Closing.
1/30/19, 20:16:37.680 [WARN] socks5: parsing failed - invalid user/pass authentication message.
I never had this before, all have worked perfectly. Immediately after the update, everything stopped working. I tried all, i installed tor/messenger and updated os, but nothing helped.
Help!
**Trac**:
**Username**: bugiguimanDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/29659WARNING torsocks[6254]: [syscall] Unsupported syscall number 39. Denying the ...2021-07-09T18:32:02ZTracWARNING torsocks[6254]: [syscall] Unsupported syscall number 39. Denying the call (in tsocks_syscall() at syscall.c:605)Following the suggestion to make a ticket at https://stackoverflow.com/questions/46634215/torsocks-and-unsupported-syscalls, which is about a non related issue:
The below warning is with torsocks 2.3.0:
WARNING torsocks[6254]: [syscall...Following the suggestion to make a ticket at https://stackoverflow.com/questions/46634215/torsocks-and-unsupported-syscalls, which is about a non related issue:
The below warning is with torsocks 2.3.0:
WARNING torsocks[6254]: [syscall] Unsupported syscall number 39. Denying the call (in tsocks_syscall() at syscall.c:605)
**Trac**:
**Username**: tu8367https://gitlab.torproject.org/tpo/core/torsocks/-/issues/29769[syscall] Unsupported syscall number 316. Denying the call (in tsocks_syscall...2021-07-09T18:32:02ZTrac[syscall] Unsupported syscall number 316. Denying the call (in tsocks_syscall() at syscall.c:615)[syscall] Unsupported syscall number 316. Denying the call (in tsocks_syscall() at syscall.c:615)
Platform is Linux x86_64, torsocks 2.3.0.
Creating a child to save entering the background.
https://filippo.io/linux-syscall-table/ doesn...[syscall] Unsupported syscall number 316. Denying the call (in tsocks_syscall() at syscall.c:615)
Platform is Linux x86_64, torsocks 2.3.0.
Creating a child to save entering the background.
https://filippo.io/linux-syscall-table/ doesn't have a legacy/trac#316 entry. How was legacy/trac#217 resolved to getdents64, legacy/trac#39 to getpid, and so on?
How could I avoid over striking legacy/trac#316 and the 2 other?
**Trac**:
**Username**: tu8367https://gitlab.torproject.org/tpo/core/torsocks/-/issues/30658Unsupported syscalls (292/dup3, 293/pipe2, 332/statx)2021-07-09T18:32:02ZTracUnsupported syscalls (292/dup3, 293/pipe2, 332/statx)I've been playing around with an torified environment via `. torsocks on`. Running a vanilla vim, torsocks complains about the mentioned syscalls:
```
$ vim -u NONE
1559028872 WARNING torsocks[6802]: [syscall] Unsupported syscall number...I've been playing around with an torified environment via `. torsocks on`. Running a vanilla vim, torsocks complains about the mentioned syscalls:
```
$ vim -u NONE
1559028872 WARNING torsocks[6802]: [syscall] Unsupported syscall number 293. Denying the call (in tsocks_syscall() at syscall.c:568)
1559028872 WARNING torsocks[6802]: [syscall] Unsupported syscall number 332. Denying the call (in tsocks_syscall() at syscall.c:568)
1559028873 WARNING torsocks[6802]: [syscall] Unsupported syscall number 292. Denying the call (in tsocks_syscall() at syscall.c:568)
```
Peeking in the linux kernel source tree, these naively look safe to me:
```
$ egrep '^(293|332|292)' arch/x86/entry/syscalls/syscall_64.tbl
292 common dup3 __x64_sys_dup3
293 common pipe2 __x64_sys_pipe2
332 common statx __x64_sys_statx
```
Does adding these to the whitelist seem reasonable?
=== Version Info
```
$ torsocks --version
Torsocks 2.3.0
$ lsb_release --all
LSB Version: 1.0
Distributor ID: VoidLinux
Description: Void Linux
Release: rolling
Codename: void
$ uname -a
Linux lang 5.0.17_1 #1 SMP PREEMPT Fri May 17 08:23:10 UTC 2019 x86_64 GNU/Linux
```
=== Notes
This is my first ticket here, so if I've commited some _faux pas_ please forgive me. Cheers!
**Trac**:
**Username**: eirizuhaexhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/32953torsocks: Unsupported syscall 157 (prctl)2021-07-09T18:32:02ZTractorsocks: Unsupported syscall 157 (prctl)== Overview
I run `. torsocks on` by default and recently ran into this nuissance:
```
$ ls
1579062527 WARNING torsocks[29826]: [syscall] Unsupported syscall number 157. Denying the call (in tsocks_syscall() at syscall.c:568)
15790625...== Overview
I run `. torsocks on` by default and recently ran into this nuissance:
```
$ ls
1579062527 WARNING torsocks[29826]: [syscall] Unsupported syscall number 157. Denying the call (in tsocks_syscall() at syscall.c:568)
1579062527 WARNING torsocks[29826]: [syscall] Unsupported syscall number 157. Denying the call (in tsocks_syscall() at syscall.c:568)
1579062527 WARNING torsocks[29826]: [syscall] Unsupported syscall number 157. Denying the call (in tsocks_syscall() at syscall.c:568)
1579062527 WARNING torsocks[29826]: [syscall] Unsupported syscall number 157. Denying the call (in tsocks_syscall() at syscall.c:568)
1579062527 WARNING torsocks[29826]: [syscall] Unsupported syscall number 157. Denying the call (in tsocks_syscall() at syscall.c:568)
1579062527 WARNING torsocks[29826]: [syscall] Unsupported syscall number 157. Denying the call (in tsocks_syscall() at syscall.c:568)
foo/ bar.baz
```
== Version Info
```
$ lsb_release --all
LSB Version: 1.0
Distributor ID: VoidLinux
Description: Void Linux
Release: rolling
Codename: void
$ uname --all
Linux lang 5.4.8_1 #1 SMP PREEMPT Sun Jan 5 18:00:07 UTC 2020 x86_64 GNU/Linux
$ torsocks --version
Torsocks 2.3.0
$ ls --version
ls (GNU coreutils) 8.31
...
$ xbps-query -p pkgver libcap # see below for explanation
libcap-2.30_1
```
== Sleuthing the Cause
Grepping the linux kernel syscall table
```
$ cd path/to/kernel/git/repo/
$ grep 157 arch/x86/entry/syscalls/syscall_64.tbl
157 common prctl __x64_sys_prctl
```
So it looks like coreutils' ls is (eventually) calling prctl; indeed
```
$ strace -e prctl ls
prctl(PR_CAPBSET_READ, CAP_MAC_OVERRIDE) = 1
prctl(PR_CAPBSET_READ, 0x30 /* CAP_??? */) = -1 EINVAL (Invalid argument)
prctl(PR_CAPBSET_READ, 0x28 /* CAP_??? */) = -1 EINVAL (Invalid argument)
prctl(PR_CAPBSET_READ, CAP_BLOCK_SUSPEND) = 1
prctl(PR_CAPBSET_READ, 0x26 /* CAP_??? */) = -1 EINVAL (Invalid argument)
prctl(PR_CAPBSET_READ, CAP_AUDIT_READ) = 1
foo/ bar.baz
```
which correspondings nicely with the six warnings from above. The issue appeared quite recently on my machine; however, both the torsocks and coreutils I am running are not particularly new and have been running on my system for a while. Doing a little spelunking:
```
$ ldd /usr/bin/ls
linux-vdso.so.1 (0x00007ffcfb53d000)
/usr/lib/torsocks/libtorsocks.so (0x00007f1e5509e000)
libcap.so.2 => /usr/lib/libcap.so.2 (0x00007f1e5507f000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f1e54ebc000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f1e54eb7000)
/lib/ld-linux-x86-64.so.2 (0x00007f1e550dc000)
```
libcap looks the most suspicious, and indeed, on my system it is the only library that has been recently updated:
```
$ xilog libcap-2.30
libcap-2.30_1 : 2020-01-07 09:13 JST
```
So we can be reasonably confident that a recent libcap update unearthed this potential regression.
== Comments
The security implications of `prctl` are beyond my expertise, but given that it manages capabilities, I am guessing this would not be a trivial patch. Is there any hope this could be fixed or mitigated?
**Trac**:
**Username**: eirizuhaexhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/33096on x64: torsocks --shell: [syscall] Unsupported syscall number 1572021-07-09T18:32:02ZTracon x64: torsocks --shell: [syscall] Unsupported syscall number 157Following the update at https://stackoverflow.com/questions/46634215/torsocks-and-unsupported-syscalls
arch is x64.
torsocks --shell warns
[syscall] Unsupported syscall number 157. Denying the call (in tsocks_syscall() at syscall.c:61...Following the update at https://stackoverflow.com/questions/46634215/torsocks-and-unsupported-syscalls
arch is x64.
torsocks --shell warns
[syscall] Unsupported syscall number 157. Denying the call (in tsocks_syscall() at syscall.c:615)
grep 157 arch/x86/entry/syscalls/syscall*tbl
syscall_32.!tbl:157 i386 sched_getscheduler sys_sched_getscheduler !__ia32_sys_sched_getscheduler
syscall_64.!tbl:157 common prctl !__x64_sys_prctl
**Trac**:
**Username**: tu8367https://gitlab.torproject.org/tpo/core/torsocks/-/issues/33552Unsupported syscall number 229 on Debian on torsocks 2.3.02021-07-09T18:32:02ZTracUnsupported syscall number 229 on Debian on torsocks 2.3.0arch is x64.
Versions:
Tor 0.4.2.6 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.8.
I'm testing Interactive Brokers' TWS software on Tails OS (just for fun, I see it's not a use...arch is x64.
Versions:
Tor 0.4.2.6 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.8.
I'm testing Interactive Brokers' TWS software on Tails OS (just for fun, I see it's not a use case, however, I hope this can help), but I've met a problem launching it:
1583671114 WARNING torsocks[25196]: [syscall] Unsupported syscall number 229. Denying the call (in tsocks_syscall() at syscall.c:605)
1583671115 ERROR torsocks[25196]: Unable to resolve. Status reply: 4 (in socks5_recv_resolve_reply() at socks5.c:677)
The application show an error message: Update Failed. Check log file for details: /home/amnesia/Jts/.intall4j/updater.log (see below).
----
Steps to reproduce:
1. Launch Tails 4.3.
2. Download tws-latest-linux-x64.sh or tws-stable-linux-x64.sh from [the official website](https://www.interactivebrokers.com/en/index.php?f=14099#tws-software).
3. Run the installer: for example,
```
./tws-stable-linux-x64.sh
```
4. After the installation, launch the application: from the installer or from Terminal:
```
torify "/home/amnesia/Jts/tws" -J-DjtsConfigDir="/home/amnesia/Jts" %U
```
or
```
. torsocks on
"/home/amnesia/Jts/tws" -J-DjtsConfigDir="/home/amnesia/Jts" %U
```
5. You get:
```
1583672301 WARNING torsocks[26808]: [syscall] Unsupported syscall number 229. Denying the call (in tsocks_syscall() at syscall.c:605)
1583672301 ERROR torsocks[26808]: Unable to resolve. Status reply: 4 (in socks5_recv_resolve_reply() at socks5.c:677)
1583672301 ERROR torsocks[26808]: Unable to resolve. Status reply: 4 (in socks5_recv_resolve_reply() at socks5.c:677)
1583672302 ERROR torsocks[26808]: Unable to resolve. Status reply: 4 (in socks5_recv_resolve_reply() at socks5.c:677)
1583672379 PERROR torsocks[26808]: socks5 libc connect: Invalid argument (in socks5_connect() at socks5.c:202)
```
----
See the log (Jts/.intall4j/updater.log):
```
[INFO] com.install4j.runtime.beans.actions.control.SetVariableAction [ID 4839]: Execute action
Property script: com.install4j.script.I4jScript_Internal_62
Property variableName: updateDescriptorUrl
Property failIfNull: true
Property onlyIfUndefined: false
Property responseFileVariable: false
Property rollbackSupported: false
Variable changed: updateDescriptorUrl=https://download2.interactivebrokers.com/installers/tws/stable/tws-stable-linux-x64.xml[class java.lang.String]
Execute action successful after 3 ms
[INFO] com.install4j.runtime.beans.actions.update.CheckForUpdateAction [ID 479]: Execute action
Property connectTimeout: 10000
Property connectionFailureScript: null
Property readTimeout: 20000
Property requestHeaders: []
Property url: https://download2.interactivebrokers.com/installers/tws/stable/tws-stable-linux-x64.xml
Property variable: updateDescriptor
Property acceptAllCertificates: false
Property askForProxy: true
Property rollbackSupported: false
Property showError: true
[ERROR] com.install4j.runtime.beans.actions.update.CheckForUpdateAction [ID 479]: could not download file
java.net.ConnectException: Invalid argument (connect failed)
java.net.ConnectException: Invalid argument (connect failed)
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:673)
at sun.net.NetworkClient.doConnect(NetworkClient.java:175)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:463)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:558)
at sun.net.www.protocol.https.HttpsClient.<init>(HttpsClient.java:264)
at sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:367)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:191)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1156)
at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1040)
at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1038)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:782)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1037)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:177)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:162)
at com.install4j.runtime.installer.helper.content.HttpRequestHandler.getURLConnection(HttpRequestHandler.java:288)
at com.install4j.runtime.installer.helper.content.HttpRequestHandler.connect(HttpRequestHandler.java:135)
at com.install4j.runtime.installer.helper.content.Downloader.connect(Downloader.java:155)
at com.install4j.runtime.installer.helper.content.Downloader.connect(Downloader.java:24)
at com.install4j.runtime.installer.helper.content.HttpRequestHandler.connect(HttpRequestHandler.java:128)
at com.install4j.runtime.installer.helper.content.Downloader.connect(Downloader.java:150)
at com.install4j.runtime.beans.actions.update.CheckForUpdateAction.execute(CheckForUpdateAction.java:35)
at com.install4j.runtime.beans.actions.SystemInstallOrUninstallAction.install(SystemInstallOrUninstallAction.java:29)
at com.install4j.runtime.installer.ContextImpl$9.executeAction(ContextImpl.java:1727)
at com.install4j.runtime.installer.ContextImpl$9.fetchValue(ContextImpl.java:1718)
at com.install4j.runtime.installer.ContextImpl$9.fetchValue(ContextImpl.java:1715)
at com.install4j.runtime.installer.helper.comm.actions.FetchObjectAction.execute(FetchObjectAction.java:14)
at com.install4j.runtime.installer.helper.comm.HelperCommunication.executeActionDirect(HelperCommunication.java:271)
at com.install4j.runtime.installer.helper.comm.HelperCommunication.executeActionInt(HelperCommunication.java:246)
at com.install4j.runtime.installer.helper.comm.HelperCommunication.executeActionChecked(HelperCommunication.java:184)
at com.install4j.runtime.installer.helper.comm.HelperCommunication.fetchObjectChecked(HelperCommunication.java:167)
at com.install4j.runtime.installer.ContextImpl.performActionIntStatic(ContextImpl.java:1715)
at com.install4j.runtime.installer.InstallerContextImpl.performActionInt(InstallerContextImpl.java:159)
at com.install4j.runtime.installer.ContextImpl.performAction(ContextImpl.java:1143)
at com.install4j.runtime.installer.controller.Controller.executeAction(Controller.java:398)
at com.install4j.runtime.installer.controller.Controller.executeActions(Controller.java:364)
at com.install4j.runtime.installer.controller.Controller.handleCommand(Controller.java:221)
at com.install4j.runtime.installer.controller.Controller.handleStartup(Controller.java:142)
at com.install4j.runtime.installer.controller.Controller.start(Controller.java:98)
at com.install4j.runtime.installer.Application.runApplication(Application.java:91)
at com.install4j.runtime.installer.Application.main(Application.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.exe4j.runtime.LauncherEngine.launch(LauncherEngine.java:85)
at com.install4j.runtime.launcher.UnixLauncher.start(UnixLauncher.java:66)
at install4j.App3118837495Id443.main(Unknown Source)
Execute action not successful after 10500 ms
[INFO] Canceled
```
**Trac**:
**Username**: secureyourselfhttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/40006DNS leaks when using youtube-dl --proxy option?2021-07-09T18:32:02ZGhost UserDNS leaks when using youtube-dl --proxy option?The [torify doc](https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/Misc) advises youtube-dl users to use `--proxy socks5://127.0.0.1:9050/` (Tor) or `--proxy socks5://127.0.0.1:9150/` (Tor Browser).
https://trac.torproject.o...The [torify doc](https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/Misc) advises youtube-dl users to use `--proxy socks5://127.0.0.1:9050/` (Tor) or `--proxy socks5://127.0.0.1:9150/` (Tor Browser).
https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/Misc
I seem to experience the following:
1. `youtube-dl --proxy socks://127.0.0.1:9050/` queries DNS in the clear.
2. `torsocks youtube-dl` (without `--proxy`) queries DNS through Tor.
Note: I used `socks://` not `socks5://` as the torify doc advises. I have not yet tested with `socks5://`.
Quick testing with nftables logging/dropping DNS packets:
- When I do 1. while logging DNS packets, I see DNS queries in my logs.
- When I do 1. while dropping DNS packets, youtube-dl fails to resolve names.
- When I do 2. while dropping DNS packets, youtube-dl works fine.
If DNS leaks are indeed happening as I believe, the issue may be a youtube-dl bug.
In this case, the torify docs should be edited to warn people about DNS leaks:
- Advise using `torsocks youtube-dl` instead of `--proxy` OR
- Add a warning
I would need to do further testing to confirm the details above, but I thought to start this issue so people know about the possibility.
Versions:
- youtube-dl: 2020.09.20
- torsocks: 2.3.0
- tor: 0.4.4.5