An important new vulnerability was discovered in OpenSSL, a popular open source software component. The good news is that the latest release (v3.0.7) fixes the vulnerability. The bad news is that it’s going to take a while for teams to upgrade. 

The vulnerability’s rating was downgraded from CRITICAL to HIGH based on the OpenSSL security policy. OpenSSL has published an article explaining the vulnerability’s rating. Essentially, the issue was around whether there’s a possibility of remote code execution, about which OpenSSL wrote:

Exposure to remote code execution is not expected on any platforms. We still consider these issues to be serious vulnerabilities and affected users are encouraged to upgrade as soon as possible.

So, what should you do and can RapidFort help?

What to do about the OpenSSL vulnerability

The official CVEs for the OpenSSL vulnerabilities are CVE-2022-3786 and CVE-2022-3602 and concern buffer overflows. Any deployments containing OpenSSL v3.0.0-3.0.6 are currently exposed. The official recommendation from OpenSSL states:

Users of OpenSSL 3.0.0 - 3.0.6 are encouraged to upgrade to 3.0.7 as soon as possible. If you obtain your copy of OpenSSL from your Operating System vendor or other third party then you should seek to obtain an updated version from them as soon as possible.

How do I know if I’m running OpenSSL 3.0.0-3.0.6?

The best way to know if you’re vulnerable is to use an SCA scanner to generate a software bill of materials (SBOM). RapidFort has a free SCA scanner for Docker containers you can use to do this. It’s fast, non-intrusive, and easy to use.

It’s important to scan all of your containers because 50-80% of most containers consist of open-source software that may be installed and running without your knowledge. Somewhere deep in the software supply chain there may be a dependency on OpenSSL by some third-party library or framework. Don’t assume you’re not running OpenSSL just because there’s no initial evidence you use it.

TIm Mackey, Principal Security Strategist for Synopsys, writes: “The critical flaw identified in OpenSSL is an example of why software composition analysis (SCA) is so fundamentally important for any AppSec and Infosec team. In preparation for the release of the patch on November 1st, response teams should perform an SCA analysis for all software they create, acquire, or consume, independent of origin or function (this includes commercial and open source software).”

The vulnerability’s origin story

Because these new CVEs only affect OpenSSL v3.0.0-3.0.6, there’s no known risk for earlier versions of OpenSSL. In other words, if you’re running v1.x, you’re currently not at risk based on what we know. OpenSSL 3.0 was released in September 2021, so you’re much more likely to be running an earlier version.

Because of its widespread adoption and valuable capabilities, OpenSSL 3.0.x is distributed and runs on every modern operating system. Because OpenSSL is open source, it may have been forked and run in unexpected circumstances.

OpenSSL’s technical explanation of the vulnerability states:

“A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address to overflow four attacker-controlled bytes on the stack. This buffer overflow could result in a crash (causing a denial of service) or potentially remote code execution.

"Many platforms implement stack overflow protections which would mitigate against the risk of remote code execution. The risk may be further mitigated based on stack layout for any given platform/compiler…

"In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects.”

Their blog post discusses the origin:

“The bugs were introduced as part of punycode decoding functionality (currently only used for processing email address name constraints in X.509 certificates). This code was first introduced in OpenSSL 3.0.0. OpenSSL 1.0.2, 1.1.1, and other earlier versions are not affected.”

Understand your software attack surface

Scanning individual containers in your infrastructure is only sustainable and realistic via automation. We highly recommend generating using an SCA scanner as part of your CI/CD pipeline. This way, any time new code is built and deployed in your organization’s infrastructure, SBOMs can be generated automatically and assessed.

RapidFort is the world’s first software attack surface management. We go beyond generating SBOMs and generate what we call a Real Bill of Materials (RBOM) so dev teams can see not only what’s in their workload, but what they’re actually using. Using the RBOM, teams can delete all the unused code within their containers and significantly reduce their known vulnerabilities.

In our experience, a majority of container code is open source and we regularly reduce attack surface up to 90% without affecting functionality. Most libraries and frameworks are included for small slices of functionality with the trade-off of bloat and OSS dependencies.

Running OpenSSL 3.0.x doesn’t indicate necessity for your workload. We can help you identify where it’s installed, where it’s used, and where it can be removed.

Our free tier scans containers, generates RBOMs, deletes unused code, and keeps your infrastructure safe and secure. Give it a try today and stay ahead of software vulnerabilities, whether from OpenSSL or any other vendor.

‍