What You Should Know about the New OpenSSL Vulnerability

How to detect which OpenSSL version you’re running and if your organization is exposed to the critical OpenSSL vulnerabilities - CVE-2022-3602 (Remote Code Execution) and CVE-2022-3786 (Denial of Service) - and what to do about it.

The OpenSSL Project published a security advisory on November 1, 2022, detailing a high-severity vulnerability in OpenSSL. OpenSSL Project explains it in change - log version 3.0.7:

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, CVE-2022-3786) or potentially remote code execution depending on stack layout for any given platform/compiler (CVE-2022-3602).

Despite what was initially thought, the vulnerability is most likely not of Heartbleed/Log4j type. Remote code execution (RCE) vulnerabilities are unlikely to be widely exploited since clients and servers must be configured to verify malicious emails within certificates. In addition, certain conditions must be met to exploit the RCE vulnerability. Namely, the malicious code must already be present on the victim's system for the attacker to be able to execute it as part of an RCE attack. The severity of the Common Vulnerabilities and Exposures (CVE) was downgraded from critical to high.

We still recommend that you investigate if your organization has vulnerable versions of OpenSSL and update the library accordingly.

How to detect if you are vulnerable

As shown above, OpenSSL can be used in multiple places in your organization. We’ve created a list of 5 methods to detect which OpenSSL version you are using and determine if you are exposed to the vulnerability:

1. OpenSSL version command

The command allows you to determine the version your system is currently using. Based on that, you can tell if the version is 3.0.*.

ubuntu@ubuntu:~$ openssl version
OpenSSL 1.1.1n 15 Mar 2022

2. Linux package managers

Amazon Linux:

repoquery --all --pkgnarrow=installed --qf="%{NAME} %{VERSION} %{RELEASE}" | grep openssl

OR

rpm -qa --queryformat "%{NAME} %{VERSION} %{RELEASE}\n" | grep openssl

Debian & Ubuntu:

dpkg-query -W -f="\${Package},\${Version}\n" | grep openssl

RHEL, Fedora, Oracle, CentOS:

rpm -qa --queryformat "%{NAME} %{VERSION} %{RELEASE}\n" | grep openssl

3. Docker image vulnerability database

The Docker image vulnerability database can help you find vulnerable Docker images. For now, the placeholder is dubbed “DSA-2022-0001.”

4. Vulnerability scanning for docker local images

apt-get update && apt-get install docker-scan-plugin

The docker scan command allows you to scan existing Docker images using the image name or ID. For example, run the following command to scan the hello-world image:

docker scan hello-world

5. Trivy

sudo trivy image --format spdx oraclelinux:9 | grep -i -C 4 openssl

Impact of the vulnerability

According to the announcement, the vulnerability affects only newer versions of OpenSSL V3.0 and higher. It is hard to predict the potential damage and risk of this vulnerability to the organization. What we do know is that, despite being the most recent version of OpenSSL, which was released one year ago, OpenSSL V3.0 is far less ubiquitous than OpenSSL V1.0.

We can split the impact into different categories: OS distributions, containers, web applications and any other application that uses an embedded OpenSSL library.

OpenSSL V3.0 has been incorporated into Linux operating systems such as Ubuntu 22.04 LTS, MacOS Ventura, Fedora 36 and others. It should be noted, however, that most of these Linux distributions only include OpenSSL 3.0 and above in their most recent releases of the OS applications. These versions are considered testing versions so may not be widely used in production systems. If you develop proprietary software in your organization, you should also check if your code uses the vulnerable OpenSSL version.

In addition, many Docker Official images still use OpenSSL V1.x and are not affected. The Docker Official container images for popular projects like Redis and httpd are unaffected. On the other hand, NodeJS’s latest version is vulnerable.

In terms of web applications, the adoption of OpenSSL V3.0 is very slow. Running a query in Shodan, we found approximately 14,000 devices running OpenSSL V3.0.0 as opposed to 770,000 running OpenSSL V1.1.1. According to this survey, OpenSSL V3.0 is adopted by less than 0.2% of websites worldwide, in comparison to more than 75% of V1.

We see that the adoption of OpenSSL V3.0 and above is still very low. Nonetheless, you should still check if you have entities with the vulnerable version in your organization.

Vulnerable OS versions

Based on our research, we've compiled a list of the most popular OS distributions and versions that contain the vulnerable OpenSSL version.

view raw  VulnerableDistros|OpenSSL.csv hosted with ❤ by GitHub

How Tenable Cloud Security can help

We can help you detect assets that have a vulnerable OpenSSL version and remediate the vulnerability to avoid crises and get the best visibility for your organization.

If you need help in understanding your OpenSSL status or how it affects your security profile, contact us.