Three more zombie kernel bugs prove why you must patch consistently

Very recently, a long-known vulnerability called Spectre re-emerged due to an exploit that was made available publicly, and a lack of patching meant that this well known vulnerability poses a danger again.

And, yet again, something similar happened. This time, security researchers found three critical bugs in 15-year-old Linux kernel code. Code this old should have been thoroughly scrutinized for bugs by now – and it is anybody’s guess how often these vulnerabilities have been exploited by malicious actors in the meantime.

Patches have now been released for CentOS 8, Oracle EL8, RHEL8, CloudLinux 7h, CloudLinux 8, AlmaLinux OS, Ubuntu Bionic HWE, Debian 10, Debian 10 Cloud, Debian 9 Backports and Proxmox VE6.

Additionally, patches are now also available for CloudLinux 6h, CloudLinux 7, CentOS 7, CentOS 7-plus, Oracle EL7, and RHEL 7.

In this article, we outline the three vulnerabilities just discovered, explain why open-source code is not always scrutinized as well as it should be (or by the right people), and point to the importance of patching consistently.

Content

1. Old code coming back to haunt us

2. Obvious coding flaws

3. You’re vulnerable even if you don’t use SCSI

4. Just because code is open-source and free to look at….

5. Patching can save your servers

6. Consider automated patching

7. Patches release schedule

Old code coming back to haunt us

The surprising thing about many modern-day operating systems is that the underlying code can be quite old. As Linux evolved from its 1991 roots the kernel was continuously updated, but that does not mean there was a wholesale rewrite of the Linux kernel. Code was added, updated, and removed but not all in one go.

As a result, the modern, current release of the Linux OS that you are using can contain code that is decades old. And it is in code more than a decade old that three vulnerabilities were found – logged as CVE-2021-27363, CVE-2021-27364 and CVE-2021-27365.

We won’t discuss the three vulnerabilities in great depth in this article – you can read the original coverage over at GRIMM. But here’s a quick overview.

The researchers at GRIMM were, as they put it, casually examining code in the Linux kernel when an extremely visible security vulnerability jumped out at them. In the series of three bugs reported by the company, the first bug was dead obvious. It also reflected a lack of awareness about security risks at the time the code was written.

This code was present on all kernel versions up to 5.11.3. This translates into bugs affecting all Linux distributions and all versions going back 15 years.

Obvious coding flaws

GRIMM’s team found a problem in the SCSI driver code. It was dead obvious: the programmer neglected to specify a length parameter when including char *buf in one area of the code. With no length validation, an attacker could, with a bit of effort, exploit this code to launch an attack.

The second and third vulnerabilities were located in the Linux iSCSI subsystem. In the second, the programmer used a kernel address as a handle (which could allow an attacker to bypass Kernel Address Space Layout Randomization) and in the third the programmer neglected to validate user data in the kernel.

All three vulnerabilities point to common programming flaws that lead to security issues – but at the time the code was written, programmers were not that widely aware of these problems. Today, these programming flaws allow a malevolent actor to execute a local privilege escalation attack in multiple Linux distributions.

You’re vulnerable even if you don’t use SCSI

The three latest vulnerabilities all relate to SCSI drivers. SCSI, short for small computer systems interface, is a 1986 standard for connecting computers and peripherals. It has evolved over the years, and it is still in use via standards such as Serial Attached SCSI (SAS) and iSCSI, which is essentially SCSI over TCP.

But even if your workload does not depend on SCSI these vulnerabilities can still affect your servers. The reason for this is the way Linux kernel packages depend on each other. SCSI driver code can be loaded into the memory of your server even if you do not have a SCSI device connected to your server, simply because of dependencies.

As a simple example, take iSCSI which is still a reliable way to access centralized data over a network. If your server calls iSCSI it will in turn call the SCSI code in which the vulnerabilities were found. It occurs automatically as the Linux kernel identifies that functionality in a module may be needed and loads the module.

In turn, threat actors can rely on the fact that modules are automatically loaded on demand to exploit vulnerabilities in code that you may well never use in your workload.

Just because code is open-source and free to look at….

There is an interesting aspect to the three vulnerabilities just listed. Open-source code is, by definition, open to scrutiny. The code is published in the public domain and can be freely viewed and experimented with.

In theory at least this could mean that open-source code is highly secure because it is so open to scrutiny. This is the assumption many people make about open-source code.

However, the three vulnerabilities we discuss were found in code that has been part of the Linux kernel for 15 years. One would have thought that these highly visible vulnerabilities would have been found long ago – but they weren’t.

So, in some ways, the premise that open source code is more secure because it is open to scrutiny is arguably less valid than it seems at first glance.

On the flipside, it is also hard to know whether any advanced persistent threat (APT) actors found these vulnerabilities before white hat security researchers did, and what they did with the knowledge. The sheer volume of Linux kernel vulnerabilities discovered every year also points to many unknown vulnerabilities yet to be found that could lead to security breaches.

Patching can save your servers

Linux kernel vulnerabilities keep piling up, and apparently, 15-year-old code can still spring a surprise. While you cannot patch against vulnerabilities that have not yet been discovered by security researchers, you can patch against the vulnerabilities and associated exploits that are in the public domain. Not doing so would be foolish.

Patching against known vulnerabilities also hardens your system. Even if an actor manages to get into your network due to a vulnerability that has not yet been discovered by researchers, lateral movement will be more difficult if your systems are consistently patched against known exploits.

But, as we all know, consistent patching simply is not easy. Often it requires reboots, taking servers offline and disrupting services. There are also the labor-hours involved – patching takes time. For that reason, patching is often neglected.

Consider automated patching

Enterprises that depend on Linux-based operating systems have the option of rolling out automated patching which removes the need to manually apply OS patches.

In the case of the KernelCare automated patching solution, it comes with the additional benefit of live, rebootless patching. In other words, KernelCare can automatically patch your servers and do so live, without requiring a server restart.

Yet, whichever route you choose – careful manual patching, or a live patching tool such as KernelCare, it is critical that you patch consistently to protect your workload against existing and emerging threats.

Patch Release Schedule

The KernelCare team is working on rebootless patches for these vulnerabilities right now. The first patches are planned for distribution on the 18th of March. Keep an eye on this blog post to get an update when the patches come out.