tor

Tor 0.2.6.8 is released

Hi, I've just put out a new stable Tor release. It is not a high-urgency item for most clients and relays, but directory authorities should upgrade. Right now, the source is available on the website, and packages should become available one their maintainers build them.

Tor 0.2.6.8 fixes a bit of dodgy code in parsing INTRODUCE2 cells, and fixes an authority-side bug in assigning the HSDir flag. All directory authorities should upgrade.

Changes in version 0.2.6.8 - 2015-05-21
  • Major bugfixes (hidden services, backport from 0.2.7.1-alpha):
    • Revert commit that made directory authorities assign the HSDir flag to relay without a DirPort; this was bad because such relays can't handle BEGIN_DIR cells. Fixes bug 15850; bugfix on tor-0.2.6.3-alpha.
  • Minor bugfixes (hidden service, backport from 0.2.7.1-alpha):
    • Fix an out-of-bounds read when parsing invalid INTRODUCE2 cells on a client authorized hidden service. Fixes bug 15823; bugfix on 0.2.1.6-alpha.
  • Minor features (geoip):
    • Update geoip to the April 8 2015 Maxmind GeoLite2 Country database.
    • Update geoip6 to the April 8 2015 Maxmind GeoLite2 Country database.

Tor 0.2.7.1-alpha is released

Tor 0.2.7.1-alpha is the first alpha release in its series. It includes numerous small features and bugfixes against previous Tor versions, and numerous small infrastructure improvements. The most notable features are several new ways for controllers to interact with the hidden services subsystem.

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.7.1-alpha - 2015-05-12
  • New system requirements:
    • Tor no longer includes workarounds to support Libevent versions before 1.3e. Libevent 2.0 or later is recommended. Closes ticket 15248.
  • Major features (controller):
    • Add the ADD_ONION and DEL_ONION commands that allow the creation and management of hidden services via the controller. Closes ticket 6411.
    • New "GETINFO onions/current" and "GETINFO onions/detached" commands to get information about hidden services created via the controller. Part of ticket 6411.
    • New HSFETCH command to launch a request for a hidden service descriptor. Closes ticket 14847.
    • New HSPOST command to upload a hidden service descriptor. Closes ticket 3523. Patch by "DonnchaC".

  read more »

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.

Syndicate content Syndicate content