ClickCease New OpenSSL Vulnerabilities Addressed by KernelCare Enterprise

Content Table

Join Our Popular Newsletter

Join 4,500+ Linux & Open Source Professionals!

2x a month. No spam.

New OpenSSL Vulnerabilities Addressed by KernelCare Enterprise

Joao Correia

February 22, 2023 - Technical Evangelist

Patches for recently discovered OpenSSL vulnerabilities are already available through TuxCare’s KernelCare Enterprise, which, for some distributions, we’ve released before the vendor-supplied updates have been made available. Read on to learn more about each vulnerability.

With KernelCare Enterprise, you get security live patches for the Linux kernel, and, through its LibCare component, you also get live patches for critical system libraries, like glibc and OpenSSL. 

These are both enticing targets for threat actors, but also highly disruptive components to patch if you’re not using a live patching approach – as traditional security updates to either one will require an additional system restart or, at the very least, service restarts, to complete.

When you’re relying on OpenSSL to ensure your encrypted communications, certificates, and other assorted cryptographic work is done securely, there is always a concern when new vulnerabilities appear. To keep your systems protected, as we have many other times in the past, the KernelCare team is working tirelessly to provide you with the latest updates in such situations.

The Advisory

On February 7th, the OpenSSL team publicly disclosed information about four new vulnerabilities impacting the OpenSSL 1.x branch (CVE-2023-0286, CVE-2023-0215, CVE-2022-4304, and CVE-2023-4450). They range from Moderate to High risk. This branch of OpenSSL is the most widely deployed in enterprise Linux distributions.

Live patches to address those vulnerabilities are already available for KernelCare Enterprise users running CentOS7/Oracle EL7/Cloud Linux 7/RHEL7, CentOS8/Oracle EL8/Cloud Linux 8/RHEL 8/RockyLinux 8/AlmaLinux 8, Amazon2, Debian10, Ubuntu-Bionic and Ubuntu-Focal. Patches for additional supported systems will be released shortly, and this article will be updated when that happens. 

It’s important to note that the patches are being released ahead of some of the Linux distribution’s regular updates, so your systems are secured not only with no disruption, but also faster than with traditional vendor-supplied updates. Linux distribution vendors will sometimes take longer than desirable to release updated packages to their users. 

Other distributions, like RHEL 7 (and its derivatives) are affected, but will not receive vendor patches at all, as they fall under the vendor’s “out of support scope.” 

You will still receive those updates through TuxCare’s LibCare, as our development team backported the fixed code directly from the upstream OpenSSL code.

A Closer Look at the Vulnerabilities


As mentioned above, OpenSSL enables functionality to accomplish many tasks related to cryptography, including certificate signing, parsing, and validation. It was found that by crafting a certificate with a specific type of value (an X.400 address) inside an X.509 GeneralName, an attacker could force an application to read specific memory contents. In turn, this could lead to information disclosure or a denial of service (by crashing the application). 

While the results of a successful exploit are dangerous, there is no indication of active usage “in the wild,” and setting up the attack involves a convoluted set of steps and a particular usage on the application side.


OpenSSL provides stream-like functionality to applications, at the code level, with an abstraction called a “BIO.” It is similar in concept to a “FILE *” in C, and enables a developer to rely on encryption functionality in a transparent way, with the underlying sometimes-hard-to-understand cryptographic functions hidden away inside of OpenSSL.

BIO_new_NDEF” is a helper function used to stream ASN.1 data. The way that different “BIO” functions could be chained together to provide high-level functionality (for example, receiving->decrypting->copying->encrypting) could be abused by triggering a NULL result from “BIO_new_NDEF” and breaking the chain unexpectedly. In this scenario, there would be a use-after-free and the application could crash (or worse, be left in an undefined state).

Many public facing functions in OpenSSL will internally call the affected function, and as such, the attack surface is much larger than a single broken function.

Side channel attacks rely on observable behavior not necessarily tied to the code being attacked, but rather characteristics, like a given operation taking more or less time to execute, using more or less memory, or particular settings of a given environment, to infer some hidden information.

It was found that it was possible to recover plaintext information remotely by sending a large number of messages for decryption, and measuring the time to process said messages. It would be possible to infer the prime values used in a TLS connection handshake that uses RSA encryption (the OpenSSL disclosure compares this to a “Bleichenbacher attack”).

It is noteworthy that initial information about a potential timing side channel opportunity was presented as far back as July, 2020, and only now has the issue been narrowed down and fixed.

Dealing with any kind of user-controlled input is always risky for an application, as malicious actors can craft elaborate inputs that abuse specific code and lead to unexpected results. Again in the certificate processing part of OpenSSL, a specially crafted PEM-encoded certificate with 0 bytes of payload data could trigger a use-after-free bug and likely lead to an application crash (and ensuing denial of service).

This type of check is very common in applications and services, as well as directly in OpenSSL-supplied command line utilities.

Secure Systems Faster and More Reliably

KernelCare Enterprise, through LibCare, provides the updates needed to maintain system security in critical situations, where any delay, such as waiting for a maintenance window, is just too long to countenance. While we traditionally prefer to use specific distribution fixes, when those distributions are slow to react, we will nonetheless provide the fix to our customers. 

With KernelCare Enterprise, you can rest assured that we are tracking the latest threats and providing you with the adequate defenses to solidify your security and compliance posture, all while maintaining business availability with zero disruption.


New OpenSSL Vulnerabilities Addressed by KernelCare Enterprise
Article Name
New OpenSSL Vulnerabilities Addressed by KernelCare Enterprise
Patches for recently discovered OpenSSL vulnerabilities are available through TuxCare’s KernelCare Enterprise: Learn more about each of them.
Publisher Name
Publisher Logo

Looking to automate vulnerability patching without kernel reboots, system downtime, or scheduled maintenance windows?

Learn About Live Patching with TuxCare

Become a TuxCare Guest Writer

Get started




Linux & Open Source

Subscribe to
our newsletter