Linux Kernel Bug Knocks PCs, IoT Gadgets and More Offline

Gadgets

linux pc sack vulnerability

Four vulnerabilities could “SACK” connected devices with denial-of-service exploits.

Multiple TCP-based remote denial-of-service vulnerabilities have been uncovered in the FreeBSD and Linux kernels by Netflix researchers. Exploitation would interrupt TCP connections and therefore streaming content flows to vulnerable Linux-based PCs (putting a crimp in binge-watching, for instance). Attackers could also disable connections to vulnerable Linux-powered internet of things gadgets, taking them offline.

First up, three related flaws denial-of-service (DoS) were found in the Linux kernel’s handling of TCP networking. The first two are related to TCP Selective Acknowledgement (SACK) packets combined with the Maximum Segment Size parameter, and the third solely with the Maximum Segment Size parameter, according to an advisory issued Monday.

The most severe vulnerability (CVE-2019-11477, dubbed SACK Panic) impacts Linux kernels 2.6.29 versions and above. It could allow a remote attacker to trigger a kernel panic in systems running the affected software and, as a result, impact the system’s availability.

“A sequence of SACKs may be crafted such that one can trigger an integer overflow, leading to a kernel panic,” Netflix noted in its advisory, posted Monday.

“Kernel panic is a fatal error from which the OS cannot quickly or easily recover,” according to a Trend Micro write-up on Tuesday. “An OS in panic displays an error message on the computer screen and writes the kernel memory’s contents to the disk for later debugging. All CPU operation will then be halted.”

The PATCH_net_1_4.patch mitigates the issue; additionally, versions of the Linux kernel up to, and including, 4.14 require a second patch, PATCH_net_1a.patch.

Another issue, CVE-2019-11478, causes SACK slowness in Linux versions below 4.15, or excess resource usage (all Linux versions are impacted). PATCH_net_2_4.patch addresses the issue.

“It is possible to send a crafted sequence of SACKs which will fragment the TCP retransmission queue,” Netflix explained. “On Linux kernels prior to 4.15, an attacker may be able to further exploit the fragmented queue to cause an expensive linked-list walk for subsequent SACKs received for that same TCP connection.”

And finally, CVE-2019-11479  causes excess resource consumption due to low MSS values in all Linux versions.

“An attacker can force the Linux kernel to segment its responses into multiple TCP segments, each of which contains only 8 bytes of data,” Netflix explained. “This drastically increases the bandwidth required to deliver the same amount of data. Further, it consumes additional resources (CPU and NIC processing power). This attack requires continued effort from the attacker and the impacts will end shortly after the attacker stops sending traffic.”

Two patches, PATCH_net_3_4.patch and PATCH_net_4_4.patch, which add a feature that lets an administrator enforce a minimum MSS appropriate for their applications, address the bug.

As workarounds for all three issues, users can also disable SACK processing altogether, or block connections with a low MSS using one of the supplied filters.

“Note that these filters may break legitimate connections which rely on a low MSS,” according to the advisory. “Also, note that this mitigation is only effective if TCP probing is disabled (that is, the net.ipv4.tcp_mtu_probing sysctl is set to 0, which appears to be the default value for that sysctl).”

Meanwhile a fourth issue, CVE-2019-5599, causes SACK slowness in FreeBSD 12 if using the RACK TCP Stack.

“It is possible to send a crafted sequence of SACKs which will fragment the RACK send map,” Netflix researchers noted. “An attacker may be able to further exploit the fragmented send map to cause an expensive linked-list walk for subsequent SACKs received for that same TCP connection.”

As a workaround, users can apply the split_limit.patch, which allows them to set a reasonable value to limit the size of the SACK table. They could also temporarily disable the RACK TCP stack.

“Good system and application coding and configuration practices (limiting write buffers to the necessary level, monitoring connection memory consumption via SO_MEMINFO, and aggressively closing misbehaving connections) can help to limit the impact of attacks against these kinds of vulnerabilities,” Netflix added.

Red Hat, Amazon Web Services, SUSE and Grsecurity have so far posted advisories on the issues for their implementations of the kernels.

[“source=threatpost”]