OpenSSL 3.0 Vulnerabilities: CVE 2022-3786 and CVE 2022-3602

By Trellix and Sam Quinn · November 1, 2022
This story was also written by Charles McFarland and Philippe Laulheret.

What is it?

CVE-2022-3786 and CVE-2022-3602 are buffer overflow vulnerabilities affecting OpenSSL 3.0 and above that were fixed on November 1st with the release of OpenSSL 3.0.7. The official advisory can be found here. It rates these two vulnerabilities as High severity.

Both vulnerabilities are the result of improper handling of maliciously crafted email addresses while verifying X.509 certificates. According to the advisory, CVE-2022-3786 can result in a Denial of Service (DoS) while CVE-2022-3602 can result in either a DoS or a potentially a Remote Code Execution (RCE) by overwriting 4 attacker-controlled bytes onto the stack.

Who is affected?

OpenSSL is a library that comes pre-installed with a wide variety of Linux distributions, Docker containers, node.js packages, and similar software. Although creating an exhaustive list of all the vulnerable installations is impossible, some resources enumerating the main distributions that could be affected can be found here (Dutch NCSC), here (Distro Watch), here (Docker advisory), and here (Node.js Advisory). As OpenSSL 3.0 is still fairly new (first released on September 7, 2021), most Linux distribution have only been shipping it in their dev/bleeding edge releases (e.g. Debian “testing” Bookworm) or potentially their last stable release (e.g. Ubuntu 22.04 and 22.10). Furthermore, Node.js 18.x and 19.x use OpenSSL 3.0 while the previous versions, Node.js 14.x and 16.x, do not.

Native applications can also ship with their own version of OpenSSL that can be found by searching for:

• libeay32.dll or ssleay32.dll on Windows
• libcrypto.dylib, libssl.dylib on MacOS
• On Linux you can also search for libcrypto.co.x.y and libssl.so.x.y (with x and y the version number), but in this case the libraries will likely be installed in a shared library folder (e.g. /usr/lib/x86_64-linux-gnu)

The case of FIPS 140-2 compliant software

FIPS 140-2 is a set of standards and verification processes created by NIST to validate cryptography modules. This compliance is mandatory for U.S. and Canadian government procurements and may also be required by other global organizations. As such, another factor that may become important is that the OpenSSL FIPS Object Module 3.0 is only compatible with OpenSSL 3.0. Its predecessor, the OpenSSL FIPS Object Module 2.0 that was compatible with older version of OpenSSL, was made end-of-life in January 2022. This means that software that needs to be FIPS 140-2 compliant has likely moved to the newer version of OpenSSL and put previous versions on their “historical list.” Since the FIPS 140-2 compliance—needed for government procurements—is now only attainable via OpenSSL 3.0, it stands to reason that we might see higher adoptions of it in critical contexts (read: government contracts) in the near future.

Deployment statistics

Akamai ran a study on some of their managed networks (but did not mention their sample size) where half of them had at least one machine using a version of OpenSSL vulnerable to CVE-2022-3786 and CVE-2022-3602. This doesn’t necessarily mean OpenSSL was used in a vulnerable/impactful scenario. This high ratio can be put into perspective per these Shodan statistics showing that a mere 16,000 servers are publicly using a vulnerable version of OpenSSL, while 240k are still vulnerable to Heartbleed. Finally, this number is dwarfed by over 2.1m servers still using OpenSSL 1.x (per this Shodan query).

Trellix customers

If you are a current Trellix customer, please refer to this updated Knowledge Base article (KB for FireEye products) to find out which of our products are affected and stay tuned for our Trellix Defenders blog for further information about detection and mitigation.

Is it the next Heartbleed?

No. The severity of CVE-2022-3602 was downgraded from Critical to High and CVE-2022-3786 was never considered Critical. Heartbleed (the only Critical vulnerability having ever affected OpenSSL) is easy to exploit and can leak sensitive information and server memory. CVE-2022-3602 and CVE-2022-3786 are memory corruption vulnerabilities, and in most if not all relevant use cases, modern security mitigations strongly decrease the likelihood of these vulnerabilities being exploited in an impactful way (discussed further in the following section). This is what lead to the decrease in severity rating according to the OpenSSL blog post. This being said, CVE-2022-3602 and CVE-2022-3786 are still High severity vulnerabilities and it is a good idea to upgrade to the latest version of OpenSSL sooner than later.

Technical Details

Both vulnerabilities patched in OpenSSL version 3.0.7 are buffer overflows. The change log between 3.0.6 and 3.0.7 (Figure 1) by Paul Dale, a developer for OpenSSL, brings light to these issues.

CVE-2022-3602

As seen in the announcement, both issues are classic buffer overflows. CVE-2022-3602, described as Critical in the pre-release announcement, later downgraded to High severity allows an attacker to control 4 bytes. The buffer is overrun when an attacker supplies a certificate with a malicious email address field. The problem with this is that the malicious certificate containing the email address intended to exploit this vulnerability must first be signed by a certificate authority (CA). Meaning the attacker would first have to social engineer their malicious certificate to be signed beforehand or hope that the server continues processing invalid certificates without having a trust chain leading back to a trusted issuer.

This vulnerability’s patch is an excellent example of how simple coding mistakes can have much greater impacts. As you can see in Figure 2 that the patch to this vulnerability was simply adding an “=” to the “>” operator effectively eliminating the off by one issue.

In the disclosure announcement and after the downgrade of severity there are two mitigating factors working against any attacker who wishes to take advantage of this vulnerability. With the current state of this vulnerability, it was stated that “We are not aware of any working exploit that could lead to code execution, and we have no evidence of this issue being exploited as of the time of release of this advisory (November 1st, 2022).” Furthermore, stack protections such as stack canaries and other stack-based buffer overflow protections are often enabled by default, further limiting the impact of this vulnerability.

CVE-2022-3786

This is another buffer overflow vulnerability but with a unique quality that allows an attacker to overwrite an arbitrary number of bytes with ONLY the “.” (period) character. While having the ability to write arbitrary number of bytes can benefit an attacker greatly, only being able to write the value of 46 into memory would be less than useful. Furthermore, this vulnerability is also limited by the same constraints as CVE-2022-3602, meaning that the malicious certificate crafted to exploit this vulnerability must be signed by a CA or the server must ignore the errors of the invalid trust chain.

While the fix for CVE-2022-3786 is not as simple as adding the “=” sign like in the previous vulnerability, OpenSSL developers were able to fix the issue by correcting the logic used to parse out the email address.

One thing to note about both vulnerabilities is that they can be triggered either by a malicious client when a server is authenticating user supplied certificates, or by a malicious server and having a victim connect. If an attacker successfully bypasses all preexisting mitigations, the result of both vulnerabilities would result in a DoS and potentially even RCE for CVE-2022-3602.

Conclusion

While CVE-2022-3602’s original critical rating was a source of concern, it has now been downgraded to High severity, making it stand out less among past OpenSSL vulnerabilities. It’s also important to keep in mind that only versions 3.0 and above of OpenSSL are affected, which is only a fraction of the total user base of OpenSSL. Furthermore, at the time of writing there is no known exploitation in the wild of the vulnerability. Don’t panic and, as usual, make sure to identify your exposure through your OS, internal use of the vulnerable library and third-party software, and update these quickly. Trellix will keep monitoring the situation and update this post if anything new emerges.