Clearing the Fog Over the New OpenSSL Vulnerabilities

By Yotam Perkal and Ofri Ouzan, Rezilion Security Research

There has been a lot of tension building up since the announcement made by the OpenSSL project team last week (October 25th) regarding a security fix for a CRITICAL vulnerability in OpenSSL versions 3.x until today (November), when the information regarding the vulnerability has been made public.

In the official security advisory released today by the OpenSSL project team, two different vulnerabilities were announced, none of which is critical: CVE-2022-3602 and CVE-2022-3786.

According to the OpenSSL team, although in the pre-announcement, CVE-2022-3602 was categorized as CRITICAL, further analysis based on some of the mitigating factors available led this to be downgraded to HIGH.

In this blog post, we will provide some background information regarding both vulnerabilities, their impact, and recommended mitigation and remediation measures. 

Technical details regarding both vulnerabilities can be found at the bottom of this post.

What is OpenSSL?

OpenSSL is a commonly used library that provides cryptographic protocols and secure communications to applications over the internet. 

OpenSSL offers an open-source application of TLS and allows users to perform actions on SSL certificates.

Should You Be Worried?

The short answer is, yes you should be worried, CVE-2022-3602 is a severe vulnerability.

But, given the limited scope as well as high exploitation complexity the risk is significantly reduced. 

The longer answer is that the OpenSSL team announcement caused significant concern for several reasons.
First, this is only the second time that the OpenSSL project team classifies a vulnerability as critical. The previous time was Heartbleed (CVE-2014-0160) which enabled attackers to compromise sensitive information such as secrets and private keys that were meant to be protected by SSL/TLS.

Second, OpenSSL is extremely prevalent in modern compute environments.

The relatively long advance warning window provided by the OpenSSL project team has added to the speculations regarding the significance of this vulnerability.

That said, once the vulnerabilities were officially announced it seems the potential impact is less severe than anticipated for the following reasons:

   1.The potential scope – In this case, the scope seems relatively limited. Mainly due to the fact that the vulnerability only affects OpenSSL versions 3.x. 

Why is that significant?

Well, version 3.0 of OpenSSL was only released a year ago. In IT terms, it is considered a new library. Hence, not many software projects and applications have migrated to use it which makes it relatively rare to find in production systems.

For proportion, there are currently under 16,000 publicly accessible servers worldwide running potentially vulnerable versions of OpenSSL (3.X) while close to 240,000 servers are STILL vulnerable to Heartbleed 8 years after its initial discovery (see image below). 

Source: Shodan.io

   2.The complexity of exploitation – For the vulnerable versions, reaching the vulnerable code path isn’t straightforward. For example, an attacker would not only need to craft a malicious certificate but also need to have that malicious certificate signed by a trusted CA. For more details on the attack complexity, see the complete technical analysis of CVE-2022-3602 below. 

   3.Possible local mitigations – Even in the case an attacker is able to reach the vulnerable code path, there are several possible stack overflow protections that would mitigate against the risk of remote code execution which makes exploitation complexity higher in certain platforms/compilers. 

That said since attackers are creative and the vulnerability can potentially allow for remote code execution do not take it lightly. It is advised to identify all vulnerable instances of OpenSSL in your environment and patch them as soon as possible.  

Am I using an affected OpenSSL version?

First, there are several Linux OS distributions that come with OpenSSL 3.x out-of-the-box. For example (a more comprehensive list is available here):

Note that there is a possibility that your OS distribution does not come with OpenSSL 3.x by default yet it was actively installed at a late stage.

You can use the following command to check the OpenSSL version that is installed via package managers:

Linux
openssl version

MacOS

brew list –versions | grep openssl | grep "3.0"

There are cases however where OpenSSL can be embedded within a specific application:

• Via Dynamic compilation 
• Via static compilation 
• By adding the entire OpenSSL code (or one of its forks) to the application code before compiling it. In this case, the application will not necessarily be statically compiled yet it will still contain the vulnerable OpenSSL code (see Node.js example below).

