KernelCare+ Patches For CVE-2020-1971 Are Here

Big news from the OpenSSL team – they issued the fix for a new CVE-2020-1971 that causes servers’ disruptions via x509v3 certificate fields. The good news is that it cannot result in data theft; however, it has the ability to shut down your servers and paralyse the company’s operation flows. OpenSSL 1.1.1 and 1.0.2 versions are affected by this issue. Other OpenSSL releases are out of support, have not been checked and with high probability will not be addressed by the vendor.

Right now, the KernelCare Team is doing a delicate work of porting the vendor’s 1.1.1 patches to v.1.1.0 and enriching it with the live patching technology. The rebootless patches for both supported and unsupported versions of OpenSSL will be delivered in 24 hours for CentOS6, and 7 with the patches for the rest supported distributions released later this week.

UPDATE from December 9:

Patches for CentOS 6 and CentOS 7 have been released. KernelCare clients will start receiving the updates in the 4 next hours.

To mitigate additional risks, we will release a new version of the KernelCare Agent tomorrow.

Contents:

1. What happened?
2. How to mitigate CVE-2020-1971 without a system restart or reboot?
3. About CVE-2020-1971

What happened?

The worst came to worst for CentOS6 users and other EOL distributions that are running OpenSSL versions older than 1.1.1 and 1.0.2: based on the open sources, earlier OpenSSL releases are out of support and it is safe to assume that the vendor will not release the fixes for CVE-2020-1971 for the older library versions, thus leaving enterprise servers susceptible to being shut down by malicious actors.  At this point, KernelCare+ is one of the few services who have the patches for CVE-2020-1971 planned for the release in 24 hours and can update old and new OpenSSL without service restart or server reboots.

Those who stick with the end-of-life operating systems or shared libraries had several constructive reasons to do so. Let’s face it: migration to a new shared library or OS is a tiresome and costly affair. And even if sysadmins are on board with updating thousand server fleets, enterprise management adequately evaluates the amount of necessary financial and time resources, hence, remains hesitant.

So, what choice do you have now? The most obvious one – if you are using v1.1.x of OpenSSL – roll up your sleeves and patch CVE-2020-1971 manually. If you are on v1.0 – upgrade to the newer version of OpenSSL to get the fix. Whatever your choice is – both require service restarts or rebooting the whole system for the shared library update to take effect. No matter what you choose – the aftermath is the same – downtime and additional workload.

How to mitigate CVE-2020-1971 without a system restart or reboot?

There is also a third option of updating OpenSSL without migration to the newer version or manual patching. The one that does not add an extreme burden on your workload caused by the emergency updates. Let KernelCare+ patch OpenSSL for you automatically.

KernelCare+ team is now in the process of porting the vendor’s 1.1.1 patches to v.1.1.0 and enriching it with the live patching technology. KernelCare+ is live patching for Shared libraries that applies security updates without affecting the operational state of your applications — no restarts, no reboots. Besides live patching of Glibc and OpenSSL, KernelCare+ will protect Linux kernels as well.

The KernelCare patches will be released on December 9th, 2020. First – for the most affected distributions – CentOS 6 and CentOS 7. The patches for the rest of the distributions will be available in the coming days.

Get a FREE 7-Day Supported Trial of KernelCare 

Your fourth option is to buy an Extended Livecycle Support from a CloudLinux, or opt for a powerful duo: CloudLinux’s CentOS 6 ELS and KernelCare+ Bundle. The installation process is simple: run one command to add a new repository file. After that, CloudLinux will provide you with updates to OpenSSL, Glibc, cPanel, Apache, PHP, MySQL, OpenSSH, Zlib, etc. The job of KernelCare+ will be to give you these updates without reboot and disruption to your processes and operations.

About CVE-2020-1971

OpenSSL recently (December 8, 2020) released an advisory patch for a high-risk null pointer dereference vulnerability found in the encryption library’s GENERAL_NAME_cmp() function. With this vulnerability left unpatched, an attacker can send maliciously crafted parameters to the GENERAL_NAME_cmp() function and crash the system causing a denial-of-service (DoS) condition. The vulnerability has been assigned CVE-2020-1971.

The purpose of the GENERAL_NAME_cmp() function is twofold:

1. It compares certificate revocation list (CRL) distribution point names between the available CRL downloaded using the “-crl_download” option and the CRL distribution point included in the X.509 certificate.
2. It verifies the timestamp response token signer matches the timestamp authority name.

If an attacker can control both parameters being compared, they can crash the system using maliciously crafted CRLs or malicious X.509 certificates.

OpenSSL uses a generic type named GeneralName to use for the comparisons. One of the types is called EDIPartyName. If both parameters contain the EDIPartyName type, the OpenSSL code handles it as “other” and a segmentation fault results.

Any servers using OpenSSL versions 1.1.1-1.1.1h and versions 1.0.2-1.0.2w should update to the latest 1.1.1i or 1.0.2x version. Developers that use OpenSSL as a dependency should also patch the encryption library, especially if they implement s_server, s_client and verify tools for certificates. These tools use GENERAL_NAME_cmp() in their functionality, and the Google security researcher, David Benjamin, who found the vulnerability proved and demonstrated that OpenSSL will crash if malformed input is sent to them.