As was highlighted by /u/lordredvampire three days ago and got so little attention probably due to the article not explaining anything correctly, there is a vulnerability in TCP in all linux systems that could affect Tor users and DNM operators.
Actual explanation here: https://blog.patternsinthevoid.net/cve-2016-5696-and-its-effects-on-tor.html
tl;dr: This vulnerability is quite serious, but it doesn't effect the Tor network any more than it effects the rest of the internet. In particular, the Tor-specific attacks mentioned in the paper will not work as described.
More:
The attack described in the paper is elegant. In terms of its impact, 96.6% of the Alexa top one million are running Linux kernels, and hence are likely vulnerable. The previously described global ACK counter enables various side-channels across TCP connections, meaning that a blind attacker can determine information about:
- whether Alice and Bob are currently communicating over TCP,
- what the correct TCP sequence number is, and
- what the range of the valid window is.
The attacker does this by sending various crafted packets to the receiver (i.e. via a side-channel) while the sender is simultaneously sending valid packets to the receiver. The combined state of the attacker's and the sender's effects upon the global counter, for each of the above pieces of information, can be determined by whether the attacker receives either 99 or 100 ACKs in response:
https://blog.patternsinthevoid.net/static/images/2015/12/card.jpeg
The authors go on to claim the attack can be used to influence a Tor user's path through the network. However, the authors seem to have a misunderstanding regarding how Tor's path selection algorithm functions.
Their idea is summarised in the last paragraph of ยง7.2 of the paper (emphasis mine):
"In general, we believe that a DoS attack against Tor connections can have a devastating impact on both the availability of the service as a whole and the privacy guarantees that it can provide. The default policy in Tor is that if a connection is down between two relay nodes, say a middle relay and an exit relay, the middle relay will pick a different exit relay to establish the next connection. If an attacker can dictate which connections are down (via reset attacks), then the attacker can potentially force the use of certain exit relays."
This is is technically incorrect. The way Tor's path selection algorithm 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. Therefore, to use this attack to "funnel" (as the authors describe) Tor users into using a particular exit node is of equal difficulty -- in terms of bandwidth of the nodes you would need to run -- to conducting a Sybil attack on the whole network.
Although, with a high-bandwidth exit in a sybil attack, the attacker has a high (and importantly, to the attack's benefit, independent) probability that an exit it controls will get picked by the client. Whereas with this attack, the bandwidth weighting is likely detrimental to pulling off the attack, since the exits you're injecting RSTs into still have independently high probabilities of being chosen again. In other words, knocking nodes out of the network doesn't do anything to change their probability of being chosen, it merely makes them unavailable and thus only amounts to a DoS attack, not a path bias attack.
While the attack on Tor -- as stated in the paper -- does not work, the attack itself is impressive, and we encourage these (and other!) researchers to think of ways the attack might apply to Tor (and other networks).
Their attack does work as a general denial-of-service against not just Tor relays, but literally against anything running Linux.
The accepted Linux kernel patch solves the issue, and does so by randomising the time window that the global variable applies to.
Thanks to /u/speckz for posting this at /r/TOR.
It actually does apply to Tor a bit - even though the attacker can't force the target towards particular nodes directly, they can still DoS every circuit the target chooses that doesn't facilitate the attack. This could amplify the effectiveness of a Sybil attack, but just how much is hard to say. It could potentially make a cheap (low-number) Sybil attack actually viable, if the attacker were patient enough.
By the way, any Tor node operators or other GNU/Linux users can instantly prevent this attack with the following two commands (as the root user or with
sudo
), no reboot or patching necessary (though the actual kernel patch solves it in a different way, and it should still be applied):So I encourage folks to do so.
Note that this assumes that your sysctl.conf is in that location (make sure it is beforehand).