Torsocks issueshttps://gitlab.torproject.org/tpo/core/torsocks/-/issues2021-07-09T18:32:02Zhttps://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.5https://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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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.org