Researchers have discovered a flaw in the Linux kernel’s TCP/IP networking subsystem implementation of the RFC 5961 challenge ACK rate limiting, that could allow an off-path attacker to inject payload into unsecured TCP connections.
The 3.6 Linux kernel introduced a global challenge ACK counter limit in order to improve tcp's robustness to blind in-window attacks as specified in RFC 5961. However, an attacker can use this global challenge ACK counter to infer the sequence and ack number of an off-path tcp connection. In a typical client/server tcp connection, an attacker can establish connections with the server. Thus, the attacker can establish a number of connections with the server, and send sufficient out-of-window traffic, in order to use up the the entire global challenge ack limit. In this case, the attacker can expect to receive the number of challenge acks that is equal to the challenge ACK counter limit in response. The attacker can then infer information about the sequence number and ack number of the connection by realizing if it has received fewer challenge ACKs in response than the global challenge ACK counter limit.
An example of the attack which makes use of this can be seen in the below video:
The most fastest way to resolve the issue to ensure you make a change to sysctl.conf by ensuring the below line is in your config:
This should ensure that the vulnerability is being resolved for now.
The 3.6 Linux kernel introduced a global challenge ACK counter limit in order to improve tcp's robustness to blind in-window attacks as specified in RFC 5961. However, an attacker can use this global challenge ACK counter to infer the sequence and ack number of an off-path tcp connection. In a typical client/server tcp connection, an attacker can establish connections with the server. Thus, the attacker can establish a number of connections with the server, and send sufficient out-of-window traffic, in order to use up the the entire global challenge ack limit. In this case, the attacker can expect to receive the number of challenge acks that is equal to the challenge ACK counter limit in response. The attacker can then infer information about the sequence number and ack number of the connection by realizing if it has received fewer challenge ACKs in response than the global challenge ACK counter limit.
An example of the attack which makes use of this can be seen in the below video:
The most fastest way to resolve the issue to ensure you make a change to sysctl.conf by ensuring the below line is in your config:
net.ipv4.tcp_challenge_ack_limit = 999999999
This should ensure that the vulnerability is being resolved for now.