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.

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.

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 discovery of a new Linux kernel vulnerability is not a major surprise in its own right. It happens all the time. However, sometimes it appears as if, whenever a security researcher goes looking, the researcher discovers a new, serious vulnerability in the Linux kernel – and that it happens just too often for comfort.

This February, a new vulnerability was reported in a relatively obscure corner of the Linux kernel – in a function that facilitates communications between virtual machine host and guest. Though just discovered, it is already listed as CVE-2021-26708.

In this article we outline the vulnerability, explain how it emerged, and point to the potential risks the new vulnerability holds.

Buffer overflow vulnerabilities remain a common way in which cyber criminals gain illegal entry into computer systems. According to the National Vulnerability Database, there has been a steady increase in reported buffer overflow vulnerabilities over the decades – with 842 reported just last year.

A new week, a new vulnerability announced. This time, it affects kernels starting from version 5.5-rc1 (November 2019) up 5.10.13 (February 2021).

This vulnerability is an improperly handled race condition in the AF_VSOCK implementation, a kernel facility available to unprivileged users that is shipped as a kernel module in all major distributions.