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, @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]: