tor

Tor 0.2.6.4-rc is released

Tor 0.2.6.4-rc fixes an issue in the directory code that an attacker might be able to use in order to crash certain Tor directories. It also resolves some minor issues left over from, or introduced in, Tor 0.2.6.3-alpha or earlier.

If no serious issues are found in this release, the next 0.2.6 release will make 0.2.6 the officially stable branch of Tor.

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

NOTE: This is an alpha release. Please expect bugs.

Changes in version 0.2.6.4-rc - 2015-03-09
  • Major bugfixes (crash, OSX, security):
    • Fix a remote denial-of-service opportunity caused by a bug in OSX's _strlcat_chk() function. Fixes bug 15205; bug first appeared in OSX 10.9.
  • Major bugfixes (relay, stability, possible security):
    • Fix a bug that could lead to a relay crashing with an assertion failure if a buffer of exactly the wrong layout is passed to buf_pullup() at exactly the wrong time. Fixes bug 15083; bugfix on 0.2.0.10-alpha. Patch from "cypherpunks".
    • Do not assert if the 'data' pointer on a buffer is advanced to the very end of the buffer; log a BUG message instead. Only assert if it is past that point. Fixes bug 15083; bugfix on 0.2.0.10-alpha.

  read more »

A new alpha series begins: Tor 0.2.6.1-alpha is released

Tor 0.2.6.1-alpha is the first release in the Tor 0.2.6.x series. It includes numerous code cleanups and new tests, and fixes a large number of annoying bugs. Out-of-memory conditions are handled better than in 0.2.5, pluggable transports have improved proxy support, and clients now use optimistic data for contacting hidden services. Also, we are now more robust to changes in what we consider a parseable directory object, so that tightening restrictions does not have a risk of introducing infinite download loops.

This is the first alpha release in a new series, so expect there to be bugs. Users who would rather test out a more stable branch should stay with 0.2.5.x for now.

This announcement is for the source release only; I'd expect that compiled packages for several platforms should be available over the next several days.

Changes in version 0.2.6.1-alpha - 2014-10-30
  • New compiler and system requirements:
    • Tor 0.2.6.x requires that your compiler support more of the C99 language standard than before. The 'configure' script now detects whether your compiler supports C99 mid-block declarations and designated initializers. If it does not, Tor will not compile.

      We may revisit this requirement if it turns out that a significant number of people need to build Tor with compilers that don't bother implementing a 15-year-old standard. Closes ticket 13233.

    • Tor no longer supports systems without threading support. When we began working on Tor, there were several systems that didn't have threads, or where the thread support wasn't able to run the threads of a single process on multiple CPUs. That no longer holds: every system where Tor needs to run well now has threading support. Resolves ticket 12439.

  read more »

Tor 0.2.5.10 is released! (and Tor 0.2.3.x is deprecated)

Tor 0.2.5.10 is the first stable release in the 0.2.5 series.

It adds several new security features, including improved denial-of-service resistance for relays, new compiler hardening options, and a system-call sandbox for hardened installations on Linux (requires seccomp2). The controller protocol has several new features, resolving IPv6 addresses should work better than before, and relays should be a little more CPU-efficient. We've added support for more OpenBSD and FreeBSD transparent proxy types. We've improved the build system and testing infrastructure to allow unit testing of more parts of the Tor codebase. Finally, we've addressed several nagging pluggable transport usability issues, and included numerous other small bugfixes and features mentioned below.

This release marks end-of-life for Tor 0.2.3.x; those Tor versions have accumulated many known flaws; everyone should upgrade.

Below we list all changes in 0.2.5.10 since the 0.2.4.x series; for a list of changes in individual alpha releases, see the ChangeLog. read more »

Changes in version 0.2.5.10 - 2014-10-24

Tor misused by criminals

Tor misused by criminals

Several people contacted The Tor Project recently because some software told them to install the Tor Browser to access a website. There is no affiliation between the criminals who wrote this software and Tor.

What happened here?

