Opened 4 years ago

Last modified 2 years ago

#16579 accepted defect

(Sandbox) Caught a bad syscall attempt (syscall socket)

Reported by: cypherpunks Owned by: nickm
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.2.7.1-alpha
Severity: Normal Keywords: 029-backport tor-client tor-relay linux sandbox 32bit
Cc: sam@… Actual Points:
Parent ID: Points: small
Reviewer: Sponsor:

Description

I'm running tor on Gentoo Hardened.
The bug exists in 0.2.6.7 and 0.2.7.1-alpha.
tor crashes within seconds of starting, before any clients can connect I think.

Jul 14 13:13:07.000 [notice] Tor 0.2.7.1-alpha (git-df76da0f3bfd6897) opening log file.
Jul 14 13:13:07.182 [notice] Tor v0.2.7.1-alpha (git-df76da0f3bfd6897) running on Linux with Libevent 2.0.22-stable, OpenSSL 1.0.1p and Zlib 1.2.8.
Jul 14 13:13:07.182 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jul 14 13:13:07.182 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Jul 14 13:13:07.182 [notice] Read configuration file "/etc/tor/torrc".
Jul 14 13:13:07.187 [notice] Opening Socks listener on 127.0.0.1:9050
Jul 14 13:13:07.187 [notice] Opening Socks listener on 127.0.0.1:9056
Jul 14 13:13:07.187 [notice] Opening Socks listener on 127.0.0.1:9055
Jul 14 13:13:07.187 [notice] Opening Control listener on 127.0.0.1:9015
Jul 14 13:13:07.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Jul 14 13:13:07.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Jul 14 13:13:07.000 [notice] Bootstrapped 0%: Starting

============================================================ T= 1436875987
(Sandbox) Caught a bad syscall attempt (syscall socket)
/usr/bin/tor(+0x142148)[0x4bb7bc8148]
/lib64/libc.so.6(socket+0x7)[0x3adc706ea07]
/lib64/libc.so.6(socket+0x7)[0x3adc706ea07]
/lib64/libc.so.6(+0xf16a0)[0x3adc70686a0]
/lib64/libc.so.6(__vsyslog_chk+0x3ef)[0x3adc7068aff]
/lib64/libc.so.6(__syslog_chk+0x89)[0x3adc7068df9]
/usr/bin/tor(+0x135bb0)[0x4bb7bbbbb0]
/usr/bin/tor(tor_log+0xd0)[0x4bb7bbc680]
/usr/bin/tor(control_event_bootstrap+0x1e4)[0x4bb7b7ba74]
/usr/bin/tor(do_main_loop+0x84)[0x4bb7abe234]
/usr/bin/tor(tor_main+0x16c5)[0x4bb7ac1225]
/lib64/libc.so.6(__libc_start_main+0x114)[0x3adc6f97134]
/usr/bin/tor(+0x34519)[0x4bb7aba519]
$ uname -r
3.18.9-hardened

This bug has been reported downstream: https://bugs.gentoo.org/show_bug.cgi?id=550302.
It occurs with the following torrc:

#
# Minimal torrc so tor will work out of the box
#
User tor
PIDFile /var/run/tor/tor.pid
Log notice syslog
Log notice file /var/log/tor/log
DataDirectory /var/lib/tor/data
SandBox 1

SocksPort 9050
SocksPort 9056 IsolateDestAddr IsolateDestPort
SocksPort 9055

ControlPort 9015
CookieAuthentication 1

By commenting out "Sandbox 1" or unsetting it, tor will obviously run without crashing.

Child Tickets

Change History (20)

comment:1 Changed 4 years ago by nickm

My guess is that the syslog() call (from Log notice syslog) is the one causing the troubles.

comment:2 Changed 4 years ago by nickm

Keywords: 026-backport added
Milestone: Tor: 0.2.7.x-final

comment:3 Changed 4 years ago by nickm

I'm guessing that because the crash is coming from within syslog_chk . But when I try to test this myself, by running only with Log notice syslog and Sandbox 1, I don't see a crash on my host.

Do you get a crash when you start Tor using a Torrc with only those two options?

Last edited 4 years ago by nickm (previous) (diff)

comment:4 in reply to:  3 Changed 4 years ago by cypherpunks

Replying to nickm:

I'm guessing that because the crash is coming from within syslog_chk . But when I try to test this myself, by running only with Log notice syslog and Sandbox 1, I don't see a crash on my host.

Do you get a crash when you start Tor using a Torrc with only those two options?

Yes.

(Sandbox) Caught a bad syscall attempt (syscall socket)
tor(+0x142148)[0x1ce09be148]
/lib64/libc.so.6(socket+0x7)[0x2b072f90a07]
/lib64/libc.so.6(socket+0x7)[0x2b072f90a07]
/lib64/libc.so.6(+0xf16a0)[0x2b072f8a6a0]
/lib64/libc.so.6(__vsyslog_chk+0x3ef)[0x2b072f8aaff]
/lib64/libc.so.6(__syslog_chk+0x89)[0x2b072f8adf9]
tor(+0x135bb0)[0x1ce09b1bb0]
tor(tor_log+0xd0)[0x1ce09b2680]
tor(control_event_bootstrap+0x1e4)[0x1ce0971a74]
tor(do_main_loop+0x84)[0x1ce08b4234]
tor(tor_main+0x16c5)[0x1ce08b7225]
/lib64/libc.so.6(__libc_start_main+0x114)[0x2b072eb9134]
tor(+0x34519)[0x1ce08b0519]
#
# Minimal torrc so tor will work out of the box
#
Log notice syslog
SandBox 1
$ tor --version
Tor version 0.2.7.1-alpha (git-df76da0f3bfd6897).

