[tor-relays] 90% of exits vulnerable to TCP off-path attack

[isis agora lovecruft]

Zack Weinberg transcribed 1.3K bytes:
> On Fri, Aug 12, 2016 at 11:27 AM,  <starlight.2016q3 at binnacle.cx> wrote:
> > RFC-5961
> > CVE-2016-5696
> > http://www.theregister.co.uk/2016/08/10/linux_tor_users_open_corrupted_communications/
> > FYI all
> 
> Tor's use of TLS _should_ mean that the worst an attacker can do here
> is denial-of-service.  The Register article suggests that they might
> also be able to force the use of specific exit relays (by disrupting
> connections that don't go through those relays) but weaponizing that
> against specific users (rather than everyone trying to use an exit the
> attacker doesn't like) strikes me as nontrivial.

The attack itself is quite brilliant.  However, having read the paper [0] and
discussed with other members of the network team, we're under the impression
that the authors have a misunderstanding on how Tor's path selection algorithm
functions.

Their idea is essentially: "when an connection between a middle relay and an
exit relay fails, the *middle relay* chooses a new exit."  The way this path
selection actually works, when a connection fails, is that the client forgets
the path of that circuit entirely, and goes back to step #1 of the algorithm,
effectively choosing an entirely new path without any memory of the path
chosen before.  Since the selection of the nodes in this new path (and in
fact, any path) is dependent on their bandwidth weight from the consensus, the
client has just as much probability to select the same exit as they did the
last time.  Ergo, to use this attack to "funnel" Tor users into using a
particular exit is of equal (or higher) difficulty (in terms of bandwidth of
the nodes you would need to run) to conducting a Sybil attack on the whole
network.

tl;dr: Running a Sybil attack would be more effective.

> Also, if you read the paper, raising the global rate limit (as
> suggested by the reg. article) doesn't help; it only slows the
> attacker down a little.

The accepted patch [1] solves the issue, and does so by randomising the time
window that the global variable applies to.

[0]: http://www.cs.ucr.edu/~zhiyunq/pub/sec16_TCP_pure_offpath.pdf
[1]: https://github.com/torvalds/linux/commit/75ff39ccc1bd5d3c455b6822ab09e533c551f758

Best regards,
-- 
 ♥Ⓐ isis agora lovecruft
_________________________________________________________
OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
Current Keys: https://fyb.patternsinthevoid.net/isis.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1240 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20160812/2c900306/attachment.sig>