The computer is probably infected with what's called ransomware. This is a kind of malicious software which restricts access to the files and demands a ransom. In this case the authors of the ransomware CryptoLocker set up a website which is only reachable by using Tor. That is why people are thinking that the software is somehow related to The Tor Project.

In fact, CryptoLocker is unrelated to The Tor Project. We didn't produce it, and we didn't ask to be included in the criminal infection of any computer. We cannot help you with your infection. However, according to the BBC you may be able to decrypt your files for free. If not, Bleeping Computer can provide more information.

We, the people of Tor, are very sorry to hear that some individual misused the anonymity granted by our service. The vast majority of our users use Tor in a responsible way. Thank you for your understanding.

Advisory: remote DoS when using Tor with recent OpenSSL versions built with the "no-ssl3" option

This is a copy of the message Nick Mathewson sent to the tor-talk & tor-relays mailing lists.

Hello, relay operators!

There's one important bugfix in the 0.2.5.9-rc release that relay operators should know about. If you have a version of OpenSSL that came out last week (like 1.0.1j, 1.0.0, ) and if your version of OpenSSL is built with the "no-ssl3" flag, then it's possible to crash your Tor relay remotely if you don't upgrade to 0.2.5.9-rc or to 0.2.4.25 (when that's out).

This appears to be an OpenSSL bug. The Tor releases in question contain a workaround for it.

To tell if your version of OpenSSL was built with 'no-ssl3': run:

openssl s_client -ssl3 -connect www.torproject.org:443

If it gives you output beginning with something like:

CONNECTED(00000003)
140632971298688:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3
alert handshake failure:s3_pkt.c:1257:SSL alert number 40
140632971298688:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl
handshake failure:s3_pkt.c:596:

then you're fine and you don't need to upgrade Tor on your relay. But if it says something that starts with:

unknown option -ssl3
usage: s_client args

then you need to upgrade Tor.

Some questions and answers:

Q: Does this affect clients?
A: No. Only relays.

Q: Does this affect me if I'm running a version of OpenSSL other than 1.0.1j, 1.0.0o, or 0.9.8zc?
A: No. Only those versions.

Q: Does this affect me if I'm running a version of OpenSSL configured without the "no-ssl3" option?
A: No. Only versions that were built with the "no-ssl3" option are affected.

Q: Does the OpenSSL team know?
A: Yes. Have a look at this thread. Also, before I saw that thread, I informed them the other day.

Q: Does this affect Tor packages?
A: I don't think that we shipped any packages where we used the "no-ssl3" flag to diable ssl3. So only if you're using OpenSSL from another source (say, your operating system) will you be affected.

Q: What can I do to remediate this problem?
A: You can upgrade to the most recent Tor, or you can use a version of OpenSSL built without the "no-ssl3" flag. Downgrading your OpenSSL is not recommended.

Q: What is the potential impact of this bug?
A: If a relay is affected by this bug, anybody can make the relay crash remotely. It does not enable any data leaks or remote code execution. Still, the ability to selectively disable relays might enable a sophisticated attacker to do some kinds of traffic analysis more efficiently. So, fix your relay if it's affected.

Q: Should we run in circles and freak out?
A: Not this time. We should just make sure we fix affected relays.

Q: Hey, Nick, you didn't explain this properly!
A: Please send a follow-up message that explains it better. :)

Tor 0.2.5.7-rc is out

Tor 0.2.5.7-rc fixes several regressions from earlier in the 0.2.5.x release series, and some long-standing bugs related to ORPort reachability testing and failure to send CREATE cells. It is the first release candidate for the Tor 0.2.5.x series.

The tarball and signature file are currently available from
https://www.torproject.org/dist/
and packages and bundles will be available soon.

