Netflix researcher spots TCP SACK flaws in Linux and FreeBSD

Three vulnerabilities have been discovered in the FreeBSD and Linux kernels through which attackers could induce a denial-of-service by clogging networking I/O on affected systems.

Uncovered by Netflix Information Security’s Jonathan Looney (yes, Netflix has a cybersecurity division), we’ll start with the most critical, dubbed ‘SACK Panic’, also identified as CVE-2019-11477.

Affecting all Linux distro kernels from 2.6.29 or later (March 2009 onwards), Looney describes it as:

A sequence of SACKs [that] may be crafted such that one can trigger an integer overflow, leading to a kernel panic.

SACK stands for Selective Acknowledgment, a feature introduced nearly two decades ago to help TCP performance when retransmitting packets.

‘Kernel panic’, meanwhile, is the Linux equivalent of what anyone who used Windows versions prior to XP will remember as a General Protection Fault (GPF), or Blue Screen of Death – in other words, a system crash.

The second, identified as CVE-2019-11478, is a related problem whereby an attacker might craft a sequence of SACKs that would cause excess resource usage in the TCP retransmission queue on all Linux versions.

On kernels earlier than 4.15, the same flaw could be exploited to cause ‘SACK Slowness’ delays, in effect amplifying the denial of service.

A variation of this, CVE-2019-5599, is identical to SACK Slowness but affects only FreeBSD 12 installations using the RACK TCP Stack.

The third and final bug, CVE-2019-11479, is about inducing increased bandwidth consumption through which…

An attacker can force the Linux kernel to segment its responses into multiple TCP segments, each of which contains only 8 bytes of data. This drastically increases the bandwidth required to deliver the same amount of data.

Patch v mitigate

The SACK Panic flaw can be fixed by applying PATCH_net_1_4.patch or, alternatively, mitigated by disabling SACK processing (/proc/sys/net/ipv4/tcp_sack set to 0) whilst noting the possibility that this might break connections requiring a low Maximum Segment Size (MSS).

Additionally, kernel versions up to and including 4.14 require a second patch: PATCH_net_1a.patch.

For excess resource usage / SACK Slowness (CVE-2019-11478) the required fix is PATCH_net_2_4.patch, or by applying workaround mitigations such as disabling SACK processing.

For SACK Slowness (CVE-2019-5599) affecting FreeBSD, the mitigation is either to apply the split_limit.patch or temporarily disable the RACK TCP stack.

Finally, for excess bandwidth consumption due to low MSS (CVE-2019-11479), the patches are PATCH_net_3_4.patch and PATCH_net_4_4.patch, which add a sysctl enforcing a minimum MSS.

Instructions for affected distributions can be found on the support sites for Amazon AWS, Red Hat, Debian, SUSE, and Ubuntu.

Apple’s macOS (which traces its lineage back to the Darwin FreeBSD port from NeXTSTEP days) isn’t mentioned anywhere in connection with the alert despite supporting SACKs. If we receive an update on that either way, we’ll publish further details.