On December 8, 2020 OpenSSL released an advisory patch for a high-risk null pointer dereference vulnerability found in the encryption library’s GENERAL_NAME_cmp() function.  CVE-2020-1971 (assigned name) is the High level vulnerability that cannot be ignored. The only level higher is the Critical level which happens maybe once in 5 years.

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 highest threat from this vulnerability is to system availability. Read more about CVE-2020-1971 here.

OpenSSL will provide the patch but it will only be available for versions of OpenSSL - CentOS 7 and 8, but NOT for CentOS6. But, CloudLinux already took care of it and all CloudLinux’ Extended Support for CentOS 6 users already received the patches that fixes this issue. Keep on reading to learn how our Team can keep your systems secure and discover more about CVE-2020-1971. 

How hackers can exploit the OpenSSL Vulnerability? 

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 this could result in segmentation fault. Thanks to David Benjamin, the Google security researcher, David Benjamin, who found the vulnerability and demonstrated that OpenSSL will crash if malformed input is sent to them!

Who is vulnerable?

We are concerned that hackers will target this CVE specifically because they know most organizations are NO longer receiving security updates for CentOS 6. 

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 who use OpenSSL as a dependency should also patch the encryption library, especially if they implement s_server, s_client and verify tools for certificates. All these tools use GENERAL_NAME_cmp() in their functionality and have to be updated. 

How CloudLinux Takes Control of the Situation 

To mitigate the risks, the CloudLinux team  already took control of the situation and distributed security patches for our CentOS 6 Extended Lifecycle Support customers to pick up from our repositories. 

CloudLinux will mitigate this vulnerability also for version 1.0.1. (OpenSSL is going to fix this vulnerability only for versions 1.0.2 and  1.1.1). While KernelCare+ will already automatically start live patching this CVE in OpenSSL this week. By the way, follow this link to out more about how KernelCare+ patches vulnerabilities on the fly.

Enjoy Safety with CloudLinux’s Extended Support for CentOS 6

With Extended Support for CentOS 6 and CloudLinux's CentOS 6 ELS and KernelCare+ Bundle, you can stop worrying about vulnerabilities and focus on more important things. 

Extended Support for CentOS 6 will keep your Linux systems updated  and secure — addressing all currently emerging CVEs. With CentOS 6 ELS and KernelCare+ Bundle, you can get your system protected from all angles.

The installation process is simple: 

1. Run one command to add a new repository file. 
2. 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. 

Focus on important things while CloudLinux will take care of your safety!