Changes in version 0.2.5.7-rc - 2014-09-11

  • Major bugfixes (client, startup):
    • Start making circuits as soon as DisabledNetwork is turned off.
      When Tor started with DisabledNetwork set, it would correctly
      conclude that it shouldn't build circuits, but it would mistakenly
      cache this conclusion, and continue believing it even when
      DisableNetwork is set to 0. Fixes the bug introduced by the fix
      for bug 11200; bugfix on 0.2.5.4-alpha.

    • Resume expanding abbreviations for command-line options. The fix
      for bug 4647 accidentally removed our hack from bug 586 that
      rewrote HashedControlPassword to __HashedControlSessionPassword
      when it appears on the commandline (which allowed the user to set
      her own HashedControlPassword in the torrc file while the
      controller generates a fresh session password for each run). Fixes
      bug 12948; bugfix on 0.2.5.1-alpha.

    • Warn about attempts to run hidden services and relays in the same
      process: that's probably not a good idea. Closes ticket 12908.
  • Major bugfixes (relay):
    • Avoid queuing or sending destroy cells for circuit ID zero when we
      fail to send a CREATE cell. Fixes bug 12848; bugfix on 0.0.8pre1.
      Found and fixed by "cypherpunks".

    • Fix ORPort reachability detection on relays running behind a
      proxy, by correctly updating the "local" mark on the controlling
      channel when changing the address of an or_connection_t after the
      handshake. Fixes bug 12160; bugfix on 0.2.4.4-alpha.
  • Minor features (bridge):
    • Add an ExtORPortCookieAuthFileGroupReadable option to make the
      cookie file for the ExtORPort g+r by default.
  • Minor features (geoip):
    • Update geoip and geoip6 to the August 7 2014 Maxmind GeoLite2
      Country database.
  • Minor bugfixes (logging):
    • Reduce the log severity of the "Pluggable transport proxy does not
      provide any needed transports and will not be launched." message,
      since Tor Browser includes several ClientTransportPlugin lines in
      its torrc-defaults file, leading every Tor Browser user who looks
      at her logs to see these notices and wonder if they're dangerous.
      Resolves bug 13124; bugfix on 0.2.5.3-alpha.

    • Downgrade "Unexpected onionskin length after decryption" warning
      to a protocol-warn, since there's nothing relay operators can do
      about a client that sends them a malformed create cell. Resolves
      bug 12996; bugfix on 0.0.6rc1.

    • Log more specific warnings when we get an ESTABLISH_RENDEZVOUS
      cell on a cannibalized or non-OR circuit. Resolves ticket 12997.

    • When logging information about an EXTEND2 or EXTENDED2 cell, log
      their names correctly. Fixes part of bug 12700; bugfix
      on 0.2.4.8-alpha.

    • When logging information about a relay cell whose command we don't
      recognize, log its command as an integer. Fixes part of bug 12700;
      bugfix on 0.2.1.10-alpha.

    • Escape all strings from the directory connection before logging
      them. Fixes bug 13071; bugfix on 0.1.1.15. Patch from "teor".
  • Minor bugfixes (controller):
    • Restore the functionality of CookieAuthFileGroupReadable. Fixes
      bug 12864; bugfix on 0.2.5.1-alpha.

    • Actually send TRANSPORT_LAUNCHED and HS_DESC events to
      controllers. Fixes bug 13085; bugfix on 0.2.5.1-alpha. Patch
      by "teor".
  • Minor bugfixes (compilation):
    • Fix compilation of test.h with MSVC. Patch from Gisle Vanem;
      bugfix on 0.2.5.5-alpha.

    • Make the nmake make files work again. Fixes bug 13081. Bugfix on
      0.2.5.1-alpha. Patch from "NewEraCracker".

    • In routerlist_assert_ok(), don't take the address of a
      routerinfo's cache_info member unless that routerinfo is non-NULL.
      Fixes bug 13096; bugfix on 0.1.1.9-alpha. Patch by "teor".

    • Fix a large number of false positive warnings from the clang
      analyzer static analysis tool. This should make real warnings
      easier for clang analyzer to find. Patch from "teor". Closes
      ticket 13036.
  • Distribution (systemd):
    • Verify configuration file via ExecStartPre in the systemd unit
      file. Patch from intrigeri; resolves ticket 12730.

    • Explicitly disable RunAsDaemon in the systemd unit file. Our
      current systemd unit uses "Type = simple", so systemd does not
      expect tor to fork. If the user has "RunAsDaemon 1" in their
      torrc, then things won't work as expected. This is e.g. the case
      on Debian (and derivatives), since there we pass "--defaults-torrc
      /usr/share/tor/tor-service-defaults-torrc" (that contains
      "RunAsDaemon 1") by default. Patch by intrigeri; resolves
      ticket 12731.
  • Documentation:
    • Adjust the URLs in the README to refer to the new locations of
      several documents on the website. Fixes bug 12830. Patch from
      Matt Pagan.

    • Document 'reject6' and 'accept6' ExitPolicy entries. Resolves
      ticket 12878.

