TCP networking code scores own goal
Analysis A flaw in the Linux kernel lets hackers inject malware into downloads and webpages, smash Tor connections, launch denial-of-service attacks, and more.
This is a troubling security headache because Linux is used widely across the internet, from web servers to Android smartphones, tablets and smart TVs.
The TCP/IP networking blunder, present in the open-source kernel since version 3.6, can be exploited by miscreants to confirm whether any two systems are talking to each other over a network.
Furthermore, it can be abused to break their connections or insert malicious code and data into their communications if the exchange is not properly encrypted.
In other words, you can hijack HTTP with this.
Crucially, you do not need to be a man-in-the-middle attacker to pull this off; you do not need to be eavesdropping on a network. You can be off to the side, firing the right packets at both ends to compromise their exchanges. You have to know the IP addresses of both sides of the connection, and you have to be able to send spoofed packets to them.
And that’s about it.
The security weakness was discovered by eggheads at the University of California, Riverside.
It’s buried within the Linux implementation of RFC 5961, which was published in 2010 and has been supported in the kernel since 2012.
This standard was supposed to make internet communications more secure – but quite the opposite has happened.
“The unique aspect of the attack we demonstrated is the very low requirement to be able to carry it out,” said project leader Zhiyun Qian.
“Essentially, it can be done easily by anyone in the world where an attack machine is in a network that allows IP spoofing.
The only piece of information that is needed is the pair of IP addresses (for victim client and server), which is fairly easy to obtain.”
RFC 5961 was designed to block spoofed packet injection attacks by introducing challenge ACK packets.
To successfully insert data into a connection you have to know the two IP addresses and the source and destination ports – known as a four-tuple – plus the next valid serial numbers stamped on the exchanged packets.
Challenge ACKs are used to ensure that no one is trying to forcibly introduce themselves into a valid connection.
Crucially, Linux rate limits the output of these challenge ACKs.
On a simple level, here’s how a hijacking could work: after inferring the source and destination ports in a connection between a server and a client, an attacker can hit the server with dodgy packets to confuse it.
That makes the server send challenge ACKs to the client until the server hits its limit and temporarily stops sending them.
Then the attacker can turn to the client and send spoofed IP packets to break or inject itself into the connection, which will be accepted by the client because the server has been silenced.
As a workaround while patches to fix the problem are prepared and distributed, you can raise the rate limit on your Linux machine or gadget so that it cannot be reached, by appending the following to /etc/sysctl.conf:
net.ipv4.tcp_challenge_ack_limit = 999999999
And then use sysctl -p to activate the new rule. You need to be root to do this.
According to the researchers:
The root cause of the vulnerability is the introduction of the challenge ACK responses and the global rate limit imposed on certain TCP control packets.
The feature is outlined in RFC 5961, which is implemented faithfully in Linux kernel version 3.6 from late 2012.
At a very high level, the vulnerability allows an attacker to create contention on a shared resource, ie, the global rate limit counter on the target system by sending spoofed packets.
The attacker can then subsequently observe the effect on the counter changes, measurable through probing packets.
Through extensive experimentation, we demonstrate that the attack is extremely effective and reliable.
Given any two arbitrary hosts, it takes only 10 seconds to successfully infer whether they are communicating.
If there is a connection, subsequently, it takes also only tens of seconds to infer the TCP sequence numbers used on the connection.
To demonstrate the impact, we perform case studies on a wide range of applications.
The basic idea is to repeat the following steps: 1) send spoofed packets to the connection under test (with a specific four-tuple), 2) create contention on the global challenge ACK rate limit, ie, by creating a regular connection from the attacker to the server and intentionally triggering the maximum allowed challenge ACKs per second, and 3) count the actual number of challenge ACKs received on that connection.
If this number is less than the system limit, some challenge ACKs must have been sent over the connection under test, as responses to the spoofed packets.
For encrypted HTTPS or SSH transmissions the worst that can be done is to break the connection.
But with unencrypted traffic, the attacker could insert new content into communications and even add malware, with no additional input from the two legitimate owners of the connection.
Sites like this are perfect because they have long duration connections between content on the site and servers providing it.
They also demonstrated an attack against a Tor relay server – set up specially so as not to interfere with legitimate traffic – and examined 40 Tor relays around the world.
Sixteen relays rejected the attack, probably due to firewalls blocking the packets, but the team broke 88.8 per cent of the rest in an average time of 51.1 seconds.
“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 team said in a white paper [PDF].
“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.”
The team notes that while later versions of Linux are vulnerable to this attack, Windows, OS X and FreeBSD aren’t vulnerable because they haven’t fully implemented RFC 5961 as yet.
The flaw finders have developed and distributed a patch for this serious error, but that’s still going to leave a lot of servers unpatched – and the exploit only requires one end of the communicators to be unpatched for the hack to work. ®
Sponsored: 2016 Cyberthreat defense report