This is a very interesting vulnerability in the TCP stack of Linux kernels pre < 4.7. The bad news: there are a lot of systems online running those kernel versions. The bug/vulnerability is as follows.
Red Hat Product Security has been made aware of an important issue in
the Linux kernel’s implementation of challenge ACKS as specified in
RFC 5961. An attacker which knows a connections client IP, server IP
and server port can abuse the challenge ACK mechanism
to determine the accuracy of a normally ‘blind’ attack on the client or server.
Successful exploitation of this flaw could allow a remote attacker to
inject or control a TCP stream contents in a connection between a
Linux device and its connected client/server.
- This does NOT mean that cryptographic information is exposed.
- This is not a Man in the Middle (MITM) attack.
[oss-security] CVE-2016-5389: linux kernel – challange ack information leak
In short: a successful attack could hijack a TCP session and facilitate a man-in-the-middle attack and allow the attacker to inject data. Ie: altering the content on websites, modifying responses from webservers, …
This Stack Overflow post explains it very well.
The hard part of taking over a TCP connection is to guess the source port of the client and the current sequence number.
The global rate limit for sending Challenge ACK’s (100/s in Linux) introduced together with Challenge ACK (RFC5961) makes it possible in the first step to guess a source port used by the clients connection and in the next step to guess the sequence number. The main idea is to open a connection to the server and send with the source of the attacker as much RST packets with the wrong sequence mixed with a few spoofed packets.
By counting how much Challenge ACK get returned to the attacker and by knowing the rate limit one can infer how much of the spoofed packets resulted in a Challenge ACK to the spoofed client and thus how many of the guesses where correct. This way can can quickly narrow down which values of port and sequence are correct. This attack can be done within a few seconds.
And of course the attacker need to be able to spoof the IP address of the client which is not true in all environments. It might be possible in local networks (depending on the security measures) but ISP will often block IP spoofing when done from the usual DSL/cable/mobile accounts.
For RHEL (and CentOS derivatives), the following OS’s are affected.
While it’s no permanent fix, the following config will make it a lot harder to abuse this vulnerability.
$ sysctl -w net.ipv4.tcp_challenge_ack_limit=999999999
And make it permanent so it persists on reboot:
$ echo "net.ipv4.tcp_challenge_ack_limit=999999999" >> /etc/sysctl.d/net.ipv4.tcp_challenge_ack_limit.conf
While the attack isn’t actually prevented, it is damn hard to reach the ACK limits.
Further reading:
- CVE-2016-5696
- Vulnerability in the Linux kernel’s tcp stack implementation
- CVE-2016-5696 and its effects on Tor
- [oss-security] CVE-2016-5389: linux kernel – challange ack information leak
- [Mitnick Attack Reappears at GeekPwn Macau Contest
]6