Vulnerability Management

Everything You Need To Know About OpenSSL Vulnerabilities

OpenSSL Project released OpenSSL version 3.0.7 on Nov 1st, 2022 to address specific vulnerabilities that had been largely unknown until today.

Shivankar Singh

Written by Shivankar Singh

November 2, 2022 | 4 min read

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 PingSafe 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.

PingSafe 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

  1. 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
Usage: docker-index cve — image <IMAGE> DSA-2022–0001

2. 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.

How PingSafe can help you to detect the Vulnerable OpenSSL

  • PingSafe scans your docker images from the registry to identify the dependency on the vulnerable package (visible under Container Security).
  • PingSafe will check for signatures of publicly accessible hosts, which might expose your OpenSSL version, to help you prioritize the issue.
  • PingSafe also easily identifies assets containing vulnerable OpenSSL Library by scanning your compute resources on the cloud and detecting the vulnerable packages installed. Detected vulnerable assets will appear under the Vulnerability Management section of the platform.

We will keep updating this article with the latest updates on these vulnerabilities.

To know more about PingSafe’s all-in-one cloud security platform, visit https://www.pingsafe.com/.