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: 1, Informative) by Anonymous Coward on Wednesday August 10 2016, @02:20PM
"There's this technique here to infer TCP sequence numbers, so if I know A is talking to B, I can use that technique to start talking to B after hijacking the right sequence number and use that in my first packet."
Also, if anything is encrypted properly (including proper key management and no key compromising), then the decryption will fail because the data will not be decryptable/unsigned. So I get that Tor is vulnerable to the extent that connections can be terminated (because of failed decryption) and thus anonymity is compromised but I don't see which other effect this will have on the user of Tor. Anyone care to illuminate me?
(Score: 1, Interesting) by Anonymous Coward on Wednesday August 10 2016, @02:52PM
If I had to take a wild stab, I'd guess that the MotU/hackers/Bad Guys could ensure that you connect to a compromised entrance node by means of exhaustion. Simply repeatedly terminate connections that aren't to compromised entrance nodes until Tor connects to a compromised one. If we assume the MotU have effectively compromised your ISP, this wouldn't be necessary to cause that to happen. It could still be useful to other parties that may want to deanonymize traffic such as Google, M$, Amazon, etc.
I'm not intimately familiar with how Tor works, but I assume that after connecting to a compromised node, the presence of the other two nodes that are supposed to be involved in obfuscating a communication's source could be forged or if not an attacker could use wash-rinse-repeat to ensure the communication also finds its way to a compromised exit node. With traffic going through both a compromised entrance node and compromised exit node, it's possible to deanonymize it.
(Score: 0) by Anonymous Coward on Wednesday August 10 2016, @02:57PM
Should have added that this seems to completely defeat the purpose of Tor. But I'm more a fan of Freenet.
(Score: 0) by Anonymous Coward on Wednesday August 10 2016, @10:27PM
All of my entrance nodes, according to TBB are routing through 5 eyes, or affiliated countries entry nodes, which a disturbing propensity for single nation hops all the way through (IE UKUKUK, or FRFRFR, or USUSUS.) I have all 5 eye nations and a few others blacklisted for both regular and exit nodes, so they shouldn't *EVER* be showing up, according to Tor docs, unless connectivity is so bad that only 'suspect' entry nodes are available.
I hope the scrutiny wastes a lot of their surveillance dollars for little return, but given how commiditized their spying is now, I imagine it is cheaper to just collect/compromise everything, than to make exceptions other than for people it is politcally or financially beneficial to not observe.
(Score: 0) by Anonymous Coward on Wednesday August 10 2016, @03:00PM
thus anonymity is compromised but I don't see which other effect this will have on the user of Tor. Anyone care to illuminate me?
Isn't anonymity kind of the whole point of using Tor? If that is compromised, any other potential effects are not really all that important.
(Score: 2) by frojack on Wednesday August 10 2016, @06:11PM
It seems to me the chance of this going unnoticed by the user is pretty slim. Even in an unencrypted data stream you would have to know exactly what was expected next in order to sneak this by the software or the user .
No, you are mistaken. I've always had this sig.
(Score: 2) by DannyB on Wednesday August 10 2016, @08:11PM
Is anonymity is compromised really?
I can see that traffic flow between two TOR nodes is interrupted. Thus a denial of service. But nobody's identity is exposed.
The Centauri traded Earth jump gate technology in exchange for our superior hair mousse formulas.
(Score: 0) by Anonymous Coward on Wednesday August 10 2016, @02:46PM
Doctor: Well, don't do that!
(Score: 4, Informative) by NotSanguine on Wednesday August 10 2016, @02:47PM
From TFA:
Here's the paper presented [ucr.edu].
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 3, Informative) by Anonymous Coward on Wednesday August 10 2016, @03:26PM
Use “sysctl -p” to update the configuration.
That should read:
Open /etc/sysctl.conf, append a command “net.ipv4.tcp_challenge_ack_limit = 999999999”.
Use “sysctl -p” to update the configuration.
(Score: 2) by NotSanguine on Wednesday August 10 2016, @03:55PM
Good catch. Thanks!
That's what I get for just doing the copypasta and not proofreading other people's writing.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 3, Insightful) by canopic jug on Wednesday August 10 2016, @04:04PM
Just skimming the paper, it looks like the problem is not Linux per se but the RFC itself, which is RFC 5961. The paper says this:
The feature is outlined in RFC 5961, which is implemented faithfully in Linux kernel version 3.6 from late 2012
So Linux is implementing the RFC as intended and there is where the bug is. The solution will be bigger than "just" patching the kernel.
Money is not free speech. Elections should not be auctions.
(Score: 0) by Anonymous Coward on Wednesday August 10 2016, @04:32PM
"So Linux is implementing the RFC as intended and there is where the bug is. The solution will be bigger than "just" patching the kernel."
So... patching the RFC?
(Can RFCs even be patched, or do they need to be revoked/reissued/rerequested?)
(Score: 0) by Anonymous Coward on Wednesday August 10 2016, @10:31PM
I think they update a header or footnote on them to state that, but otherwise keep them intact.
And yeah RFCs can amend, revoke, or replace other RFCs, but the original RFC will not be changed.
(Score: 3, Interesting) by Nerdfest on Wednesday August 10 2016, @04:53PM
Wonder why just Linux is mentioned. Does Windows implement the spec improperly? What about OSX?
(Score: 4, Informative) by NotSanguine on Wednesday August 10 2016, @05:07PM
Wonder why just Linux is mentioned. Does Windows implement the spec improperly? What about OSX?
From the paper [ucr.edu]:
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 2) by Nerdfest on Wednesday August 10 2016, @06:18PM
Strange that neither OS has implemented a networking specification that's many years old ... but then again, it's Apple and Microsoft.
(Score: 5, Informative) by NotSanguine on Wednesday August 10 2016, @05:01PM
Just skimming the paper, it looks like the problem is not Linux per se but the RFC itself, which is RFC 5961. The paper says this:
The feature is outlined in RFC 5961, which is implemented faithfully in Linux kernel version 3.6 from late 2012
So Linux is implementing the RFC as intended and there is where the bug is. The solution will be bigger than "just" patching the kernel.
I disagree. The issue is the implementation of this feature in the Linux kernel, not the specification in the RFC. The challenge_ack functionality is exploitable due to the linux implementation of ack throttling. To wit, the default (100) number of challenge acks is small and is a static value.
There are ways to mitigate the vulnerability without modifying the challenge_ack functionality defined in RFC 5961. The paper's authors suggest several methods for this [ucr.edu]. One bypasses the mechanism completely (potentially causing other issues addressed in RFC 5961) and one that tweaks the implementation of ack throttling:
What's more, the RFC's authors note the issues mentioned in TFA and paper and make the following statements about potential issues:
From RFC 5961 [ietf.org]:
(Score: 2) by NotSanguine on Wednesday August 10 2016, @04:03PM
As an aside, the default value for net.ipv4.tcp_challenge_ack_limit appears to be '100'.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 3, Funny) by Anonymous Coward on Wednesday August 10 2016, @03:04PM
Huh. The fortune reads:
"Linux is obsolete -- Andrew Tanenbaum"
... +5, Touche, SoylentNews resident self-aware AI. +5, Touche.
(Score: 0) by Anonymous Coward on Wednesday August 10 2016, @03:27PM
pshaw! i always connect thru windows localhost 127.0.0.1 first ... it's rainbow-farts out of unicorns all the way down.
(Score: 4, Insightful) by Anonymous Coward on Wednesday August 10 2016, @03:33PM
(Score: 4, Touché) by Thexalon on Wednesday August 10 2016, @03:44PM
In NSA HQ: "Gosh darn it, one of those stupid researchers caught us again! Time to work on Heartbleed 2.0 instead!"
"Think of how stupid the average person is. Then realize half of 'em are stupider than that." - George Carlin
(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