Tor 0.2.9.9 is released

by arma | January 23, 2017

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://utuhewzcso.oedi.net/ 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.
    • Fix Libevent detection on platforms without Libevent 1 headers installed. Fixes bug 21051; bugfix on 0.2.9.1-alpha.

Comments

Please note that the comment area below has been archived.

Anonymous (not verified) said:

January 23, 2017

Permalink

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.

Anonymous (not verified) said:

January 23, 2017

Permalink

"This bug affects all 0.2.9.x versions"
Tor Browser is not affected. It is built with -fwrapv.

The tor we ship in Tor Browser is affected as well which is why we rebuild parts of the upcoming Tor Browser bundles to pick the new tor versions up.

Anonymous (not verified) said:

January 25, 2017

Permalink

Oh, the hardened one is not affected, sure. But the others are going with undefined behavior now.

Anonymous (not verified) said:

January 24, 2017

Permalink

Oh, the hardened one is not affected, sure. But others are going with undefined behavior now.

Anonymous (not verified) said:

January 24, 2017

Permalink

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:

  1. # cat /var/lib/tor/cached-microdesc-consensus \<br />
  2.     | grep '^r ' | awk '{print $6}' | sort | uniq -d -c

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?

Well, the "why no more than 2" part is easy to answer: the directory authorities vote Running about no more than 2 relays per IP address:

https://gitweb.torproject.org/torspec.git/tree/proposals/109-no-sharing…

(Originally the plan was "no more than 3", but somewhere along the line it got changed to "no more than 2".)

You could check out the individual votes by directory authorities:
https://collector.torproject.org/archive/relay-descriptors/votes/
to see that some IP addresses have more than 2 relays on them, but they don't get Running votes for the extra ones.

Anonymous (not verified) said:

January 25, 2017

Permalink

Hello

The tor package version 0.2.9.9 from deb.torproject.org for armhf and armel does not seems to be aviliable but tor-geoipdb version 0.2.9.9 is availiable on jessie and strech.

Did you planned to release it later?

Regards

Anonymous (not verified) said:

January 25, 2017

Permalink

Sorry. You are not using Tor.
Your IP address appears to be: 162.243.117.41
TorLauncher NOTE: WARN DANGEROUS_SOCKS PROTOCOL=SOCKS5 ADDRESS=162.243.117.41:80
What's going on?

Sounds like you are using some program that you didn't specify, which is not Tor Browser? Maybe you have installed the "torbrowser-launcher" deb from Debian or Ubuntu, for example?

Actually, it looks like maybe you're using some non-standard program that isn't Tor Browser, *and* you've configured it in some surprising and broken way, to use a proxy or something.

My best advice is to discard whatever you were doing, and use Tor Browser.

Anonymous (not verified) said:

January 26, 2017

Permalink

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 no expert but here's my two cents.

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).

Thanks for so good reply!

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:

  1. I restart my VM, so it's rolled back to its original state (easy to make with dmsetup snapshots).
  2. 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.