Tor 0.2.1.12-alpha is released

by phobos | February 9, 2009

Tor 0.2.1.12-alpha features several more security-related fixes. You
should upgrade, especially if you run an exit relay (remote crash) or
a directory authority (remote infinite loop), or you're on an older
(pre-XP) or not-recently-patched Windows (remote exploit). It also
includes a big pile of minor bugfixes and cleanups.

https://www.torproject.org/download.html.en

Changes in version 0.2.1.12-alpha - 2009-02-08
Security fixes:

  • Fix an infinite-loop bug on handling corrupt votes under certain
    circumstances. Bugfix on 0.2.0.8-alpha.
  • Fix a temporary DoS vulnerability that could be performed by
    a directory mirror. Bugfix on 0.2.0.9-alpha; reported by lark.
  • Avoid a potential crash on exit nodes when processing malformed
    input. Remote DoS opportunity. Bugfix on 0.2.1.7-alpha.

Minor bugfixes:

  • Let controllers actually ask for the "clients_seen" event for
    getting usage summaries on bridge relays. Bugfix on 0.2.1.10-alpha;
    reported by Matt Edman.
  • Fix a compile warning on OSX Panther. Fixes bug 913; bugfix against
    0.2.1.11-alpha.
  • Fix a bug in address parsing that was preventing bridges or hidden
    service targets from being at IPv6 addresses.
  • Solve a bug that kept hardware crypto acceleration from getting
    enabled when accounting was turned on. Fixes bug 907. Bugfix on
    0.0.9pre6.
  • Remove a bash-ism from configure.in to build properly on non-Linux
    platforms. Bugfix on 0.2.1.1-alpha.
  • Fix code so authorities _actually_ send back X-Descriptor-Not-New
    headers. Bugfix on 0.2.0.10-alpha.
  • Don't consider expiring already-closed client connections. Fixes
    bug 893. Bugfix on 0.0.2pre20.
  • Fix another interesting corner-case of bug 891 spotted by rovv:
    Previously, if two hosts had different amounts of clock drift, and
    one of them created a new connection with just the wrong timing,
    the other might decide to deprecate the new connection erroneously.
    Bugfix on 0.1.1.13-alpha.
  • Resolve a very rare crash bug that could occur when the user forced
    a nameserver reconfiguration during the middle of a nameserver
    probe. Fixes bug 526. Bugfix on 0.1.2.1-alpha.
  • Support changing value of ServerDNSRandomizeCase during SIGHUP.
    Bugfix on 0.2.1.7-alpha.
  • If we're using bridges and our network goes away, be more willing
    to forgive our bridges and try again when we get an application
    request. Bugfix on 0.2.0.x.

Minor features:

  • Support platforms where time_t is 64 bits long. (Congratulations,
    NetBSD!) Patch from Matthias Drochner.
  • Add a 'getinfo status/clients-seen' controller command, in case
    controllers want to hear clients_seen events but connect late.

Build changes:

  • Disable GCC's strict alias optimization by default, to avoid the
    likelihood of its introducing subtle bugs whenever our code violates
    the letter of C99's alias rules.

The original announcement can be found at http://archives.seul.org/or/talk/Feb-2009/msg00054.html

Comments

Please note that the comment area below has been archived.

Actually, it did install. What most likely failed is the automatic installation of torbutton into Firefox. This is literally the last thing the installer does. Everything else is installed fine, I bet.

Anonymous (not verified) said:

February 13, 2009

Permalink

I have tried and can't work...

BTW....where should i report this if I put this into a wrong post?

Alex (not verified) said:

February 15, 2009

Permalink

Are there any updates regarding Tor and German Data Retention ?
I found only a relatively old update (https://blog.torproject.org/blog/tor%2C-germany%2C-and-data-retention).

I'm asking because some nodes in JAP implemented data retention recently: Here is what they log: (from http://anon.inf.tu-dresden.de/dataretention_en.html)

=============================
Therefore the Mixes of the AN.ON project will log the following data:
1. A first Mix logs the IP-address, the date and time of incoming connections as well as the outgoing channel numbers of the channels to the next Mix.
2. A middle Mix logs incoming and outgoing channel numbers as well as date and time of the channel openings.
3. A last Mix logs the incoming channel numbers, the date and time of channel openings and closings, the source port number of outgoing connections as well as the date and time of openings of outgoing connections.
...
neither IP-addresses of contacted servers nor requested URLs will be logged.
=============================

German version of the same text is here: http://anon.inf.tu-dresden.de/dataretention_de.html. In JAP forum however, however, it was explained that TU Dresden implemented more than required by law.

Anonymous - no more (not verified) said:

February 26, 2009

Permalink

With the intoduction of version 2.1.6 Alpha you introduced a new seriouse security issue.
If you are a Chinese who risk go to prison for your opinions or a Russian journalist who risk to be assasined or an Amerikan citisen who don't wan't the goverment to spy on them, you are not safe anymore until you fixed this issue with TOR.
Even if people is not using the new country filter option in torrc...:
Example:
ExcludeNodes CN,GB,DE,US

...but only uses IP filters & namefilters...:
ExcludeNodes 0.0.0.0/5,147.0.0.0/8,111.111.111.111/32,jalopy,nixnix

..that worked up until version 2.1.5 Alpha this will not work properly anymore.
TOR NOW USES NODES YOU BLOCK IN TORRC AS EXITNODES !!!
This is a very seriouse security issue that you failed to fix in version 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.1.12.
How could you possibly miss to fix this issue?
Is it done on purpose to serve demands from certain country(s) ?

If no one reports these issues, then it's difficult for us to find them. We welcome help in improving our unit tests and feature testing.

We don't do any secret requests. Everything we do is published via code commits (see or-cvs), blogged about, or tracked in the bug tracker.

If this has been going on for so long, I'm surprised no one else opened a bug tracker issue for it.

Anonymous (not verified) said:

March 13, 2009

Permalink

Actually, it did install. What most likely failed is the automatic installation of torbutton into Firefox . This is literally the last thing the installer does. Everything else is installed fine, I bet.