SACK Panic & Slowness: KernelCare Live Patches Are Here

June 24, 2019 - TuxCare PR Team

Kernel Care-03 (2)

Recently, the wrong kind of Netflix Original was revealed to the public. The streaming giant announced that they had discovered four new denial-of-service (DoS) and resource consumption vulnerabilities affecting Linux and FreeBSD servers. Netflix offered full details in an advisory posted on GitHub. The vulnerabilities threaten any enterprise running large fleets of production Linux computers.

Best Case Scenario: Slowdown

All of the Linux-threatening vulnerabilities exploit the kernel’s TCP Selective Acknowledgement feature (hence “TCP SACK”). Two of the vulnerabilities – CVE–2019–11478, and CVE–2019–11479 – cause the TCP retransmission queue to become so fragmented that the kernel spends excessive resources managing that TCP connection’s SACK elements. While this isn’t disastrous, it could cause significant slowdown in the CPU. CVE–2019–11478 affects all kernels before 4.15; CVE–2019–11479 affects all Linux versions since 2.6.29.

Worst Case Scenario: Disaster

The third vulnerability – CVE–2019–11477 – has rightfully been dubbed “SACK Panic.” Affecting all kernels 2.6.29 and newer, SACK Panic is an integer overflow vulnerability that exploits the kernel’s TCP Selective ACKnowledgement feature by adjusting the values of the MSS (Maximum Segment Size). A particular sequence of packets can induce a kernel panic.

Like the slowness vulnerabilities, SACK Panic is particularly worrying because it can be remotely-triggered. Malicious actors can trigger a full-blown panic, which can utterly bork an OS, forcing the restart of a targeted host and causing a temporary shutdown in services. This means crashed servers, disrupted communications, and a risk of serious data loss. This is very bad news for services that use Linux-based systems to deliver online services.

As if that wasn’t bad enough: SACK Panic affects all kernels 2.6.29 and newer.

Get a FREE 7-Day Supported Trial of KernelCare

Protect Your Kernels and Your IoT Devices – Without Rebooting

KernelCare’s SACK Panic & Slowness live patches, including the all important PATCH_net_1_4.patch PATCH_net_1a.patch, are here for all supported distributions except UEK (which is in progress right now). And with a vulnerability as serious as SACK Panic, you want to get patched as soon as possible. Yes, there are some configuration file workarounds, but these are far from failsafe.

However: if you’re rebooting to patch, this presents a serious headache. Rebooting servers is a major inconvenience; you can’t do it without planning in advance, and it’s very tempting to delay it for as long as possible. (This is especially true of IoT devices, which can be difficult and time-consuming to patch.) This means every time a vulnerability comes around, you’re faced with a lose-lose: the hassle of rebooting your server fleet, or the risk of delaying that rebooting until midnight on Saturday, when the downtime will be the least problematic.

Furthermore, delaying your reboots doesn’t only make you unsafe: it makes you non-compliant. Most companies’ errors and omissions (E&O) insurance policies, as well as the clauses in their SLA contracts, require adherence to best practices for patching. Usually, this equates to a gap between patch issue and patch application of no more than 30 days. But a lot of companies still tend to plan their reboot cycles in terms of months or quarters – putting them in perpetual breach of their insurance policies. The earlier you patch, the earlier you’re protected – and the more compliant you become.

Over this weekend, patches rolled out to KernelCare users and were automatically applied, without any rebooting required. Next time a dangerous CVE comes along, there’s no need to be faced with the annoyance of rebooting your servers. There’s no need to be noncompliant with industry security standards. Live-patch with KernelCare, and you’ll be fully protected without having to lift a finger.

Get a FREE 7-Day Supported Trial of KernelCare

Read more: