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

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Please update Torbirdy for jessie-backports!

I'll take over this release to ask you guys about an explanation for this https://metrics.torproject.org/userstats-relay-country.html?graph=userstats-relay-country&country=ae

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.

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

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

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

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:

# cat /var/lib/tor/cached-microdesc-consensus \
| 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-ips.txt

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

Thanks, Roger! I didn't know about these particularities of Tor protocol.

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

I'm also still waiting for 0.2.9.9 for arm... Or is the arm-architecture for some strange reason not affected by the 0.2.9.8 bugs?

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.

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?

Post new comment

  • Lines and paragraphs break automatically.
  • Allowed HTML tags: <em> <strong> <cite> <code> <ul> <ol> <li> <b> <i> <strike> <p> <br>

More information about formatting options

Syndicate content Syndicate content