The OpenSSL project has pre-announced a new and critical severity vulnerability, which was downgraded to High as of today, Nov. 1, 2022. The initial pre-announcement blog has been updated here to reflect additional remediation guidance.
About OpenSSL
OpenSSL offers users an open source option to implement the TLS protocol, with a cryptography library that allows you to create and sign certificates, or create private keys that demonstrate a secured network communication. For example, HTTPS requires an SSL certificate, and is a mandated requirement across Chrome, Firefox and countless other applications. In GitHub alone, there are 41M code references.
Who is potentially exposed
At this point, it is clear that all of the OpenSSL 3.0 versions except for the updated release, OpenSSL 3.0.7, are potentially vulnerable. This vulnerability has some dependencies that will determine whether or not it can be exploited. For example, stack overflow protections are found to mitigate possible remote code execution (though a crash might still happen instead). The official guidance about who is vulnerable states that, “Any OpenSSL 3.0 application that verifies X.509 certificates received from untrusted sources should be considered vulnerable.” OpenSSL 3.0 was released on September 7, 2021. While OpenSSL 1.xhas been available for 12 years, OpenSSL 1.1.1 and 1.0.2 are not affected by this issue.
About the vulnerabilities
The actual vulnerabilities released today are milder and less critical than initially thought. CVE-2022-3602 was downgraded to a severity level of High because, in extensive testing, it was determined that the possibilities for remote code execution were less likely than originally believed. A second listed vulnerability, CVE-2022-3786, was also listed as High severity.
With these vulnerabilities, in a certificate exchange (for secure communications) between an application and the web server, an attacker could theoretically create a malicious certificate that allows them to take the web server down or accomplish remote code execution by triggering a buffer overflow. In this case, any applications connecting to the affected web server would crash. The web server must use a version of OpenSSL that does not allow for this exploit in order to prevent this from happening.
The conditions that could lead to remote code execution (RCE) on popular platforms is unlikely. The conditions will vary, however, by platform and compiler combinations used in conjunction with affected OpenSSL libraries. No RCE exploits are known at this time.
How to detect and mitigate the vulnerability
If you have already identified where you might be vulnerable, based on the pre-announcement, you have a head start. You can search your software bills of material (SBOMs) and identifying where the vulnerable OpenSSL libraries are used and running. See here a video of doing this with Aqua’s supply chain security solution:
Customers using Aqua’s supply chain security solution can query all images, containers and hosts for the existence of the OpenSSL vulnerabilities.
You can also create an Assurance Policy that makes these images/containers/hosts non-compliant if there is evidence of an affected OpenSSL version. Click here to see a demo of this process.
If you are using the Open Source Aqua Trivy scanner, you can take advantage of its SBOM capabilities to find OpenSSL usage:
Is Aqua impacted?
No, Aqua uses base images with a version of OpenSSL that is not impacted.
Summary
This OpenSSL vulnerability has the potential to cause disruption to affected systems and organizations worldwide. While the severity of the vulnerability was downgraded, affected users should still take all steps to identify and remediate their potential exposure immediately..
Sign up for a free assessment of Aqua’s Software Supply Chain Security solution to understand your impact, remediate, and proactively prevent further impact. Or download Trivy for the quickest view into the impact on your environment.
