[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #32953 [- Select a component]: torsocks: Unsupported syscall 157 (prctl)
#32953: torsocks: Unsupported syscall 157 (prctl)
------------------------+--------------------------------------
Reporter: eirizuhaex | Owner: (none)
Type: defect | Status: new
Priority: Medium | Component: - Select a component
Version: | Severity: Normal
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
------------------------+--------------------------------------
== 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?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32953>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs