SoylentNews is people
SoylentNews
Submitted via IRC for Beige
Researchers at the University of California, Riverside (UCR) have identified a weakness in the Transmission Control Protocol (TCP) of all Linux operating systems since late 2012 that enables attackers to hijack users' internet communications completely remotely.
Such a weakness could be used to launch targeted attacks that track users' online activity, forcibly terminate a communication, hijack a conversation between hosts or degrade the privacy guarantee by anonymity networks such as Tor.
Led by Yue Cao, a computer science graduate student in UCR's Bourns College of Engineering, the research will be presented on Wednesday (Aug. 10) at the USENIX Security Symposium in Austin, Texas. The project advisor is Zhiyun Qian, an assistant professor of computer science at UCR whose research focuses on identifying security vulnerabilities to help software companies improve their systems.
While most users don't interact directly with the Linux operating system, the software runs behind-the -scenes on internet servers, android phones and a range of other devices. To transfer information from one source to another, Linux and other operating systems use the Transmission Control Protocol (TCP) to package and send data, and the Internet Protocol (IP) to ensure the information gets to the correct destination.
For example, when two people communicate by email, TCP assembles their message into a series of data packets—identified by unique sequence numbers—that are transmitted, received, and reassembled into the original message. Those TCP sequence numbers are useful to attackers, but with almost 4 billion possible sequences, it's essentially impossible to identify the sequence number associated with any particular communication by chance. The UCR researchers didn't rely on chance, though. Instead, they identified a subtle flaw (in the form of 'side channels') in the Linux software that enables attackers to infer the TCP sequence numbers associated with a particular connection with no more information than the IP address of the communicating parties.
[...] Encrypted connections (e.g., HTTPS) are immune to data injection, but they are still subject to being forcefully terminated by the attacker. The weakness would allow attackers to degrade the privacy of anonymity networks, such as Tor, by forcing the connections to route through certain relays. The attack is fast and reliable, often taking less than a minute and showing a success rate of about 90 percent. The researchers created a short video showing how the attacks works.
Source: https://ucrtoday.ucr.edu/39030
(Score: 3, Informative) by Anonymous Coward on Wednesday August 10 2016, @05:35PM
As a network engineer, this doesn't read overly novel to me. Gain knowledge of the TCP sequence numbers, and you can muck about with TCP streams. We've been doing this for a long time, for example with firewall products that can forcibly close TCP sessions passing through them. Need to terminate a live TCP session? Send appropriate RST packets with correct sequence numbers in both directions. The firewall is in the routing path in the middle of the TCP stream, so it knows the sequence numbers, so it can do this. Some products such as Cisco ASA even randomise sequence numbers as TCP traffic passes through it, which I would presume mitigates this particular attack - whatever algorithm is used to predict the sequence numbers by the attacker no longer works.
Even with gaining knowledge of the TCP sequence numbers, without being in the network path or without being able to manipulate the underlying /routing/ of your target's traffic over the networks it traverses, the number of attacks you can do are limited. It would be hard to actually take over a live TCP stream since traffic isn't routed to you. You could spoof traffic which the both ends might consider valid in terms of the TCP stream so causing disruption, but you couldn't MITM traffic directly just with sequence number knowledge alone. And as mentioned, encrypted traffic, whilst could be disrupted, is still immune to injection if the attacker were able to MITM the actual path traffic took.
Having just read through RFC 5961 (yes I actually read something before responding!), I'm not sure how the suggested workaround of setting “net.ipv4.tcp_challenge_ack_limit = 999999999” mitigates the ability of the attacker guessing the sequence number. To me it reads as "allow the machine to send more Challenge ACKs per second than default". Kernel source docs say the default of this value is 100. A normal end user device isn't going to be creating/destroying 100 TCP sessions per second. A server might be doing so, perhaps. Setting this on most client machines sounds like opening the potential for a mini-non-amplifying-DOS attack in the making to me. What happens when the kernel needs to send more challenges than the configured limit, does it just accept the spoofed RSTs which are above limit instead of challenging them as per RFC 5961, hence the suggestion to increase the value? Maybe there's something about how Linux implements TCP which I'm not familiar with, it would be nice if someone could comment.
If anything though, I can give credit that they found a way to /predict/ TCP sequence numbers from just source and destination IP. That on its own I will admit is a good find. I suspect without looking at the code submitted, the patches simply make Linux's sequence number generation more random and rely less on the source and destination IP. But the attacks on disrupting the TCP streams don't seem that new to me.
(Score: 4, Informative) by NotSanguine on Wednesday August 10 2016, @06:17PM
Having just read through RFC 5961 (yes I actually read something before responding!), I'm not sure how the suggested workaround of setting “net.ipv4.tcp_challenge_ack_limit = 999999999” mitigates the ability of the attacker guessing the sequence number. To me it reads as "allow the machine to send more Challenge ACKs per second than default".
IIUC, the advantage in increasing the value of net.ipv4.tcp_challenge_ack_limit isn't to hinder the guessing of sequence numbers, rather it's to make it more difficult to identify existing TCP connections, termed "connection inference" in the paper [ucr.edu].
Since such an attack (whether the goal is DoS or data corruption) is only viable if the attacker can identify an existing TCP virtual circuit, that's a critical piece of the exploit. Setting the value to be very high increases the cost (and the likelihood of exposing the attack) of such a mechanism.
if you need to send roughly a billion RSTs within a one second window, and do so multiple times to enable identification of an existing connection, effecting such an attack becomes quite problematic.
As is suggested in the paper, a better solution would be to randomly vary the challenge_ack_limit and the time frame under which it is applied.
You're absolutely correct that there's nothing new WRT TCP sequence number guessing. However, to do so without being on the network path by using this mechanism is new, or at least newly publicized.
No, no, you're not thinking; you're just being logical. --Niels Bohr