Linux Kernel Vulnerabilities to Know (and Mitigate Without Reboot)

With the Linux open-source community, you have the power of developers adding to its codebase improving features and performance. The downside to this approach is that hackers also have access to source code and any vulnerabilities that they find can be used against Linux-based devices including critical servers. Known vulnerabilities are reported to a centralized NIST vulnerability database where vendors, developers, and users can be aware of exploits that affect specific software versions. A Common Vulnerabilities and Exposures (CVE) report is your cue to patch software including the Linux kernel when an issue is found. Note: Not every Linux patch gets a CVE, but you can stay up-to-date with latest updates on kernel.org.

Contents:

1. Non-Critical Patches are Important Too
2. Linux CVEs You Should Know
3. Heartbleed CVE-2014-0160
4. Spectre and Meltdown CVE-2017-5753, CVE-2017-5715, CVE-2017-5754
5. Zombieload (Microarchitectural Data Sampling) CVE-2018-12207
6. SACK Panic and Slowness CVE-2019-11477, CVE-2019-11478
7. Mutagen Astronomy CVE-2018-14634
8. Conclusion

Non-Critical Patches are Important Too

Traditionally, Linux administrators have been forced to choose between performance and security. Because patching required reboots and downtime, administrators often delayed critical updates for a scheduled time or delayed the procedure for months. The thought is that non-critical patches aren’t as important as critical ones, and they can wait until a more opportune time.

There are a few mistakes in this way of thinking. The first is that non-critical patches can turn into critical ones with the right vulnerability. If several non-critical bugs are left to accumulate, it could be an opportunity for an attacker. For instance, a simple bug such as a buffer overflow can lead to privilege escalation attack opportunities. From there, an attacker can vertically or horizontally expand their presence and use their own malware and tools to persist on the network. Advanced persistent threats (APT) are difficult to eradicate on the environment and lead to critical data breaches.

Patches aren’t always for security reasons. In some cases, patches resolve crashes and performance on the system. Even though you haven’t experienced a crash, by delaying patch deployments you risk the possibility of a crash in the future as long as the kernel remains unpatched. With extreme delays, you have increased risk of several functionality crashes that could lead to critical downtime.

The most infamous of non-critical patches that led to a severe data breach was the Equifax debacle. The preventable breach stemmed from an Apache Struts bug left unpatched for months after an update was released. What was supposed to be a non-critical patch turned into a breach of sensitive data for millions of consumers and is considered one of the top data breaches to date.

Linux CVEs You Should Know

Every month new CVEs are added to the publicly available NIST database. A primary issue behind many of the biggest breaches is unpatched software. As of December 2019, Shodan estimates that there are still 77,000 devices worldwide vulnerable to Heartbleed including 18,000 publicly available Apache httpd servers.  We’ve collected a few of the most important CVEs that you should be aware of so that you can secure servers and devices.

Heartbleed CVE-2014-0160

CVSS 3.x Score: 7.5 (High)

Discovered by Codenomicon in 2014 doing a routine test of its software, Heartbleed quickly became one of the biggest bugs affecting any server that used OpenSSL for its SSL management. Heartbleed reminded us that even one line of code can cause severe bugs. The Heartbleed vulnerability was caused by just one coding error:

memcpy(bp, pl, payload);

The bp variable is a pointer where data is copied to. The pl variable is a pointer to the source data, and the payload variable is the number of bytes to copy. Developers did not check the length of the payload variable, so an attacker could send a payload with (for instance) 8 bytes of data for the pl variable, but assign 64 bytes to the payload variable. The result is that OpenSSL would send back 64 bytes of data when only 8 bytes was copied. The remaining bytes in memory could be private keys, passwords, user data, or anything else stored in the remaining length of bytes in memory. It’s important to note that Heartbleed was not a buffer overflow, but an over-read issue.

To mitigate it before patching, OpenSSL can be recompiled with the -DOPENSSL_NO_HEARTBEATS parameter. This will have unknown consequences with applications that require an SSL heartbeat. This means that applications functioning based on a heartbeat could crash, throw errors, or simply not work. For this reason, it’s critical that patching happens sooner rather than later.  KernelCare+ allows administrators to patch OpenSSL with no reboot required, so administrators can patch for Heartbleed while avoiding downtime or risky mitigation techniques.

Spectre and Meltdown CVE-2017-5753, CVE-2017-5715, CVE-2017-5754

CVSS 3.x Score: 5.6 (Medium)

What makes Spectre and Meltdown unique from most other CVEs is that it’s a hardware issue rather than software-related. It also affected just about every device globally and forced Intel to change the way they build processors. Both vulnerabilities allow attackers to read memory running on the local device due to various failed privilege checks on the hardware. Meltdown exploits bypass privilege checks and Spectre tricks applications into accessing privileged memory. In both cases, an attacker gains access to operating system instructions from mapped physical memory with the kernel, which could include passwords, keys, and other sensitive data.

