OpenSSL, the widely used cryptography toolkit and library, has been the target of security researchers’ audits more than almost any other project, perhaps only excluding the Linux Kernel itself. This week was no exception, and again some issues were found.
Rather than reinventing the wheel every time they need a secure communication channel or perform a certificate validation, for example, programmers rely on the tried and tested OpenSSL library. They enjoy the ease of use and wide adoption, even across operating systems and architectures, of not having to worry about these common functionalities and focusing on core application goals.
So, whenever the alarms go off around OpenSSL, many pay attention and take it seriously. Just this week, two new vulnerabilities were disclosed, CVE-2021-3449 and CVE-2021-3450, affecting all OpenSSL versions in the 1.1.1 branch. These are the versions bundled with several operating systems like RHEL 8, which means systems running them should upgrade OpenSSL as soon as possible, as OpenSSL 1.1.1k contains the fix for both problems.
The first vulnerability, CVE-2021-3449, is a possible Denial-of-Service (DoS) vulnerability, where a malicious actor could crash a server application (for example, a web or an email server) that is using TLSv1.2 configured for renegotiation - unfortunately, this is the default behavior, so unless a configuration change was explicitly set, any software using TLSv1.2 could be crashed remotely. The problem comes from a missing parameter validation in a specific code-path, which could lead to a NULL pointer being used - immediately triggering the crash.
The second vulnerability, CVE-2021-3450, permits specially crafted certificates to be accepted as CA (Certification Authority) certificates by programs using vulnerable OpenSSL versions, which means all the validation and assurances that come from having a chain-of-trust of certificates is potentially eliminated, making fake certificates show up as actual, trustworthy certificates.
The KernelCare team has already started working on the patches, and they should be available early next week for affected systems running KernelCare. This post will be updated with specific operating system patch availability as they are completed.