New stable Tor releases, with security fixes and DoS prevention: 0.3.2.10, 0.3.1.10, 0.2.9.15

Today, we made several new stable Tor releases.  Together, they fix an issue in directory authorities, and backport a feature to improve relays' resistance of denial-of-service attacks. In addition, the 0.3.2.10 release fixes a security bug affecting relays running earlier 0.3.2.x versions.

To summarize:

  • Relays (and bridges) running 0.3.2.1-alpha through 0.3.2.9 should upgrade.
  • Directory authorities should upgrade.
  • Relays (and bridges) running 0.3.3.1-alpha should upgrade.
  • All other relays (and bridges) may wish to upgrade in order to improve their
    resistance to denial-of-service attacks.

If you build Tor from source, you can fetch the latest source code from https://dist.torproject.org/. New packages for relays should be available in the coming days.

The 0.3.2.10 changelog is below. For the changes in 0.2.9.15 and 0.3.1.10, please see the ChangeLog file distributed along with the source code. The changes in 0.3.3.3-alpha will be listed in my next blog post.


Tor 0.3.2.10 is the second stable release in the 0.3.2 series. It backports a number of bugfixes, including important fixes for security issues.

It includes an important security fix for a remote crash attack against directory authorities, tracked as TROVE-2018-001.

Additionally, it backports a fix for a bug whose severity we have upgraded: Bug 24700, which was fixed in 0.3.3.2-alpha, can be remotely triggered in order to crash relays with a use-after-free pattern. As such, we are now tracking that bug as TROVE-2018-002 and CVE-2018-0491, and backporting it to earlier releases. This bug affected versions 0.3.2.1-alpha through 0.3.2.9, as well as version 0.3.3.1-alpha.

This release also backports our new system for improved resistance to denial-of-service attacks against relays.

This release also fixes several minor bugs and annoyances from earlier releases.

Relays running 0.3.2.x SHOULD upgrade to one of the versions released today, for the fix to TROVE-2018-002. Directory authorities should also upgrade. (Relays on earlier versions might want to update too for the DoS mitigations.)

