90% of exits vulnerable to TCP off-path attack
RFC-5961 CVE-2016-5696 http://www.theregister.co.uk/2016/08/10/linux_tor_users_open_corrupted_commu... FYI all
On Fri, Aug 12, 2016 at 11:27 AM, <starlight.2016q3@binnacle.cx> wrote:
RFC-5961 CVE-2016-5696 http://www.theregister.co.uk/2016/08/10/linux_tor_users_open_corrupted_commu... 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. 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. Right now I think one should not panic and should wait for the kernel people to do a proper fix. zw
On Fri, Aug 12, 2016 at 12:01:03PM -0400, Zack Weinberg wrote:
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.
Agreed. I attended the talk at Usenix Security this week, and the presenter seemed to think that if a TCP connection between two relays gets cut, then the first relay will redirect all those circuits to some other relay. If that were true, then you could do the "keep cutting the connection until your target circuit goes the way you want it to" attack. But Tor clients are the ones that choose their paths, and when a circuit fails, they throw it out and choose a new path, without memory of what links inside the Tor network did or didn't work in the past. So clients will effectively fail closed, meaning they will keep trying a circuit of their choice and you will keep trying to find it and tear it down, but you won't be able to "direct" their path in the way the authors thought. That said, this kind of TCP level attack is indeed neat, and people should keep thinking about ways to apply it, or something like it, to Tor. For an earlier paper in the same area, see also http://freehaven.net/anonbib/#tcp-tor-pets12
Right now I think one should not panic and should wait for the kernel people to do a proper fix.
Yes, this makes sense. Another option is to encourage people to remember that operating system diversity is important. :) https://torbsd.github.io/ --Roger
yeah that paper Spying in the Dark: TCP and Tor Traffic Analysis was also a very good read. i believe their rate reduction confirmation attack (as described in section 5.1) is applicable using the TCP challenge ACK inference side channel to gain the ability to perform injection attacks which manipulate the congestion management! an adversary with the ability to passively monitor a given server should be able to use the rate reduction attack + challenge ACK side channel to discover the guard relay of a tor connection to the server given enough time and bandwidth. the challenge ACK side channel can be used to discover TCP connections from the exit relay to a middle relay. Further the rate reduction attack could be used to confirm if a given TCP connection to a middle relay belongs to the target Tor circuit. this process is repeated to collect the rest of the relays in the circuit. in Off-Path TCP Exploits: Global Rate Limit Considered Dangerous section 4.2 they talk about their TCP 4-tuple inference attack which discovers connections from a known client to a known server's TCP port. they describe a clever way to utilize a binary or multi-bin search by parallelizing probes to many different ports and repeatedly observing side channel messages to confirm a given port range has a connection or not. this same parallelizing of probes definitely applies here. although our number of probes is much greater since it's multiplied by a large fraction of the tor relay consensus (exit, middle, guard relays). david On Fri, Aug 12, 2016 at 12:10:49PM -0400, Roger Dingledine wrote:
On Fri, Aug 12, 2016 at 12:01:03PM -0400, Zack Weinberg wrote:
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.
Agreed. I attended the talk at Usenix Security this week, and the presenter seemed to think that if a TCP connection between two relays gets cut, then the first relay will redirect all those circuits to some other relay. If that were true, then you could do the "keep cutting the connection until your target circuit goes the way you want it to" attack.
But Tor clients are the ones that choose their paths, and when a circuit fails, they throw it out and choose a new path, without memory of what links inside the Tor network did or didn't work in the past. So clients will effectively fail closed, meaning they will keep trying a circuit of their choice and you will keep trying to find it and tear it down, but you won't be able to "direct" their path in the way the authors thought.
That said, this kind of TCP level attack is indeed neat, and people should keep thinking about ways to apply it, or something like it, to Tor.
For an earlier paper in the same area, see also http://freehaven.net/anonbib/#tcp-tor-pets12
Right now I think one should not panic and should wait for the kernel people to do a proper fix.
Yes, this makes sense.
Another option is to encourage people to remember that operating system diversity is important. :) https://torbsd.github.io/
--Roger
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Zack Weinberg transcribed 1.3K bytes:
On Fri, Aug 12, 2016 at 11:27 AM, <starlight.2016q3@binnacle.cx> wrote:
RFC-5961 CVE-2016-5696 http://www.theregister.co.uk/2016/08/10/linux_tor_users_open_corrupted_commu... 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/75ff39ccc1bd5d3c455b6822ab09e533c55... Best regards, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt
participants (5)
-
dawuud -
isis agora lovecruft -
Roger Dingledine -
starlight.2016q3＠binnacle.cx -
Zack Weinberg