[Secunia] Regarding Tor 0.1.2.15 Release Notes

[Roger Dingledine]

On Mon, Jul 23, 2007 at 05:06:07PM +0200, Secunia Research wrote:
> Hello,
> 
> We have noticed in your release notes for Tor 0.1.2.15 at:
> http://archives.seul.org/or/announce/Jul-2007/msg00000.html
> 
> "Major bugfixes (security):
>     - Fix a possible buffer overrun when using BSD natd support. Bug
>       found by croup.
>     - When sending destroy cells from a circuit's origin, don't include
>       the reason for tearing down the circuit. The spec says we didn't,
>       and now we actually don't. Reported by lodger.
>     - Keep streamids from different exits on a circuit separate. This
>       bug may have allowed other routers on a given circuit to inject
>       cells into streams. Reported by lodger; fixes bug 446.
>     - If there's a never-before-connected-to guard node in our list,
>       never choose any guards past it. This way we don't expand our
>       guard list unless we need to."
> 
> We are about to issue an advisory based on this information and we would
> appreciate to receive your comments on these issues before we
> publish our advisory.

Great. I'm also cc'ing this to the main user mailing list, so other
people can be up to date too.

> * Can the "possible buffer overrun" be exploited by an attacker and
> compromise the target system?

We just looked at it closer, and it appears to read off the end of
the buffer, but not write anything, so it shouldn't (heh) be that big
a problem.

In any case, this is only a problem if you added the Natdport
configuration option to your torrc file, which you would only have done
if you're on a really old BSD and also you were experimenting with the
new natd support.

So most users will not be affected by this.

> * What are the most severe impacts for each of the items mentioned?

Sending out the reason for tearing down your circuit relates to reduction
in anonymity, rather than system security. It might be usable by an
adversary who's trying to narrow down who you are out of a small set of
suspects; we don't have a specific attack in mind, and we don't think
that an attack like this would be the best way to attack Tor, but it's
best to fix it.

The "Keep streamids from different exits on a circuit separate" bug is
probably the biggest one. Tor servers in the middle of your circuit can
blindly inject data into your TCP stream -- they can't read anything, and
they have only a 1 in 2**16 chance of guessing which tag to use to make it
work, but those are still not good odds. As usual, if users use end-to-end
authentication (a la ssl or ssh), this attack won't work against them.

Lastly, the "don't expand your guard list without needing to" helps to
limit the number of new entry nodes you'll pick, which protects from
http://freehaven.net/anonbib/#hs-attack06 and other anonymity-related
attacks.

> * Under which circumstances are these exploitable and are there any
> mitigating factors?

Hope that helps,
--Roger