<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

KernelCare for IoT adds support for Raspbian

KernelCare for IoT adds support for RaspbianSo, you have your shiny new Raspberry Pi, a great idea to use it, and the technical skill to pull it off successfully. It doesn’t matter if it’s as a network print server, a dedicated media center, a retro arcade cabinet or a home automation system. The Pi has you covered.

 

You configure it to your heart content, adjust every parameter and setting to squeeze out the performance you need, create your best invention. The Pi is foremost an enabling platform, letting you give free rein to your creativity.

 

And then you let your project run. After the initial set up and configuration, the Pi can be hidden away and forgotten, while it sits in your home network performing its function. And maybe you don’t follow IT security news, or miss a relevant vulnerability report amongst the flood of CVEs, or simply don’t think anyone would target your Pi to exploit any weaknesses. The thing is, hackers love this kind of device because they present an entry point into your network.

KernelCare for IoT adds support for Raspbian

KernelCare for IoT adds support for RaspbianSo, you have your shiny new Raspberry Pi, a great idea to use it, and the technical skill to pull it off successfully. It doesn’t matter if it’s as a network print server, a dedicated media center, a retro arcade cabinet or a home automation system. The Pi has you covered.

 

You configure it to your heart content, adjust every parameter and setting to squeeze out the performance you need, create your best invention. The Pi is foremost an enabling platform, letting you give free rein to your creativity.

 

And then you let your project run. After the initial set up and configuration, the Pi can be hidden away and forgotten, while it sits in your home network performing its function. And maybe you don’t follow IT security news, or miss a relevant vulnerability report amongst the flood of CVEs, or simply don’t think anyone would target your Pi to exploit any weaknesses. The thing is, hackers love this kind of device because they present an entry point into your network.

KernelCare ePortal 1.22-1 released

KernelCare ePortal 1.22-1 released

The KernelCare Team is proud to announce the latest update to ePortal, its centralized management interface for KernelCare clients. It’s now at version 1.22-1, and it has some new features, namely the easier deployment of the KernelCare client, and some bug fixes.

KernelCare ePortal 1.22-1 released

KernelCare ePortal 1.22-1 released

The KernelCare Team is proud to announce the latest update to ePortal, its centralized management interface for KernelCare clients. It’s now at version 1.22-1, and it has some new features, namely the easier deployment of the KernelCare client, and some bug fixes.

And now, for something completely different... TuxCare!

And now, for something completely different... TuxCare!

 

CloudLinux Enterprise services have been growing steadily for years now. KernelCare, for example, was launched around 6 years ago as a live patching tool for the Linux Kernel. Since then we have added several useful integrations for vulnerability scanners, automation tools and others, and we also released KernelCare+ which adds live patching for OpenSSL and glibc shared libraries.

Last year we also added Extended Lifecycle Support services that let you continue to receive security updates for your systems that are past their original vendor’s End-of-Life date. So if you need more time to migrate to current versions of your distro we can continue to provide patches and updates up to four years past the EOL date.

And now, for something completely different... TuxCare!

And now, for something completely different... TuxCare!

 

CloudLinux Enterprise services have been growing steadily for years now. KernelCare, for example, was launched around 6 years ago as a live patching tool for the Linux Kernel. Since then we have added several useful integrations for vulnerability scanners, automation tools and others, and we also released KernelCare+ which adds live patching for OpenSSL and glibc shared libraries.

Last year we also added Extended Lifecycle Support services that let you continue to receive security updates for your systems that are past their original vendor’s End-of-Life date. So if you need more time to migrate to current versions of your distro we can continue to provide patches and updates up to four years past the EOL date.

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.