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

Our April 2021 blog post is out. We’ve got lots to tell you about, so let’s get started. First up, we highlight UChecker, a tool that checks for vulnerable libraries in your Linux system. Next up is the monthly CVE report. This month, a 20-year-old vulnerability rears its ugly head, and a BPF code vulnerability reveals itself. Next, we’ve updated the KernelCare ePortal. This month we have a guest article about securing your non-commercial IoT devices. We also focus on two informative videos. Last but not least, CentOS AlmaLinux to receive CloudLinux support.

The KernelCare team is proud to announce the release of KernelCare 2.43-2, bringing new features and bug fixes to the enterprise’s live patching tool of choice. This follows the recent update to ePortal, and signals KernelCare’s continued commitment to support and maintain this important and widely used enterprise tool, giving users the confidence to continue to depend on it for their live patching needs.

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.

[Update 20 April: Over the past weeks, KernelCare has released patches for CVE-2021-3449 covering AlmaLinux OS 8, RHEL 8, Ubuntu 18.04, Ubuntu 20.04, Centos 8, Debian 10, Oracle Linux 8, and for CVE-2021-3450 covering AlmaLinux OS 8, Centos 8, Oracle Linux 8, RHEL 8. If you're running KernelCare on one of those systems, you have already received the patches.]

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.