- tor-relays - lists.torproject.org

Security advisory: Please upgrade to today's OpenSSL.
by Nick Mathewson 25 Mar '21

25 Mar '21

Hi, all! There is a new version of OpenSSL out today, with a security advisory that affects Tor. The vulnerability is CVE-2021-3449, as described on https://www.openssl.org/news/secadv/20210325.txt . It affects OpenSSL versions 1.1.1 through 1.1.1j. OpenSSL 1.1.1k is the first version with a fix. I haven't tested this bug, but I believe that it would allow an adversary to remotely crash Tor relays and authorities. It won't have any effect on Tor clients. I suggest that everybody should upgrade to the latest OpenSSL when it becomes available on their platform. best wishes, -- Nick

1 0

Failed upgrade
by r1610091651 24 Mar '21

24 Mar '21

Hi FYI So I've upgraded tor package from 0.4.4.6 to 0.4.5.7-1~xenial+1. No other changes. Yet on startup tor is complaining about mis-configuration: Mar 23 20:55:02.928 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Mar 23 20:55:02.929 [notice] Read configuration file "/etc/tor/torrc". Mar 23 20:55:02.932 [warn] Configuration port ORPort 9443 superseded by ORPort <local-ip>:9443 Mar 23 20:55:02.932 [warn] We are listening on an ORPort, but not advertising any ORPorts. This will keep us from building a router descriptor, and make us impossible to use. Mar 23 20:55:02.932 [warn] Failed to parse/validate config: Misconfigured server ports Mar 23 20:55:02.932 [err] Reading config failed--see warnings above. config: ORPort <local-ip>:9443 NoAdvertise ORPort 9443 NoListen IPv4Only AddressDisableIPv6 1 OutboundBindAddress <local-ip> This config is according to spec and worked with 4.4.6. Seems to be related to thes issues, except for me it's blocking: tor fails to start. https://gitlab.torproject.org/tpo/core/tor/-/issues/40300 https://gitlab.torproject.org/tpo/core/tor/-/issues/40302 I had to add 0.0.0.0 as ip to make tor start, although that's not documented... ORPort <local-ip>:9443 NoAdvertise ORPort 0.0.0.0:9443 NoListen IPv4Only Regards

2 1

is this valid bridge config
by gi vian 23 Mar '21

23 Mar '21

hello, i want to run bridge. i have configured using tor relay configurator(1). is this valid or can it be improved. config ------ ORPort auto SocksPort 0 BridgeRelay 1 ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs4 0.0.0.0:8042 ExtOrPort auto Log notice file /var/log/tor/notices.log ExitPolicy reject *:* ------ regards, vian (1) https://tor-relay.co/

2 1

Circuit Creation Madness: Anyone else still experiencing (extremely) excessive clients / (possibly) modified relays creating millions upon millions of circuits?
by William Kane 23 Mar '21

23 Mar '21

@tor-relays: Sorry for being quite noisy recently but I really need to know how many people are suffering from the same madness I am encountering right now. Quick excerpt from the log: ... Mar 22 09:48:10 <hostname_redacted> tor[pid_redacted]: Mar 22 09:48:10.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [12420 similar message(s) suppressed in last 120 seconds] Mar 22 09:49:10 <hostname_redacted> tor[pid_redacted]: Mar 22 09:49:10.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [31764 similar message(s) suppressed in last 60 seconds] Mar 22 09:50:10 <hostname_redacted> tor[pid_redacted]: Mar 22 09:50:10.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [104748 similar message(s) suppressed in last 60 seconds] Mar 22 09:51:10 <hostname_redacted> tor[pid_redacted]: Mar 22 09:51:10.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [364165 similar message(s) suppressed in last 60 seconds] Mar 22 09:52:10 <hostname_redacted> tor[pid_redacted]: Mar 22 09:52:10.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [509474 similar message(s) suppressed in last 60 seconds] Mar 22 09:53:10 <hostname_redacted> tor[pid_redacted]: Mar 22 09:53:10.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [241332 similar message(s) suppressed in last 60 seconds] ... This then goes on for a while, stopping at a few million suppressed messages / circuit creation attempts. Sorry, but 1 million circuit creation requests in just 5 minutes, there is no way that this is legitimate behavior we are seeing - this is also what was previously used to get my relay oom-killed but that I have fixed so the legitimate clients hopefully don't suffer too much anymore. If any other relay operators are encountering the same log entries or behavior, please don't hesitate to reply. Added tor-dev(a)lists.torproject.org as a CC as they might want to know about this. @tor-dev: I suspect some kind of denial-of-service attack against onion services or a more targeted attack against singular relays for guard discovery / traffic confirmation attacks. Might be smart to add some code which, if this scenario is triggered, lists offenders by hashes of their signing keys (if relay), or IP addresses (if client). There doesn't seem to be a defense against this, and the new connect() rate-limit added through ticket 40253 also won't handle this as the connection is already ACK'd and established, and a malicious relay with custom source code could do whatever it was programmed to do anyway. - William