Changes in version 0.3.2.10 - 2018-03-03

  • Major bugfixes (denial-of-service, directory authority, backport from 0.3.3.3-alpha):
    • Fix a protocol-list handling bug that could be used to remotely crash directory authorities with a null-pointer exception. Fixes bug 25074; bugfix on 0.2.9.4-alpha. Also tracked as TROVE-2018-001 and CVE-2018-0490.
  • Major bugfixes (scheduler, KIST, denial-of-service, backport from 0.3.3.2-alpha):
    • Avoid adding the same channel twice in the KIST scheduler pending list, which could lead to remote denial-of-service use-after-free attacks against relays. Fixes bug 24700; bugfix on 0.3.2.1-alpha.

 

  • Major features (denial-of-service mitigation, backport from 0.3.3.2-alpha):
    • 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 (onion services, retry behavior, backport from 0.3.3.1-alpha):
    • Fix an "off by 2" error in counting rendezvous failures on the onion service side. While we thought we would stop the rendezvous attempt after one failed circuit, we were actually making three circuit attempts before giving up. Now switch to a default of 2, and allow the consensus parameter "hs_service_max_rdv_failures" to override. Fixes bug 24895; bugfix on 0.0.6.
    • New-style (v3) onion services now obey the "max rendezvous circuit attempts" logic. Previously they would make as many rendezvous circuit attempts as they could fit in the MAX_REND_TIMEOUT second window before giving up. Fixes bug 24894; bugfix on 0.3.2.1-alpha.
  • Major bugfixes (protocol versions, backport from 0.3.3.2-alpha):
    • Add Link protocol version 5 to the supported protocols list. Fixes bug 25070; bugfix on 0.3.1.1-alpha.
  • Major bugfixes (relay, backport from 0.3.3.1-alpha):
    • Fix a set of false positives where relays would consider connections to other relays as being client-only connections (and thus e.g. deserving different link padding schemes) if those relays fell out of the consensus briefly. Now we look only at the initial handshake and whether the connection authenticated as a relay. Fixes bug 24898; bugfix on 0.3.1.1-alpha.
  • Major bugfixes (scheduler, consensus, backport from 0.3.3.2-alpha):
    • The scheduler subsystem was failing to promptly notice changes in consensus parameters, making it harder to switch schedulers network-wide. Fixes bug 24975; bugfix on 0.3.2.1-alpha.
  • Minor features (denial-of-service avoidance, backport from 0.3.3.2-alpha):
    • Make our OOM handler aware of the geoip client history cache so it doesn't fill up the memory. This check is important for IPv6 and our DoS mitigation subsystem. Closes ticket 25122.
  • Minor features (compatibility, OpenSSL, backport from 0.3.3.3-alpha):
    • Tor will now support TLS1.3 once OpenSSL 1.1.1 is released. Previous versions of Tor would not have worked with OpenSSL 1.1.1, since they neither disabled TLS 1.3 nor enabled any of the ciphersuites it requires. Now we enable the TLS 1.3 ciphersuites. Closes ticket 24978.
  • Minor features (geoip):
    • Update geoip and geoip6 to the February 7 2018 Maxmind GeoLite2 Country database.
  • Minor features (logging, diagnostic, backport from 0.3.3.2-alpha):
    • When logging a failure to check a hidden service's certificate, also log what the problem with the certificate was. Diagnostic for ticket 24972.
  • Minor bugfix (channel connection, backport from 0.3.3.2-alpha):
    • Use the actual observed address of an incoming relay connection, not the canonical address of the relay from its descriptor, when making decisions about how to handle the incoming connection. Fixes bug 24952; bugfix on 0.2.4.11-alpha. Patch by "ffmancera".
  • Minor bugfixes (denial-of-service, backport from 0.3.3.3-alpha):
    • Fix a possible crash on malformed consensus. If a consensus had contained an unparseable protocol line, it could have made clients and relays crash with a null-pointer exception. To exploit this issue, however, an attacker would need to be able to subvert the directory authority system. Fixes bug 25251; bugfix on 0.2.9.4-alpha. Also tracked as TROVE-2018-004.
  • Minor bugfix (directory authority, backport from 0.3.3.2-alpha):
    • Directory authorities, when refusing a descriptor from a rejected relay, now explicitly tell the relay (in its logs) to set a valid ContactInfo address and contact the bad-relays@ mailing list. Fixes bug 25170; bugfix on 0.2.9.1.
  • Minor bugfixes (build, rust, backport from 0.3.3.1-alpha):
  • Minor bugfixes (onion services, backport from 0.3.3.2-alpha):
    • Remove a BUG() statement when a client fetches an onion descriptor that has a lower revision counter than the one in its cache. This can happen in normal circumstances due to HSDir desync. Fixes bug 24976; bugfix on 0.3.2.1-alpha.
  • Minor bugfixes (logging, backport from 0.3.3.2-alpha):
    • Don't treat inability to store a cached consensus object as a bug: it can happen normally when we are out of disk space. Fixes bug 24859; bugfix on 0.3.1.1-alpha.
  • Minor bugfixes (performance, fragile-hardening, backport from 0.3.3.1-alpha):
    • Improve the performance of our consensus-diff application code when Tor is built with the --enable-fragile-hardening option set. Fixes bug 24826; bugfix on 0.3.1.1-alpha.
  • Minor bugfixes (OSX, backport from 0.3.3.1-alpha):
    • Don't exit the Tor process if setrlimit() fails to change the file limit (which can happen sometimes on some versions of OSX). Fixes bug 21074; bugfix on 0.0.9pre5.
  • Minor bugfixes (spec conformance, backport from 0.3.3.3-alpha):
    • Forbid "-0" as a protocol version. Fixes part of bug 25249; bugfix on 0.2.9.4-alpha.
    • Forbid UINT32_MAX as a protocol version. Fixes part of bug 25249; bugfix on 0.2.9.4-alpha.
  • Minor bugfixes (testing, backport from 0.3.3.1-alpha):
    • Fix a memory leak in the scheduler/loop_kist unit test. Fixes bug 25005; bugfix on 0.3.2.7-rc.
  • Minor bugfixes (v3 onion services, backport from 0.3.3.2-alpha):
    • Look at the "HSRend" protocol version, not the "HSDir" protocol version, when deciding whether a consensus entry can support the v3 onion service protocol as a rendezvous point. Fixes bug 25105; bugfix on 0.3.2.1-alpha.
  • Code simplification and refactoring (backport from 0.3.3.3-alpha):
    • Update the "rust dependencies" submodule to be a project-level repository, rather than a user repository. Closes ticket 25323.
  • Documentation (backport from 0.3.3.1-alpha):
    • Document that operators who run more than one relay or bridge are expected to set MyFamily and ContactInfo correctly. Closes ticket 24526.
olderOS

March 04, 2018

Permalink

what happened in v3 hidden service???

tor just look for 3!!! not 4 hops, change in spec.????

[debug] onion_extend_cpath(): Path is 2 long; we want 3

compared to original hidden service

[debug] onion_extend_cpath(): Path is 3 long; we want 4

BIG PROBLEM!!!

after re-testing with 0.3.2.9, it is confirmed, there is somthing WRONG in v3 hidden service in the latest version (0.3.2.10)

0.3.2.10 reduce to 3 hops (0.3.2.9 or earlier used 4 hops) when client connecting to v3 hidden service

That's BAD

olderOS

March 05, 2018

Permalink

improving relay's resistance at a dos attack : what is the difference with a dos attack at the relay & at the site (whatever its name/address) ?
is it not the same thing ? i mean , on the onion-network , a relay is the first wall then the config of the site in second no ?

olderOS

April 06, 2018

Permalink

I realize that windows users of tor (not torbrowser) are now untouchables, but for those of us that have no choice but to use windows in certain situations, would it be to much to ask to at least put copies of the win32 files in the win32 directory? That way we don't have to keep looking in different places to see if it has been released yet. For example, I don't know if a win32 executable for 0.2.9.15 has been released and I can't find it, or it simply won't be released.

I do appreciate the work that torproject does.

Join the discussion...

This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.

11 + 2 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.