After discovery, Intel announced that it would change the way it manufactures its processors, so new processors are not vulnerable. Patches were released but users saw a significant performance hit especially on older machines. Two patches were released to mitigate the issue: Kaiser for Meltdown and the Retpoline patch for Spectre. The biggest issue with mitigation is that performance takes a major hit and a reboot is required, but KernelCare applies patches for these two vulnerabilities with no reboot required. 

Zombieload (Microarchitectural Data Sampling) CVE-2018-12207

CVSS 3.x Score: 6.5 (Medium)

After Spectre and Meltdown, a new hardware bug was found coined “Zombieload.” Zombieload is a group of exploits that take advantage of a microprocessor’s speculative instruction functionality. To speed up performance, the processor attempts to cache future instructions that are likely to run next. Zombieload and other Microarchitectural Data Sampling (MDS) attacks take advantage of failed protection boundaries surrounding this memory space and trick applications into divulging critical data. 

You can mitigate the issue by performing all three of the following steps:

• Updating microcode on the processor
• Disabling hyperthreading in the BIOS (manual instructions depend on your BIOS manufacturer)
• Patching the Linux kernel

For virtual machines, you just need to patch the Linux kernel but you still must perform all three steps on the physical host machine. All three require a reboot, but we’ve provided instructions to perform the first two steps without a reboot. The third step to patch the Linux kernel without a reboot can be done with KernelCare.

SACK Panic and Slowness CVE-2019-11477, CVE-2019-11478

CVSS 3.x Score: 7.5 (High)

Discovered by Netflix researchers, SACK Panic and Slowness cause a denial-of-service (DoS) by exploiting the Linux kernel’s TCP Selective-Acknowledgement (SACK) functionality. The SACK functionality in Linux was created in 1996 and is responsible for handling fragmented TCP packets to determine if enough packets were received to rebuild fragmented data and, if not, send a message to the sender to require a resend. 

Both vulnerabilities affect TCP procedures, but they affect the kernel in different ways. In a Panic attack, the TCP_SKB_CB(skb)->tcp_gso_segs value is vulnerable to a buffer overflow when handling SACK. This data structure is the socket buffer designed to hold up to 17 TCP packet fragments, but a remote attacker can send over 17 fragments to overflow the buffer and crash Linux. With SACK Slowness, an attacker sends a crafted sequence of acknowledgment messages to the target which will fragment the retransmission queue using tcp_fragment in the kernel, which creates slowdowns. 

Initial mitigations include disabling SACK processing or blocking connections with a low maximum segment size (MSS). The issue with mitigation using these two solutions is that they will cause slowness in TCP processing, which means any device using TCP connections will suffer from performance degradation. This is typically not acceptable in high-traffic servers responsible for critical functions, but you can patch the kernel using KernelCare, which requires no reboot.

Mutagen Astronomy CVE-2018-14634

CVSS 3.x Score: 7.8 (High)

Although Mutagen Astronomy (an anagram for Too Many Arguments) can only be exploited by a local user on the Linux machine, it’s a high-level critical issue because it gives this local user root privileges. The privilege escalation stems from a buffer overflow in the create_elf_tables() function in Linux. An attacker can overflow the MAX_ARG_STRINGS value used to limit arguments passed to the function and inject their own environment variables and functions using a SUID-root binary. The result is that an attacker can escalate privileges, run rogue functions on the local device, or inject their own environment variables. To see a breakdown of the vulnerable code, Qualsys published its findings here.

Not only does this vulnerability require the user to be on the local machine, but the attack requires a device with more than 16GB of RAM and it must be running a 64-bit kernel.  Even so, it’s a critical flaw that should be patched as soon as possible. The researchers at Qualsys that found the flaw state that most Linux users are not affected, but the main targets vulnerable to this attack are RedHat and CentOS systems. RedHat published a workaround, but this still requires a reboot. 

Instead of applying a lengthy workaround, Linux servers running KernelCare will receive the patch and no reboot is required. 

Conclusion

Although not every kernel exploit gets its own CVE, it’s critical for Linux administrators to regularly scan servers for vulnerabilities and patch them when a new one is found. In every one of our examples, the fallout from an unpatched system could be devastating to the business and its reputation.

KernelCare+ can patch all five of the above CVEs with no reboot required instead of mitigation with cumbersome solutions that don’t remedy the issue long-term and create risks and software usability issues. With KernelCare+, you get non-critical and critical patches applied to your servers, glibc and OpenSSL libraries as soon as they are available. No delays, no workarounds, no scheduling, no downtime, and most importantly, no vulnerable servers left open to attackers.