On the recent Black Hat 2014 Talk Cancellation

As posted by Roger on the Tor-Talk mailing list:

Hi folks,

Journalists are asking us about the Black Hat talk on attacking Tor that got cancelled. We're still working with CERT to do a coordinated disclosure of the details (hopefully this week), but I figured I should share a few details with you earlier than that.

1) We did not ask Black Hat or CERT to cancel the talk. We did (and still do) have questions for the presenter and for CERT about some aspects of the research, but we had no idea the talk would be pulled before the announcement was made.

2) In response to our questions, we were informally shown some materials. We never received slides or any description of what would be presented in the talk itself beyond what was available on the Black Hat Webpage.

3) We encourage research on the Tor network along with responsible disclosure of all new and interesting attacks. Researchers who have told us about bugs in the past have found us pretty helpful in fixing issues, and generally positive to work with.

[Edit 30 July 2014: here is the security advisory we posted.]

On being targeted by the NSA

As quoted in the original article on Das Erste:

We've been thinking of state surveillance for years because of our work in places where journalists are threatened. Tor's anonymity is based on distributed trust, so observing traffic at one place in the Tor network, even a directory authority, isn't enough to break it. Tor has gone mainstream in the past few years, and its wide diversity of users -- from civic-minded individuals and ordinary consumers to activists, law enforcement, and companies -- is part of its security. Just learning that somebody visited the Tor or Tails website doesn't tell you whether that person is a journalist source, someone concerned that her Internet Service Provider will learn about her health conditions, or just someone irked that cat videos are blocked in her location.

Trying to make a list of Tor's millions of daily users certainly counts as widescale collection. Their attack on the bridge address distribution service shows their "collect all the things" mentality -- it's worth emphasizing that we designed bridges for users in countries like China and Iran, and here we are finding out about attacks by our own country. Does reading the contents of those mails violate the wiretap act? Now I understand how the Google engineers felt when they learned about the attacks on their infrastructure.

Tor Challenge 2014

We are excited to announce the EFF has just launched the second Tor Challenge!

This challenge is somewhat different from the previous edition, as there are now incentives tied to running relays for an extended period of time. The goal is to educate and encourage lots of people to setup relays, and continue to contribute throughout the year.

EFF will be giving out a "limited-edition" sticker to relay operators who keep their relay running for at least 12 months. On top of that, people running a 1MB/s+ relay for 12 months will also receive a Tor t-shirt!

The more high-bandwidth relays we have, the better off the network is as a whole and the more people we will be able to help stay safe and secure online; so please join the EFF & the Tor Project for the 2014 Tor Challenge! Also, help us spread the word about this challenge by sharing this with others!

tor 0.2.4.22 released

This is a slightly belated announcement for the release of tor 0.2.4.22. Going into the future, we're planning to publish this information on the blog shortly after it is sent to tor-announce.

Release information is always published first on tor-talk.

Tor 0.2.4.22 backports numerous high-priority fixes from the Tor 0.2.5 alpha release series. These include blocking all authority signing keys that may have been affected by the OpenSSL "heartbleed" bug, choosing a far more secure set of TLS ciphersuites by default, closing a couple of memory leaks that could be used to run a target relay out of RAM, and several others.

Here is the complete changelog:

