Main menu

Tor 0.2.9.9 is released

Tor 0.2.9.9 fixes a denial-of-service bug where an attacker could cause relays and clients to crash, even if they were not built with the --enable-expensive-hardening option. This bug affects all 0.2.9.x versions, and also affects 0.3.0.1-alpha: all relays running an affected version should upgrade.
This release also resolves a client-side onion service reachability bug, and resolves a pair of small portability issues.
You can download the source code from https://dist.torproject.org/ but most users should wait for the upcoming Tor Browser release, or for their upcoming system package updates.

Changes in version 0.2.9.9 - 2017-01-23

Major bugfixes (security):

Downgrade the "-ftrapv" option from "always on" to "only on when --enable-expensive-hardening is provided." This hardening option, like others, can turn survivable bugs into crashes -- and having it on by default made a (relatively harmless) integer overflow bug into a denial-of-service bug. Fixes bug 21278 (TROVE-2017-001); bugfix on 0.2.9.1-alpha.

Major bugfixes (client, onion service):

Fix a client-side onion service reachability bug, where multiple socks requests to an onion service (or a single slow request) could cause us to mistakenly mark some of the service's introduction points as failed, and we cache that failure so eventually we run out and can't reach the service. Also resolves a mysterious "Remote server sent bogus reason code 65021" log warning. The bug was introduced in ticket 17218, where we tried to remember the circuit end reason as a uint16_t, which mangled negative values. Partially fixes bug 21056 and fixes bug 20307; bugfix on 0.2.8.1-alpha.

Minor features (geoip):

Update geoip and geoip6 to the January 4 2017 Maxmind GeoLite2 Country database.

Minor bugfixes (portability):

Avoid crashing when Tor is built using headers that contain CLOCK_MONOTONIC_COARSE, but then tries to run on an older kernel without CLOCK_MONOTONIC_COARSE. Fixes bug 21035; bugfix on 0.2.9.1-alpha.

Hmm, why do you think that undefined behavior after integer overflow bug is relatively harmless? -ftrapv and -fwrapv were developed specially to convert UB to defined: crash or wrap. So, if you want Tor to continue execution with "survivable bug", -fwrapv is your choice.

Yeah, I think the next step is to open up a discussion about how and when to put -ftrapv, or maybe -fwrapv, back into place. We figured step one was to fix the immediate remote DoS vulnerability, then step two will be to clean up the other pieces.

I noticed strange network anomaly. There are IPs which host many nodes to utilize the whole bandwidth. At the moment Tor network has 7216 nodes. Among these nodes 210 IPs are used to host few nodes. You can get full list of them using this simple command:

Why there is no any IP which hosts more than 2 nodes? None of them has 3, 4 or more. All of them (210) host exactly 2 nodes! How it can be explained? I first noticed it long time ago, so I can confirm this is valid at least for about 2 last years. Can it be vague indication that many of them are managed by the same party?

Do we have any mechanism to make use of ControlPort option safe? This option is used by many applications such as Tor Brower, which, it turn, are running in completely non-trusted environment. So, if environment (e.g. VM with Tor browser) is compromised, by using access to ControlPort the anonymity will be compromised too, as access to this port allows to do almost anything concerning configuration of Tor.

It would be good to have "restricted ControlPort" which allows the application to only restart tor chains [kill -1 $(pidof tor)] and nothing more; and, better, restart only those chains that are used by this application (so, tor chains of other applications will not be affected). Is it already somehow implemented or not? Do we have any proposal or ticket on this thing?

I'm not exactly sure what you mean by "tor chains". If you mean circuits, then these can be isolated without ControlPort access, using IsolateSOCKSAuth and using a SOCKS username and password in the client. I believe TorBrowser does this for the "New Tor circuit for this site" button. Torsocks does it for the IsolatePID (-i) option.

I think Yawning is working on a sort of application-level "firewall" that sits between the client and the ControlPort, so that applications can only access/modify data relevant to themselves, and blocks unsafe commands. Think of it like a permissions system for the ControlPort. At least that's my understanding -- read some of his blog posts for more info about this and his sandbox.

Regarding `kill -1 $(pidof tor)` SIGHUP is already reserved for online reloading torrc. I'm uncertain whether this has the same affect as NEWNYM, and I probably wouldn't rely on it for such (unless documented). They could dedicate another signal like SIGUSR1 to this, but I don't think it would be useful in a lot of cases. It would only work when the tor process and the client process are running as the same user on the same machine, and the signal might even get blocked by SELinux/AppArmor/Tomyo in some cases.

