<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=645174729237247&amp;ev=PageView&amp;noscript=1">
We are updating the structure and design of KernelCare blog for your convenience. Today, you may experience some text formatting inconvenience which will be fixed shortly.
Latest Articles

Monthly KernelCare Update - April 2021

April KernelCare newsletter

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.


Monthly KernelCare Update - April 2021

April KernelCare newsletter

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.


KernelCare 2.43-2 released

KernelCare 2.43-2 released

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.

 

KernelCare 2.43-2 released

KernelCare 2.43-2 released

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.

 

KernelCare ePortal 1.21-1 update and UI improvements

KernelCare ePortal 1.21-1 update and UI improvements

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. 

KernelCare ePortal 1.21-1 update and UI improvements

KernelCare ePortal 1.21-1 update and UI improvements

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. 

BPF code can allow local privilege escalation (CVE-2021-29154)

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.  Because of the nature of the BPF functionality, which is to allow user code to interact with network packet processing within the kernel, there is a very big potential for attack given any weakness in the implementation. This specific functionality has been addressed recently in the specter mitigation code bug discussed here.  To be vulnerable, a system would have to be configured to allow BPF JIT compilation (for example, by setting “net.core.bpf_jit_enable = 1”). This is often the case in situations where regular users are doing work related to sockets’ manipulation or in seccomp (secure computing mode) environments where permissions are granted more granularly than normal.  The actual vulnerable code resides in arch/x86/net/bpf_jit_comp.c and arch/x86/net/bpf_jit_comp32.c in the kernel source code tree. The flaw comes from the way branch displacement happens when the user code is compiled, by making wrong assumptions regarding the address of code during optimization.  Proper exploitation of this vulnerability could even lead to container or chroots’ escape, since the kernel is shared between them, and running code in the kernel context permits it to escape containerization limits.  As a stop-gap procedure, you can quickly disable BPF JIT by running:  # echo 0 > /proc/sys/net/core/bpf_jit_enable   Which will persist until reversed or a system reboot. A more permanent removal can be achieved by using your distribution’s syscfg equivalent utility to set “net.core.bpf_jit_enable=0” at boot time. Of course, this type of solution solves the problem by disabling the functionality, which in itself is self-defeating. If you actually had your system configured to use BPF JIT, in all likelihood your use case needed that setting explicitly enabled, and you should rely instead on proper kernel patching, either through your distribution vendor’s patches or through KernelCare’s rebootless process.

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.

BPF code can allow local privilege escalation (CVE-2021-29154)

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.  Because of the nature of the BPF functionality, which is to allow user code to interact with network packet processing within the kernel, there is a very big potential for attack given any weakness in the implementation. This specific functionality has been addressed recently in the specter mitigation code bug discussed here.  To be vulnerable, a system would have to be configured to allow BPF JIT compilation (for example, by setting “net.core.bpf_jit_enable = 1”). This is often the case in situations where regular users are doing work related to sockets’ manipulation or in seccomp (secure computing mode) environments where permissions are granted more granularly than normal.  The actual vulnerable code resides in arch/x86/net/bpf_jit_comp.c and arch/x86/net/bpf_jit_comp32.c in the kernel source code tree. The flaw comes from the way branch displacement happens when the user code is compiled, by making wrong assumptions regarding the address of code during optimization.  Proper exploitation of this vulnerability could even lead to container or chroots’ escape, since the kernel is shared between them, and running code in the kernel context permits it to escape containerization limits.  As a stop-gap procedure, you can quickly disable BPF JIT by running:  # echo 0 > /proc/sys/net/core/bpf_jit_enable   Which will persist until reversed or a system reboot. A more permanent removal can be achieved by using your distribution’s syscfg equivalent utility to set “net.core.bpf_jit_enable=0” at boot time. Of course, this type of solution solves the problem by disabling the functionality, which in itself is self-defeating. If you actually had your system configured to use BPF JIT, in all likelihood your use case needed that setting explicitly enabled, and you should rely instead on proper kernel patching, either through your distribution vendor’s patches or through KernelCare’s rebootless process.

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.

UChecker - are you sure your libraries are up to date?

UChecker - are you sure your libraries are up to date?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”. 

UChecker - are you sure your libraries are up to date?

UChecker - are you sure your libraries are up to date?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”. 

Monthly KernelCare Update - March 2021

Monthly KernelCare blog

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

Monthly KernelCare Update - March 2021

Monthly KernelCare blog

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

20 year old vulnerability in libcurl publicly disclosed CVE-2021-22876

20 year old vulnerability in libcurl publicly disclosed as CVE-2021-22876At 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.

20 year old vulnerability in libcurl publicly disclosed CVE-2021-22876

20 year old vulnerability in libcurl publicly disclosed as CVE-2021-22876At 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.

Two more vulnerabilities uncovered in OpenSSL

Two more vulnerabilities uncovered in OpenSSL

 

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

Two more vulnerabilities uncovered in OpenSSL

Two more vulnerabilities uncovered in OpenSSL

 

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

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

How to Upgrade An Unsupported OS: An In-depth ChecklistUpdating 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?

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

How to Upgrade An Unsupported OS: An In-depth ChecklistUpdating 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?

Spectre just won't remain dead

 Spectre just won't remain dead

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.

Spectre just won't remain dead

 Spectre just won't remain dead

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.