comment:5 Changed 4 years ago by cypherpunks

This error may depends on how syslogd/rsyslog/syslog-ng is configured?

__vsyslog_chk() belongs to glibc:/misc/syslog.c

I cannot reproduce this on gentoo/hardening with normal syslog-ng listing on af_unix:/dev/log

comment:6 in reply to:  5 ; Changed 4 years ago by cypherpunks

Replying to cypherpunks:

This error may depends on how syslogd/rsyslog/syslog-ng is configured?

__vsyslog_chk() belongs to glibc:/misc/syslog.c

I cannot reproduce this on gentoo/hardening with normal syslog-ng listing on af_unix:/dev/log

Are you on Gentoo Hardened with the hardened toolchain and kernel?
I'm running on OpenRC which obviously affects how the syslog works. I haven't edited any syslog/rsyslog/etc configs, it's vanilla in that respect. I'm not using systemd.

My libseccomp is 2.1.1.

Last edited 4 years ago by cypherpunks (previous) (diff)

comment:7 in reply to:  6 ; Changed 4 years ago by cypherpunks

Replying to cypherpunks:

Replying to cypherpunks:

This error may depends on how syslogd/rsyslog/syslog-ng is configured?

__vsyslog_chk() belongs to glibc:/misc/syslog.c

I cannot reproduce this on gentoo/hardening with normal syslog-ng listing on af_unix:/dev/log

Are you on Gentoo Hardened with the hardened toolchain and kernel?
I'm running on OpenRC which obviously affects how the syslog works. I haven't edited any syslog/rsyslog/etc configs, it's vanilla in that respect. I'm not using systemd.
My libseccomp is 2.1.1.

So maybe __vsyslog_chk() did not find an af_unix:/dev/log socket and try to connect to UDP/514 syslog port.
Can you check if you running a syslog daemon and which listen sockets are provided.

# ss -lp | grep syslog
u_str  LISTEN     0      0      /var/run/syslog-ng.ctl 1561                  * 0                    users:(("syslog-ng",pid=836,fd=7))
u_dgr  UNCONN     0      0      /dev/log 1563                  * 0                    users:(("syslog-ng",pid=836,fd=13))

comment:8 in reply to:  7 Changed 4 years ago by cypherpunks

Replying to cypherpunks:

Replying to cypherpunks:

Replying to cypherpunks:

This error may depends on how syslogd/rsyslog/syslog-ng is configured?

__vsyslog_chk() belongs to glibc:/misc/syslog.c

I cannot reproduce this on gentoo/hardening with normal syslog-ng listing on af_unix:/dev/log

Are you on Gentoo Hardened with the hardened toolchain and kernel?
I'm running on OpenRC which obviously affects how the syslog works. I haven't edited any syslog/rsyslog/etc configs, it's vanilla in that respect. I'm not using systemd.
My libseccomp is 2.1.1.

So maybe __vsyslog_chk() did not find an af_unix:/dev/log socket and try to connect to UDP/514 syslog port.
Can you check if you running a syslog daemon and which listen sockets are provided.

# ss -lp | grep syslog
u_str  LISTEN     0      0      /var/run/syslog-ng.ctl 1561                  * 0                    users:(("syslog-ng",pid=836,fd=7))
u_dgr  UNCONN     0      0      /dev/log 1563                  * 0                    users:(("syslog-ng",pid=836,fd=13))

You're right. I didn't have a syslog running! Thanks. With syslog-ng, there's no crash anymore.
But should Tor crash without a syslog-ng? I didn't realise I was lacking one (hadn't caused any issues).

Obviously the Log line referring to syslog is an issue, but Tor probably shouldn't crash in seccomp.

comment:9 Changed 4 years ago by cypherpunks

Thanks for feedback.

@nickm
we may have at least two options:

  • allow full socket() syscall at seccomp filter (I don't like it because socket() can be used to leak data outside of tor process)
  • check for seccomp=true && linux=true && syslog conf option in use && syslog daemon not listening via fd and deal with it gracefully

Maybe it is possible to define socket() syscall _with_ explicit option data at seccomp filter?

In the meantime let's wait for Pluto pictures :)

Last edited 4 years ago by cypherpunks (previous) (diff)

comment:10 Changed 4 years ago by nickm

Keywords: PostFreeze027 added

I'd merge patches for these for 0.2.7 if they come in on time. In some cases, that will require figuring out an as-yet-unsolved bugs.

comment:11 Changed 4 years ago by nickm

Keywords: PostFreeze027 removed
Milestone: Tor: 0.2.7.x-finalTor: 0.2.8.x-final

Moving these tickets into 0.2.8. Not expecting to take patches for any into 0.2.7 at this late date. As usual, please say something if you disagree! :)

comment:12 Changed 4 years ago by dgoulet

Points: small

comment:13 Changed 4 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.9.x-final

Throw most 0.2.8 "NEW" tickets into 0.2.9. I expect that many of them will subsequently get triaged out.

comment:14 Changed 3 years ago by nickm

Owner: set to nickm
Status: newaccepted

comment:15 Changed 3 years ago by isabela

Milestone: Tor: 0.2.9.x-finalTor: 0.2.???

tickets market to be removed from milestone 029

comment:16 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:17 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:18 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:19 Changed 2 years ago by nickm

Keywords: 029-backport added; 026-backport removed
Severity: Normal

comment:20 Changed 2 years ago by nickm

Keywords: tor-client tor-relay linux sandbox 32bit added
Note: See TracTickets for help on using tickets.