Tor 0.2.7.4-rc is released

Tor 0.2.7.4-rc is the second release candidate in the 0.2.7 series. It fixes some important memory leaks, and a scary-looking (but mostly harmless in practice) invalid-read bug. It also has a few small bugfixes, notably fixes for compilation and portability on different platforms. If no further significant bounds are found, the next release will the the official stable release.

NOTE: This is a release candidate. We think we've squashed most of the bugs, but there are probably a few more left over.

You can download the source from the usual place on the website.
Packages should be up in a few days.

Changes in version 0.2.7.4-rc - 2015-10-21

  • Major bugfixes (security, correctness):
    • Fix an error that could cause us to read 4 bytes before the beginning of an openssl string. This bug could be used to cause Tor to crash on systems with unusual malloc implementations, or systems with unusual hardening installed. Fixes bug 17404; bugfix on 0.2.3.6-alpha.
  • Major bugfixes (correctness):
    • Fix a use-after-free bug in validate_intro_point_failure(). Fixes bug 17401; bugfix on 0.2.7.3-rc.

 

  • Major bugfixes (memory leaks):
    • Fix a memory leak in ed25519 batch signature checking. Fixes bug 17398; bugfix on 0.2.6.1-alpha.
    • Fix a memory leak in rend_cache_failure_entry_free(). Fixes bug 17402; bugfix on 0.2.7.3-rc.
    • Fix a memory leak when reading an expired signing key from disk. Fixes bug 17403; bugfix on 0.2.7.2-rc.
  • Minor features (geoIP):
    • Update geoip and geoip6 to the October 9 2015 Maxmind GeoLite2 Country database.
  • Minor bugfixes (compilation):
    • Repair compilation with the most recent (unreleased, alpha) vesions of OpenSSL 1.1. Fixes part of ticket 17237.
    • Fix an integer overflow warning in test_crypto_slow.c. Fixes bug 17251; bugfix on 0.2.7.2-alpha.
    • Fix compilation of sandbox.c with musl-libc. Fixes bug 17347; bugfix on 0.2.5.1-alpha. Patch from 'jamestk'.
  • Minor bugfixes (portability):
    • Use libexecinfo on FreeBSD to enable backtrace support. Fixes part of bug 17151; bugfix on 0.2.5.2-alpha. Patch from Marcin Cieślak.
  • Minor bugfixes (sandbox):
    • Add the "hidserv-stats" filename to our sandbox filter for the HiddenServiceStatistics option to work properly. Fixes bug 17354; bugfix on tor-0.2.6.2-alpha. Patch from David Goulet.
  • Minor bugfixes (testing):
    • Add unit tests for get_interface_address* failure cases. Fixes bug 17173; bugfix on 0.2.7.3-rc. Patch by fk/teor.
    • Fix breakage when running 'make check' with BSD make. Fixes bug 17154; bugfix on 0.2.7.3-rc. Patch by Marcin Cieślak.
    • Make the get_ifaddrs_* unit tests more tolerant of different network configurations. (Don't assume every test box has an IPv4 address, and don't assume every test box has a non-localhost address.) Fixes bug 17255; bugfix on 0.2.7.3-rc. Patch by "teor".
    • Skip backtrace tests when backtrace support is not compiled in. Fixes part of bug 17151; bugfix on 0.2.7.1-alpha. Patch from Marcin Cieślak.
  • Documentation:
    • Fix capitalization of SOCKS in sample torrc. Closes ticket 15609.
    • Note that HiddenServicePorts can take a unix domain socket. Closes ticket 17364.
Anonymous

October 24, 2015

Permalink

Does this fix Tor's vulnerability to threat#2 (state-level adversaries) on https://weakdh.org/? Apparently there are standard primes (and "Oakley Groups" based on them) that have been widely used for DH. Tor is explicity mentioned in the paper as one of the vulnerable applications.

Logjam was patched in the Tor Browser a good while ago. Links between nodes (client-relay and relay-relay) are protected via TLS 1.2, which should use ECDHE or 2048-bit DE keys. You can confirm this by running SSL tests against them. Circuit-level crypto (the onion-like encryption) uses Curve25519, which is not vulnerable to Logjam. I cannot find a mention of Tor in their paper, and while the Tor Browser was initially vulnerable, I do not believe that the Tor network itself was vulnerable, and as I said the Tor Browser is now patched.

The 0.2.7.x series has a hard requirement at compile time for a SSL library that supports at least one ECDHE curve.

1024 bit DH is still used as part of the hidden service protocol, but it is in a hybrid construct with RSA (The older TAP handshake), so should still be reasonably safe. Naturally this will be resolved completely when the next gen HS work gets done.

My question was not about Logjam but about Adrian et al's item#2: "threats from state-level adversaries". They suggest that one or more of the fixed 1024-bit primes has been "cracked", and that this is what has led to the NSA building their large infrastructure for eavesdropping on VPNs.

Tor is mentioned in the penultimate paragraph of section 2 of the conference paper, in connection with the Oakley Groups.

If 1024-bit is still used in HSs then let's hope for an early transition to more secure technologies.

Thanks for your answers anyway.

Indeed, the current HS design uses DH wrapped in RSA, so it actually resists these it's-all-one-group attacks.

And the next-gen HS design has stronger crypto to make it even more moot.

Anonymous

October 25, 2015

Permalink

having trouble using tor with my windows laptop :( it downloaded but cant connect through firewal;l

Anonymous

October 25, 2015

Permalink

I know This Is Not The Proper Spot For This Blog, But Where's Our Bi-Monthly Weekly Bog From Tor?? Something's Wrong ?? D-Hellman Problems Etc Etc?? Just PLZ Bring The Blog Back!! I Read It A Lot To Simi Keep up todate With All That's Tor. Thank's Plz Keep Tor Safe An Thus Inturn Keep Us Safe.Tor Should Not Be Concerened With Bio-Watches Bi- Phones, And All Other Nano-bio JUNK!! Plz Just Make Tor Safe And Extremly Private, THANKS fo all your help and Good Work O And Bring Back New's Blog Weeklt,Bi Monthle Etc . Weekly Would be NICE Thanks

Anonymous

October 27, 2015

Permalink

With javascipt open, the system time will be revealed by the sites you are visiting with your browser. Is that I should care about?