OpenSSL Project released OpenSSL version 3.0.7 on November 1st, 2022 to address specific vulnerabilities (CVE-2022-3786 and CVE-2022-3602) that had been largely unknown until today.
The new version will fix these High severity vulnerabilities in the library affecting OpenSSL versions 3.0.0 and above, as well as any application with an embedded, impacted OpenSSL library.
An important thing to note is that this is only the second time since 2014 that OpenSSL has categorized an issue/vulnerability as Critical, but then it was changed to High.
Let’s dive into the details and understand how it impacts us.
What is OpenSSL?
OpenSSL is a cryptographic library that offers an open-source application of the TLS protocol used for encrypting communications on the Internet. First released in 1998, it is available for Linux, Windows, macOS, and BSD systems and is widely used by Internet servers, including most HTTPS websites, for secure communication. OpenSSL allows users to perform various SSL-related tasks, including CSR (Certificate Signing Request), private keys generation, and SSL certificate installation.
Are you vulnerable?
You should consider yourself vulnerable if you use any of the OpenSSL versions ranging from Open SSL ‘3.0.0’ to ‘3.0.6’.
Below are examples of how SentinelOne alerts its users for these vulnerabilities.
Which known applications are vulnerable?
- Redhat Enterprise Linux 9
- Ubuntu 22.04+
- CentOS Stream9
- Kali 2022.3
- Debian 12
- Fedora 36
- Node JS 18.X and 19.X
If you are not using these Linux distributions, it doesn’t mean you are not affected. We advise you to verify the recommended steps mentioned in this article.
About the vulnerabilities
These vulnerabilities would likely result in the disclosure of server memory, potentially reveal user details, and potentially exploit it remotely to compromise server private keys or execute remote code.
If you follow OpenSSL, the last time it released a Critical patch was for HeartBleed (CVE-2014–0160) in 2014. This vulnerability exposed sensitive information, such as secrets and private keys, that were SSL/TLS protected. It impacted hundreds of thousands of public web servers that subsequently took months to be secured. CVEs for this OpenSSL vulnerability are CVE-2022–3786 and CVE-2022–3602.
CVE-2022–3786
This CVE can be exploited by a buffer overrun that 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 a malicious certificate or for an application to continue certificate verification despite failure to construct a path to a trusted issuer.
An attacker can craft a malicious email address in a certificate to overflow an arbitrary number of bytes containing the “.” character (decimal 46) on the stack. This buffer overflow could result in a crash (causing a denial of service). 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.
CVE-2022–3602
This CVE can be exploited by a buffer overrun 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 the risk of remote code execution.
In addition, the risk may be further mitigated based on the stack layout for any given platform/compiler. Pre-announcements of CVE-2022–3602 described this issue as CRITICAL. Further analysis based on some of the mitigating factors described above has led this to be downgraded to HIGH.
SentinelOne Research — How many organizations are exposed?
To gauge the possible impact of this vulnerability, we analyzed over 100K assets across major CSPs (AWS, GCP, Azure). However, we have found that only 2.54% of these assets use the vulnerable OpenSSL version (3.0.0–3.0.6). Although exposure to this vulnerability seems low, its impact is critical and should be addressed immediately.
Actions you need to take to fix this vulnerability
- Identify — Run the below commands to identify the vulnerable assets across your infrastructure
- For node packages
node -e “console.log(process.versions)” | grep openssl- For Server Packages
sudo dpkg -S /usr/lib/x86_64-linux-gnu/libssl.so.3- For docker images refer to https://github.com/docker/index-cli-plugin
Usage: docker-index cve — image <IMAGE> DSA-2022–00012. Prioritize
- External Assets accessible on the Internet
- Business critical assets having sensitive data, secrets, production services, etc.
- Assets that have access to other critical resources with sensitive production data hosted on Intranet
3. Execute
- Update machines to OpenSSL version 3.0.7 as quickly as possible post-November 1st.
- Ensure third-party applications exposed to this vulnerability are patched.
- Isolate machines from the Internet entirely until you can update the OpenSSL package on that system.
- Communicate with support teams for any adverse impact during the update phase.
- Be prepared to respond to your customers (if applicable) about what you are doing to identify and mitigate this risk.
Additionally, you can follow OpenSSL Project for future updates related to this vulnerability to ensure that you stay updated with the latest security information.
