There are two high vulnerabilities in OpenSSL versions 3.0.0 – 3.0.6. On November 1, the project released OpenSSL version 3.0.7, which mitigates potential exploitation from CVE-2022-3602, “X.509 Email Address 4-byte Buffer Overflow,” along with CVE-2022-3786, “X.509 Email Address Variable Length Buffer Overflow.”
What is OpenSSL?
OpenSSL is one of the most widely used encryption libraries available. It is used to generate certificates and communications in networks using TLS (Transport Layer Security).
The good news is that the affected versions of OpenSSL (3.0.0-3.0.6) are far less common than version 1.
At Bionic, we found that less than 2% of our customers’ instances are impacted by OpenSSL 3.0.0-3.0.6.
Although less common, vulnerable versions of OpenSSL are present in many popular operating systems, such as Ubuntu 22.04 LTS, Fedora 36, and MacOS Ventura.
What You Need to Know about the OpenSSL Vulnerability
The OpenSSL project initially assessed CVE-2022-3602 as critical, but downgraded it to high on November 1. While analysis is still underway, we know that it’s unlikely to be exploitable in a remote-code execution scenario, but could be still exploitable in a denial-of-service scenario.
Our initial assessment is that this is a limited stack overflow vulnerability. It has become extremely difficult to exploit a stack overflow vulnerability because common operating system protection mechanisms have matured over the last decade. While there are instances in which exploitation was proven possible, it’s widely accepted that such a vulnerability is not exploitable in remote code execution scenarios.
This vulnerability is reminiscent of OpenSSL’s Heartbleed vulnerability in 2014, which affected major portions of the internet and caused immense leakage of sensitive data and encryption keys.
Any OpenSSL 3.0 application that verifies X.509 certificates received from untrusted sources should be considered vulnerable. This includes TLS clients, and TLS servers that are configured to use TLS client authentication. If you have an earlier version of OpenSSL, you are not vulnerable.
What Should Security Teams Do?
Identify the application, services, and dependencies that use vulnerable versions of OpenSSL.
Prioritize your findings based on business criticality or exposure. Is this service internet-facing? Does it access sensitive data? If you answer yes to either or both of these questions, then you should prioritize fixing those issues first.
Fix the issues that create business risk. Identify the service owner(s) and ensure they deploy the patch to the affected service(s) immediately.
Detecting and Patching the OpenSSL Vulnerability with Bionic
As mentioned earlier, we found that OpenSSL 3.0.0-3.0.6 impacts less than 2% of our customers’ applications.
Bionic can be used to find services that use OpenSSL in an application architecture. To get this information, use the Bionic query builder to search for any services that use OpenSSL library 3.0.0-3.0.6. This includes services in which the library is installed and services where the library is loaded into memory.
In this example, we’ve found a java process that uses OpenSSL version 1.1. The Collected Data tab displays the relevant information about the process.
Here’s What to Do Next
Communicate with the application/service owners and other stakeholders across your organization about this vulnerability. Inform them of what it is, the actions you have taken to fix it, along with the status of any remediation.
In this context, it’s most important to assure your stakeholders that you’ve prioritized patching for any vulnerable instances in production. If you’ve identified OpenSSL version 3.0.0, but it’s not in a production environment, it’s okay to de-prioritize patching until you’ve fixed the instances that are in production, internet-facing, and/or connected to sensitive data.
If you are unsure if your current tooling has detected all vulnerable instances of OpenSSL, get in touch with us now. We can help you find and fix any vulnerability that creates real risk, without the zero-day fire drill. See Bionic in action.