In the last two cases, standard vulnerability scanners/SCA tools will not necessarily be able to identify the vulnerability since they mostly rely on package manager information in order to identify vulnerable software components (more on that here). In the described scenarios, the package manager will have no evidence of OpenSSL being installed. 

One such example is Node.js which since version 17.0.0 (including), comes with a built-in version of OpenSSL 3.0.x based on a fork of the original code.

Here it might be easier to simply examine the Node.js version itself using:

node --version

Vulnerable Containers

If you are running Docker containers in your environment, please refer to the DockerHub image vulnerability database which tracks vulnerable container images under DSA-2022-0001. 

Docker currently estimates that around 1,000 docker image repositories (Official Images and Verified Publisher Images) are potentially vulnerable.

Examples of potentially vulnerable containers include:

A full list of affected and unaffected software can be found in this link.

The list of affected applications is likely to grow in the next few days. We will provide updates in this blog post accordingly.

What isn’t vulnerable?

Do note that there are some projects that are simply wrappers around whatever OpenSSL version you have installed in your system and are not vulnerable to the CVEs themselves.
Examples include the Ruby openssl implementation and PyOpenSSL. 

So take into account that simply querying your package manager for anything containing the string `ssl` will create noise. 

Fixed Distributions

Remediation

Once you have identified the assets containing OpenSSL 3.x and therefore potentially vulnerable, it is advised to upgrade to version 3.0.7 of  OpenSSL as soon as possible.

Depending on your distribution this can be done using the following commands:

Debian, Ubuntu, and other Debian-Based Linux distributions

sudo apt-get update openssl

Red Hat, CentOs, Fedora, SUSE, Oracle and other RPM distributions

sudo yum update openssl

Mitigation

For cases in which patching isn’t possible, for example when the OpenSSL is part of commercial/vendor provided software and until that vendor issues a patched update, it is advised to make sure that the servers running that software are probably segmented to avoid propagation to the entire network.

Technical Details

Both vulnerabilities utilize a linear stack overflow, in which a fixed region of the memory on the stack is allocated to hold writable data, yet an attacker can cause the program to write past the allocation border, thus overwriting and corrupting data intended for a different purpose.

CVE-2022-3602 (OpenSSL Remote Code Execution vulnerability)

CVE-2022-3602 is a stack overflow vulnerability that occurs during the parsing of a X.509 TLS certificate post-validation. The vulnerability is caused due to a problem with the processing of Punycode while checking certificates. An attacker can potentially exploit this vulnerability by crafting a malicious certificate containing punycode in the domain of the email address field.

Then, the attacker has to have that certificate signed by a trusted CA. Once the client will try to verify the certificate chain it could possibly trigger a crash. Although the attacker can only control the content of 4 bytes, there are (hard to implement) exploitation scenarios in which this crash can lead to arbitrary code execution. It is important to mention that in the case in which even basic anti-exploitation protection mechanisms are enabled during compilation (such as stack canaries for example), exploitation will only corrupt a designated special guarded value that will cause the program to abort, reducing the impact of the vulnerability to potential denial of service and not remote code execution.

CVE-2022-3786 (OpenSSL Denial of Service vulnerability)

CVE-2022-3786 differs from CVE-2022-3602 by the fact that it does not allow the attacker to control the content of the overflow which in this case is limited to the period character (`.`).

In this case, an attacker still needs to craft a malicious email address in a certificate signed by a trusted CA in order to overflow an arbitrary number of bytes containing the `.’ character on the stack. This buffer overflow could result in a crash which can result in a denial of service.

Conclusion

Taking all factors into account, it appears that exploitation of these vulnerabilities in the wild to achieve code execution is not highly likely.

That said, exploitation is possible and hence it is advised to identify and patch vulnerable assets as soon as possible. 

As new information surfaces, we will continue to update this blog post.

Rezilion Can Help. Already a customer?

Check your environment by going to https://app.rezilion.com/inventory/packages and entering a filter such as the following:

New to Rezilion?

Receive a free OpenSSL assessment today at https://www.rezilion.com/lp/openssl-flaw-know-if-youre-at-risk-and-take-action/ to know your risk and develop an action plan.