Serious TCP bug in Linux Kernel allows traffic hijacking
A recent research has exposed a three-years-old bug in the Linux Kernel. The bug, starting from version 3.6 of the Linux Kernel, allows TCP traffic hijacking without the need of being in the middle of the communication. Computer scientists from the University of Carolina and U.S. Army Research laboratory, have discovered a bug in the implementation of RFC5961 in the Linux Kernel. Such bug has existed for over three years starting from version 3.6 released in 2012. The most terrifying part however, is that the attacker doesn’t have to be in the traffic stream. That means anyone in the world could interfere, jam, hijack or inject TCP communications between two machines without being “in-the-middle“. Such “off-path” attack, opposed to the man-in-the-middle attacks, wouldn’t require the perpetrator to be in the middle: as a matter of fact the only things needed to carry it would be:
- The IP addresses pair from client and server that are communicating.
- Enough time to perform the procedure.
Possible results? If the communication is not encrypted, malicious code injection. Possible targets? Anyone (clients and servers) where one of the two is using an unpatched version of the Linux Kernel with version > 3.6, though the patch will be backported to other versions, so the number of affected machines remains unknown. Researchers have shown the bug in this video:
The video shows how, given enough time, a connection can be hijacked and the entire page content is replaced with a “malicious” image. For further reference look up: CVE-2016-5389 .
How does this work?
The trick is possible because of the RFC5961 which is faithfully implemented by the Linux Kernel. The fault however isn’t to be attributed to the RFC, but to the implementation; even though the. TCP uses a particular sequence of SYN, ACK and SYN-ACK to perform the so-called three-way-handshake. Such process is meant to be successful and to establish a connection, but when it doesn’t work (an intruder sends a packet to ta a special packet called Challenge ACK is sent, and essentially challenges the other party, asking for a secret number that no one should be able to guess (as described in RFC5961). How many times can this happen? It is up to the operating system to decide how many times, and if this count is low, an intruder might saturate the whole attempts and get max_attempts-1 (because the real party will respond) in case the two parties are connected, and max_attempts in case the two parties are not connected.
What to do if you own a server?
You can easily check if you are affected by issuing:
# sysctl net.ipv4.tcp_challenge_ack_limit net.ipv4.tcp_challenge_ack_limit = 100
If the limit is low (100), then you are affected. To resolve you should just increase that number by adding the parameter in the file /etc/systcl.conf :
net.ipv4.tcp_challenge_ack_limit=999999
Windows and Mac?
Since the bug is related RFC5961, up to now, only Linux has implemented it. So Windows and Mac are not thought to be affected.
- 2020 A year in review for Marksei.com - 30 December 2020
- Red Hat pulls the kill switch on CentOS - 16 December 2020
- OpenZFS 2.0 released: unified ZFS for Linux and BSD - 9 December 2020
Recent Comments