2 2

ECONNREFUSED
by tor 23 Mar '21

23 Mar '21

Hi All, I've been running a bridge on my home lan. I'm able to successfully attach to the bridge on the lan and from the wan. There are established circuits and clients: https://metrics.torproject.org/rs.html#details/E120A0492F789F5367EAD84C64F9… According to the tcp reachablilty test everything is reachable. However, the status page keeps saying I'm dysfunctional with a ECONNREFUSED: https://bridges.torproject.org/status?id=E120A0492F789F5367EAD84C64F92EE279… So everything seems to be working on my end. -matt

3 2

Question
by Андрей Гвоздев 23 Mar '21

23 Mar '21

What does it mean "Tor's file descriptor usage is at 90%. If you run out Tor will be unable to continue functioning."?

2 1

Questing regarding Team Cymru Tor Relays and Bridges
by Lisa Winter 23 Mar '21

23 Mar '21

Hello list, I just visited BridgeDB and got a bridge from "Team Cymru", according to the whois of the IP - should the Tor Project really allow a company trying to "track and take down threat actors and criminals around the globe" host a substantial portion of the network, according to their info page: https://team-cymru.com/company/ The following was also very concerning: "Team Cymru is comprised of former…" - ... - Law enforcement - ISP backbone engineers - ... I suspect that they log connections to their relays and bridges, and maybe even more. Such companies profit from gathering and selling information's, exploits and the likes. bad-relays rejected this message, which is concerning.. I hope someone here could redirect it to the right people, or do the Tor Project higher-ups know the people behind Team Cymru and vouch for them? Bye, Lisa Winter

3 3

Sunsetting C3WLittleGem and C3WPhantomStreak
by MacLemon 18 Mar '21

18 Mar '21

Hi! FYI: We sadly have to sunset two of our relays due to persistent network/upling problems with the vSphere cluster of our hosting provider. It wasn't possible to solve these issues in about a year. To reduce our volunteers' time investment for no gain, we'll turn of C3WLittleGem and C3WPhantomStreak in the next few days. If you want to have a last look at them, here's a link to our family. https://metrics.torproject.org/rs.html#search/family:B1F09810C4F7B9D30F483D… We'll continue running C3WEyeOfSauron and hope being able to add more relays again in the future. Best regards MacLemon (on behalf of Chaos Computer Club Wien (C3W))

2 1

Re: [tor-relays] Did 'Sandbox 1' break Tor for anyone else on 0.4.5.6?
by William Kane 17 Mar '21

17 Mar '21

