SACK race: Linux servers in urgent need of patching to defend against new DoS threat

Don’t Panic – patch

Linux servers and devices need patching to defend against newly discovered security vulnerabilities that create a ready mechanism for hackers to crash systems simply by sending malformed requests.

The problem stems from three related flaws in the Linux kernel’s handling of TCP networking.

The first two relate to the Selective Acknowledgement (SACK) packets combined with Maximum Segment Size (MSS), while the third is solely concerned with the Maximum Segment Size (MSS).

The most serious of the trio, dubbed “SACK Panic”, allows a remotely-triggered kernel panic on recent Linux kernels.

This CVE-2019-114477 flaw is characterized as “important” by Red Hat. Linux OS vendors designate the other two flaws – CVE-2019-11478 and CVE-2019-11479 – as a lower “moderate” severity risk.

None of the trio present either a privilege escalation or remote code execution (RCE) risk but are nonetheless really bad news because of the widespread denial-of-service risk they might present.

A series of malicious packets sent to vulnerable system is all it takes to crash or slow them down by triggering a so-called kernel panic.

Fortunately patches from Linux OS vendors, such as Red Hat, are already available.

A related issue (CVE-2019-5599) that was dubbed SACK Slowness poses a moderate risk to FreeBSD systems.

The set of related denial-of-service flaws were discovered by security staffers at streaming media giant Netflix, which has published an advisory. Netflix classifies the flaws as “critical”.

The likes of Cloudflare and AWS have already taken action to defend against the threat.

Some protection, short of patching, is possible but this has its drawbacks.

“While mitigations shown in this article are available, they might affect traffic from legitimate sources that require the lower MSS values to transmit correctly and system performance,” Red Hat explains in its security bulletin.

TCP Selective Acknowledgment (SACK) allows a data receiver to confirm with a sender which particular segments of streamed transmission have arrived successfully.

Missing segments can be retransmitted without going through the overhead of starting from scratch.

Disabling TCP SACK is possible but incurs a transmission overhead for streamed content.