Check the status of CVEs. Learn More.
Keeping your systems up 100% of the time requires live patching. Our solutions will align strongly with your risk, compliance, and operational uptime requirements.
TuxCare is trusted by the most innovative companies across the globe.
Learn about TuxCare's modern approach to reducing cybersecurity risk with Blogs, White Papers, and more.
Continually increasing Cybersecurity, stability, and availability of Linux servers and open source software since 2009.
TuxCare provides live security patching for numerous industries. Learn how TuxCare is minimizing risk for companies around the world.
2x a month. No spam.
December 8, 2020 - TuxCare expert team
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.
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.
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.
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:
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.
Learn About Live Patching with TuxCare
End-of-life software is just a fact of our fast-paced technology...
Look, everyone knows that it’s a tough act. Thousands of...
The public sector, including state and federal agencies, are at...
If your organization deploys IoT solutions, you know that development...
We continue to look at the code issues that cause...
Catastrophic risks such as natural disasters and indeed cyberattacks require...