Hi Peter, >Would be great if you could get details about the failing call. I already thought of gathering said details by tracing the process, but did not want to risk my uptime statistics, which would inevitably happen if I had to restart the server and service over and over (I disabled tracing globally through the Yama LSM as a security measure, i.e. kernel.yama.ptrace_scope == 3) - recently I lost the guard flag multiple times, caused by some sort of attack that I already reported on this list (tor-relays) - someone kept creating a fuckton of circuits through my relay (averaging 90k per minute), thus causing tor to run out of memory / get oom-killed by the kernel before it could even step in and close the circuits - if it was even trying to, it would make sense for the DoS mitigation code to be active only for the first link in the circuit aka the guard, and my node simply being a middle-only relay, it got completely stomped by said attack. After somewhat mitigating this attack by tweaking MaxMemInQueues, creating a bigger swap file and tuning vm.swappiness, I regained the guard flag, but then the hypervisor my KVM box is running under experienced some issues and had to be rebooted - once again, I received no notice of that until the relay was already offline for a few days, causing me to lose the guard flag again. Seems like luck is just not on my side these days, or well, it's been weeks now. > You should simply see a Permission Denied if the capability is the problem. Here's a copy from stdout, only happening if Sandbox is set to 1.: Mar 15 20:15:20.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. Mar 15 20:15:21.000 [warn] fstat() on directory /var/lib/tor_debug failed. Mar 15 20:15:21.000 [err] Can't create/check datadirectory /var/lib/tor_debug Mar 15 20:15:21.000 [err] Error initializing keys; exiting Running it as a privileged user does not change thing, so no permissions issue: Mar 15 20:17:24.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. Mar 15 20:17:24.000 [warn] You are running Tor as root. You don't need to, and you probably shouldn't. Mar 15 20:17:25.000 [warn] fstat() on directory /var/lib/tor_debug failed. Mar 15 20:17:25.000 [err] Can't create/check datadirectory /var/lib/tor_debug Mar 15 20:17:25.000 [err] Error initializing keys; exiting I've traced down the origin of the fstat() call to this piece of code: https://github.com/torproject/tor/blob/master/src/lib/fs/dir.c#L158 However, looking at the code that establishes and populates seccomp rules, it seems like fstat and it's 64 bit counterpart are not subject to (parameter) filtering, i.e. seccomp_rule_add_0 is invoked with the parameter SCMP_ACT_ALLOW, reading the manpage for seccomp_rule_add(3) reveals: "The seccomp filter will have no effect on the thread calling the syscall if it matches the filter rule." References: https://github.com/torproject/tor/blob/master/src/lib/sandbox/sandbox.c#L148 https://github.com/torproject/tor/blob/master/src/lib/sandbox/sandbox.c#L15… https://man7.org/linux/man-pages/man3/seccomp_rule_add.3.html So, even though technically, seccomp should allow these syscalls to be invoked, no matter which parameters are passed, somehow enabling the whole sandbox subsystem still breaks fstat. We are getting into tor-dev@ territory here, so maybe someone who is more experienced with the code base could figure out why this is happening, I'm pretty good at C/C++ on Linux / Windows and all the shenanigans that come with it, but lack time to debug this further. I've added tor-dev(a)lists.torproject.org as a CC just in case. - William 2021-03-15 17:10 GMT, Peter Gerber <tor(a)arbitrary.ch>: > Hi William > > William Kane: >> Hi everyone, >> >> Ever since I upgraded to tor version 0.4.5.6, enabling tor's built-in >> seccomp sandbox completely breaks tor, i.e. it gets killed by the >> kernel on start for a seccomp violation (fstat(..)) - sandboxing >> worked fine on 0.4.4.6, my system configuration did not change between >> the updates. > > Tor itself usually fails with a Permission Denied error when a syscall > fails due to seccomp. So, this is rather odd. > >> I figured this was happening because I do not grant the >> CAP_DAC_READ_SEARCH capability, but I'm not so sure anymore if that's >> the reason. > > You should simply see a Permission Denied if the capability is the problem. > > Would be great if you could get details about the failing call. If > seccomp is involved, you should be able to get details like this: > > • install package auditd > • make sure auditd is running > • crash Tor > • find the syscall with `ausearch -ts recent -i` > > Peter >

2 2

Did 'Sandbox 1' break Tor for anyone else on 0.4.5.6?
by William Kane 16 Mar '21

16 Mar '21

Hi everyone, Ever since I upgraded to tor version 0.4.5.6, enabling tor's built-in seccomp sandbox completely breaks tor, i.e. it gets killed by the kernel on start for a seccomp violation (fstat(..)) - sandboxing worked fine on 0.4.4.6, my system configuration did not change between the updates. Not specifying 'Sandbox 1' in the torrc allows tor to fully start as usual, I had to disable it post-update in order to be able to continue running my relay. /etc/tor/torrc: ORPort 37.157.195.83:38619 ORPort [2a02:2b88:2:1::3239:0]:38619 Nickname michaelscott ContactInfo ttallink(a)googlemail.com ControlPort 9051 SocksPort 0 CookieAuthentication 1 ExitPolicy reject *:* DataDirectory /var/lib/tor # Sandbox 1 ShutdownWaitLength 120 MaxMemInQueues 672MB /usr/lib/systemd/system/tor.service: [Unit] Description=Anonymizing Overlay Network After=network.target [Service] User=tor Type=simple ExecStart=/usr/bin/tor -f /etc/tor/torrc ExecReload=/usr/bin/kill -HUP $MAINPID KillSignal=SIGINT LimitNOFILE=32768 PrivateDevices=yes [Install] WantedBy=multi-user.target /etc/systemd/system/tor.service.d/override.conf: [Service] PrivateTmp=yes ProtectHome=yes ProtectSystem=strict ProtectKernelLogs=yes ProtectKernelModules=yes ProtectKernelTunables=yes ProtectControlGroups=yes NoNewPrivileges=yes RestrictSUIDSGID=yes RestrictAddressFamilies=AF_INET AF_INET6 ReadWritePaths=/var/lib/tor CapabilityBoundingSet=CAP_NET_BIND_SERVICE TimeoutStopSec=2min 15s I'm running ArchLinux with the 5.11.4 kernel, Tor is still sandboxed by systemd so this is not a huge issue but I would like to be able to continue using the built-in sandbox as well as systemd's sandboxing options in order to maximize process isolation. Did anyone else run into this? I would have posted a bug report but due to various reason I am not able to do so right now. I figured this was happening because I do not grant the CAP_DAC_READ_SEARCH capability, but I'm not so sure anymore if that's the reason. Any help is greatly appreciated. - William

2 1