tl;dr: This vulnerability is quite serious, but it doesn’t affect the Tor network any more than it affects the rest of the internet. In particular, the Tor-specific attacks mentioned in the paper will not work as described.
Recently, an excellent paper, entitled “Off-Path TCP Exploits: Global Rate Limit Considered Dangerous,” was published by Yue Cao, Zhiyun Qian, Zhongjie Wang, Tuan Dao, Srikanth V. Krishnamurthy, and Lisa M. Marvel at USENIX Security 2016.
The paper describes the 2012 modifications of RFC5961 to the specification of the Transmission Control Protocol (TCP), the latter of which is used to transport roughly 90% of our data across the internet. The modification was meant to protect against TCP “blind in-window” attacks.
When a TCP packet is sent, the sender and receiver both know a number, called the sequence number, that this packet should have. If the sequence number is not correct, various (complicated, boring) things may happen, but the important part is that neither the sender nor the receiver actually believes that this is a valid packet. Instead, they assume something went wrong somehow, or that an active attacker is attempting to inject packets into their communication stream. The term blind simply means that an attacker is unable to directly observe the packets going between the sender and receiver, but is usually instead trying to use some side-channel to determine this information. There’s another part of the TCP specification which describes windowing — which simply means (did I mention that TCP is very complicated and boring…) that the sequence number was “correct enough” — that is, that the sequence number was within the right range. Specification nerds have long argued over what “correct enough” means, because apparently they find this topic absolutely riveting.
The fix to the TCP blind in-window attack was to specify that, under certain conditions, if the TCP sequence number doesn’t match what was expected, the receiver of this messed up packet should send a “challenge” ACK to the sender. Depending on the type of messed-up-ness, the sender and receiver do one of a number of little dances with each other, in the special way that TCP is so fond of doing. When one party sends a challenge ACK, they increment a counter stored in a global variable which is shared across all TCP connections. This global variable is reset to 0 once per second, and it has a maximum value of 100, i.e. no more than 100 challenge ACKs will be sent per second (for all connections combined). If it wasn’t obvious from the title of the paper, global variables (across programming languages, frameworks, and contexts) are commonly known to be a very bad, no good, horrible idea.
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 …
read more