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

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.

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.]

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.

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.

We’ve covered brand new Linux kernel vulnerabilities in a few of our past articles, but in this article we’ll take a look at a vulnerability that’s been re-listed accidentally. Both reports – the erroneous relisting, and the original listing – point to a vulnerability in Linux kernel memory mapping where a race condition can develop when a memory expansion function is used.

We’ll cover the vulnerability as it stands. But we’ll also look at a key issue revealed by the double listing: if security experts can so easily lose sight of an existing vulnerability to the extent that a vulnerability is relisted as “new” and “just discovered” – what does it say about the state of vulnerability management?

And what does it mean for Linux users around the globe, vulnerable to countless offensive strategies – but dependent on the security experts for assistance?

A flaw in the way OpenSSL API function X509_issuer_and_serial_hash() has been disclosed that may lead applications using it to crash, causing a potential denial-of-service (DoS) to their users. 

The flaw lies in the way a hash is calculated from the Issuer and Serial Number data of an X509 certificate, which can make OpenSSL fail returning a NULL value. In turn, this can crash the application calling the function.

The KernelCare team are following developments for a recently-reported vulnerability involving QEMU-KVM guests running Linux kernels.

KernelCare patches will start rolling out on Monday, 12 August.

A new month has started—Summer is in full swing—Must be time for another CPU vulnerability. (Let’s hope this one has a catchy name.)