GetPageSpeed is aware of a vulnerability, announced at the USENIX Security conference on Aug 10, 2016, which describes a vulnerability in the Linux kernel’s tcp stack implementation (kernel versions 3.6 to 4.6). At a high-level, a patient adversary can leverage rate-limited challenge ACK’s on a non-secure tcp connection to conduct a hijacking attack.
The Issue
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.
What GetPageSpeed is doing to protect itself?
Ahead of this announcement, GetPageSpeed began the process of removing rate-limiting on challenge ACK’s across all of its potentially affected systems. Customer-facing content delivery, and GetPageSpeed’s mission-critical systems were successfully protected ahead of this announcement.
How to protect your systems
Admins who wish to take a similar (recommended) mitigation path can use sysctl to set the challenge ack limit to an arbitrarily large value.
Example (refer to your system(s)’ *nix documentation for exact steps):
sysctl net.ipv4.tcp_challenge_ack_limit=1073741823;
grep -q tcp_challenge_ack_limit /etc/sysctl.conf || echo "net.ipv4.tcp_challenge_ack_limit=1073741823" >> /etc/sysctl.confThe sysctl workaround sets the global challenge ACK counter sufficiently large such that the attacker could not reasonably come up against it and thus cannot infer any additional data about the client-server connection.
Permanent fix
For a permanent fix, the 4.7 upstream Linux kernel hardens against this exploit by both randomizing the maximum number challenge acks sent per second, as well as enforcing the per-socket challenge ACK limits in all cases.
For more information
We will provide a link to the announcement/presentation when it becomes available. In the meantime, please check out the below for additional information.
For information about the associated CVE, please see: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5696
For details regarding the implementation of the Linux kernel patch, please see: https://www.mail-archive.com/netdev@vger.kernel.org/msg118677.html