Changes in version 0.2.4.22 - 2014-05-16:

  • Major features (security, backport from 0.2.5.4-alpha):
    • Block authority signing keys that were used on authorities
      vulnerable to the "heartbleed" bug in OpenSSL (CVE-2014-0160). (We
      don't have any evidence that these keys _were_ compromised; we're
      doing this to be prudent.) Resolves ticket 11464.
  • Major bugfixes (security, OOM):
    • Fix a memory leak that could occur if a microdescriptor parse
      fails during the tokenizing step. This bug could enable a memory
      exhaustion attack by directory servers. Fixes bug 11649; bugfix
      on 0.2.2.6-alpha.
  • Major bugfixes (TLS cipher selection, backport from 0.2.5.4-alpha):
    • The relay ciphersuite list is now generated automatically based on
      uniform criteria, and includes all OpenSSL ciphersuites with
      acceptable strength and forward secrecy. Previously, we had left
      some perfectly fine ciphersuites unsupported due to omission or
      typo. Resolves bugs 11513, 11492, 11498, 11499. Bugs reported by
      'cypherpunks'. Bugfix on 0.2.4.8-alpha.

    • Relays now trust themselves to have a better view than clients of
      which TLS ciphersuites are better than others. (Thanks to bug
      11513, the relay list is now well-considered, whereas the client
      list has been chosen mainly for anti-fingerprinting purposes.)
      Relays prefer: AES over 3DES; then ECDHE over DHE; then GCM over
      CBC; then SHA384 over SHA256 over SHA1; and last, AES256 over
      AES128. Resolves ticket 11528.

    • Clients now try to advertise the same list of ciphersuites as
      Firefox 28. This change enables selection of (fast) GCM
      ciphersuites, disables some strange old ciphers, and stops
      advertising the ECDH (not to be confused with ECDHE) ciphersuites.
      Resolves ticket 11438.
  • Minor bugfixes (configuration, security):
    • When running a hidden service, do not allow TunneledDirConns 0:
      trying to set that option together with a hidden service would
      otherwise prevent the hidden service from running, and also make
      it publish its descriptors directly over HTTP. Fixes bug 10849;
      bugfix on 0.2.1.1-alpha.
  • Minor bugfixes (controller, backport from 0.2.5.4-alpha):
    • Avoid sending a garbage value to the controller when a circuit is
      cannibalized. Fixes bug 11519; bugfix on 0.2.3.11-alpha.
  • Minor bugfixes (exit relay, backport from 0.2.5.4-alpha):
    • Stop leaking memory when we successfully resolve a PTR record.
      Fixes bug 11437; bugfix on 0.2.4.7-alpha.
  • Minor bugfixes (bridge client, backport from 0.2.5.4-alpha):
    • Avoid 60-second delays in the bootstrapping process when Tor is
      launching for a second time while using bridges. Fixes bug 9229;
      bugfix on 0.2.0.3-alpha.
  • Minor bugfixes (relays and bridges, backport from 0.2.5.4-alpha):
    • Give the correct URL in the warning message when trying to run a
      relay on an ancient version of Windows. Fixes bug 9393.
  • Minor bugfixes (compilation):
    • Fix a compilation error when compiling with --disable-curve25519.
      Fixes bug 9700; bugfix on 0.2.4.17-rc.
  • Minor bugfixes:
    • Downgrade the warning severity for the the "md was still
      referenced 1 node(s)" warning. Tor 0.2.5.4-alpha has better code
      for trying to diagnose this bug, and the current warning in
      earlier versions of tor achieves nothing useful. Addresses warning
      from bug 7164.
  • Minor features (log verbosity, backport from 0.2.5.4-alpha):
    • When we run out of usable circuit IDs on a channel, log only one
      warning for the whole channel, and describe how many circuits
      there were on the channel. Fixes part of ticket 11553.
  • Minor features (security, backport from 0.2.5.4-alpha):
    • Decrease the lower limit of MaxMemInCellQueues to 256 MBytes (but
      leave the default at 8GBytes), to better support Raspberry Pi
      users. Fixes bug 9686; bugfix on 0.2.4.14-alpha.
  • Documentation (backport from 0.2.5.4-alpha):
    • Correctly document that we search for a system torrc file before
      looking in ~/.torrc. Fixes documentation side of 9213; bugfix on
      0.2.3.18-rc.
Syndicate content Syndicate content