I'm not even sure NEWNYM is what you want for this kind of use case, either. NEWNYM prevents all built circuits from being reused, not just those being used by the application that wants a new identity. Theoretically, this could be used to associate different streams (applications) with each other in a kind of high-tech correlation attack under certain conditions. What you want is only for the application (that's asking for a new circuit) to have its existing circuits retired, but leave other applications' circuits on the standard 10 minute cycle. I don't think it would be portable enough for Tor to operate this way by trying to identify the sending process of a signal (not to mention associate the sender's PID with sockets connected to the SOCKSPort).

I'm not exactly sure what you mean by "tor chains". If you mean circuits

Yes, exactly.

I believe TorBrowser does this for the "New Tor circuit for this site" button.

In typical install, yes, but my case is different, because my TBB is running inside VM, and Tor is running on another OS (host system). Furthermore, VM has no access to ControlPort (I forbid it intentionally). This isolation gives me good security (similar to Whonix), but it has this issue with NEWNYM...

I think Yawning is working on a sort of application-level "firewall" that sits between the client and the ControlPort, so that applications can only access/modify data relevant to themselves, and blocks unsafe commands. Think of it like a permissions system for the ControlPort.

Thanks for information. I think you mean his works on sandboxing. It's good to know, however, I don't think this is a proper replacement. System kernel, iptables and tor itself will be always more trusted than 3rd order application firewall. It would be more reliable to make this isolation on the level of Tor itself.

SIGHUP is already reserved for online reloading torrc. I'm uncertain whether this has the same affect as NEWNYM, and I probably wouldn't rely on it for such (unless documented).

Good point. However, I remember that -1 signal was recommended and used for circuits restart for many years. Hopefully, this behavior is preserved at least for backward compatibility.

It would only work when the tor process and the client process are running as the same user on the same machine, and the signal might even get blocked by SELinux/AppArmor/Tomyo in some cases.

Well, I don't have experience with SELinux etc, but I have experience with VMs. Since ControlPort is blocked in my setup, now it works as follows.

Let's assume for simplicity, that each application is just a particular VM, which connects to particular Tor's SocksPort on host machine. So, when I need to refresh any of my VMs, I do the following:

I restart my VM, so it's rolled back to its original state (easy to make with dmsetup snapshots).

I restart all Tor circuits with kill -1 signal.

Both of these steps are run by scripts from my host machine, so this is the place where VMs are managed and where Tor is running. However, I don't want to restart all circuits, because, as you correctly pointed it out, it gives extra correlation. I want to restart only those circuits that are used by my VM. In other words, all circuits, which were associated to particular SocksPort must be marked as retired, and new circuits must be created instead of them. This is exactly what I want.

I'm not even sure NEWNYM is what you want for this kind of use case, either. NEWNYM prevents all built circuits from being reused, not just those being used by the application that wants a new identity. Theoretically, this could be used to associate different streams (applications) with each other in a kind of high-tech correlation attack under certain conditions.

Exactly. But I use kill -1 because I don't have better option. However, I could connect to ControlPort from my host machine (not VM, where application is running) and make exactly this command, NEWNYM. AFAIK, stem and tor-arm have this functionality, I only need to understand the protocol and write my script for that. Maybe, in this protocol I can do NEWNYM associated with particular SocksPort, but I'm not sure.

What you want is only for the application (that's asking for a new circuit) to have its existing circuits retired, but leave other applications' circuits on the standard 10 minute cycle. I don't think it would be portable enough for Tor to operate this way by trying to identify the sending process of a signal (not to mention associate the sender's PID with sockets connected to the SOCKSPort).

You are completely right. This is what I want. Surely, proper mechanism shouldn't be some signal, but something like "restricted port". So that I point each my VM to specific SocksPort and RestricedControlPort, and then be sure that communication of my VM with Tor's RestrictedControlPort refresh only the circuits used by that SocksPort.

Basically, instead of making extra application-level firewall filtering request to single and very dangerous ControlPort (like root access to Tor!), I suggest to make "users" of each SocksPort distinguished by different ports, which are completely safe. System's security is much easier to reach by standard kernel's firewall than by any 3rd level mechanisms.

Finally, it would be like this:

SocksPort 9000
RestrictedControlPort 9001

SocksPort 9002
RestrictedControlPort 9003

ControlPort 9004

Or, maybe in other syntax:

SocksPort 9000,9001
SocksPort 9000,9003
ControlPort 9004

So that, ports 9001 and 9003 will behave exactly like 9004 on those operations that are permitted for VM's on ports 9000 and 9002, respectively.

Recent Updates

Hi! There's a new alpha release available for download. If you build Tor from source, you can download the source code for 0.3.3.2-alpha from the usual place on the website. Packages should be available over the coming weeks, with a new alpha Tor Browser release some time in February.

Remember, this is an alpha release: you should only run this if you'd like to find and report more bugs than usual.

Tor 0.3.3.2-alpha is the second alpha in the 0.3.3.x series. It introduces a mechanism to handle the high loads that many relay operators have been reporting recently. It also fixes several bugs in older releases. If this new code proves reliable, we plan to backport it to older supported release series.

Changes in version 0.3.3.2-alpha - 2018-02-10

Major features (denial-of-service mitigation):

Give relays some defenses against the recent network overload. We start with three defenses (default parameters in parentheses). First: if a single client address makes too many concurrent connections (>100), hang up on further connections. Second: if a single client address makes circuits too quickly (more than 3 per second, with an allowed burst of 90) while also having too many connections open (3), refuse new create cells for the next while (1-2 hours). Third: if a client asks to establish a rendezvous point to you directly, ignore the request. These defenses can be manually controlled by new torrc options, but relays will also take guidance from consensus parameters, so there's no need to configure anything manually. Implements ticket 24902.

Major bugfixes (netflow padding):

Stop adding unneeded channel padding right after we finish flushing to a connection that has been trying to flush for many seconds. Instead, treat all partial or complete flushes as activity on the channel, which will defer the time until we need to add padding. This fix should resolve confusing and scary log messages like "Channel padding timeout scheduled 221453ms in the past." Fixes bug 22212; bugfix on 0.3.1.1-alpha.