How to Upgrade An Unsupported OS: An In-depth Checklist

ePortal is KernelCare Enterprise’s solution for deployments where the machines that need to receive the updates have restricted internet access, serving as a central staging point of delivery for patches, thus reducing exposure of internal resources to outside access.

The KernelCare team is proud to announce the release of ePortal 1.21-1, with many UI improvements and often requested functionality added. One such feature is the ability to control and receive only patches for a specific subset of KernelCare’s supported list of distributions, for example for environments where only one or two different distributions are used. 

Another vulnerability targeting the BPF subsystem has been disclosed publicly in the past few days (CVE-2021-29154). It allows users on a system running non-default configuration of the BPF subsystem to run specially crafted code as a BPF filter and run arbitrary executable code in the kernel context. 

According to vendors, it affects all distributions running kernels up to version 5.11.12. Distribution vendors are starting to deliver patches through their update mechanisms, and KernelCare is also finalizing patches for it’s rebootless patching process to address this issue.

When you see so many vulnerabilities being reported and so many security-related issues being exploited, you may think to yourself “I’m lucky not to be using that package or software, I’m not vulnerable to this”. 

In this month’s update, we highlight CVEs that just won’t die. We’ve also published some critical information regarding live patching the Microsoft Azure IoT Hub with KernelCare IoT integrations. Additionally, we know many still love their old, unsupported distros. The KernelCare team presents an in-depth checklist on how to upgrade an unsupported OS. Keep reading for more details or watch a quick video recap.
.

At what point does an old vulnerability go from being a bug to becoming a feature? That is the question probably going through the mind of many software developers who use libcurl as part of their applications, as a bug was discovered in code committed in August of 2000 to the libcurl code base.

OpenSSL, the widely used cryptography toolkit and library, has been the target of security researchers’ audits more than almost any other project, perhaps only excluding the Linux Kernel itself. This week was no exception, and again some issues were found.

Updating an OS seems like a trivial task. The type of activity a sysadmin instinctively knows how to perform. But have you ever actually considered the full scope of it? All the different threads that must be knit together to perform it successfully, safely and predictably? What if the operating system, on top of being old, is also no longer supported?

Shortly after exploit code was found in a public repository, two new vulnerabilities (CVE-2020-27170 and CVE-2020-27171) have been found in the Linux Kernel code that protects against it.

Both vulnerabilities allow a local user to read kernel memory which could contain sensitive information like encryption keys. Proof-of-concept code has also been made available privately, but it is safe to assume it will eventually reach public outlets.

Cyber threats come and go, but some threats leave a lasting imprint due to their impact. Think of Spectre and the closely related Meltdown, for example, two of the most widely covered vulnerabilities in recent memory.

It is of course frustrating when a cyber threat simply refuses to go away, and even worse when it is a highly prominent vulnerability. That’s turning out to be the case with Spectre, one of the most dangerous exploits of recent times. While patched systems are protected against Spectre, the nature of Spectre patches and the resulting impact on performance means that a large number of systems have not been patched..

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.