Everything you need to know about the new OpenSSL vulnerabilities (CVE-2022-3602 & CVE-2022-3786)
- Article tags
Before securing systems, we need to understand what we’re trying to secure and how to do it. Today we are exploring two new vulnerabilities that got the community's attention this month.
Most importantly you will learn how to patch them and how impactful they are.
When you know it’s coming
On November 1st, 2022, the OpenSSL team released an advisory detailing two high-severity vulnerabilities, CVE-2022-3602 and CVE-2022-3786.
CVE-2022-3602 was pre-announced as a critical bug but later downgraded to high, causing waves of hate from the community. It’s important to remember that CVE-2022-3602 was reported in private by Polar Bear on October 17 and, one day later, Viktor Dukhovni reported CVE-2022-3786.
This is the first issue to reach this level of severity since the famous Heartbleed vulnerability (CVE-2014-0160).
In this post, we’ll break down the two new OpenSSL vulnerabilities but we’ll focus on the technical details of CVE-2022-3602.
What is OpenSSL and how is it used?
The OpenSSL library is employed for cryptographic functions, particularly in the context of network connections.
For instance, web servers frequently use OpenSSL to create connections that are encrypted. OpenSSL is also used by mail servers and VPN technologies like OpenVPN to create secure communication channels. A wide range of products, including network devices, embedded systems, and container images, include the library.
OpenSSL has three main components:
libcrypto - a cryptographic library with the implementation of many protocols
libssl- a library implementing all TLS protocols up to TLSv1.3
OpenSSL- a command line utility for various operations (ex. generating certificates)
What are these vulnerabilities?
These vulnerabilities are memory corruption issues, also known as buffer overrun/overflow, in which attackers may be able to execute arbitrary code on a victim’s machine and take it over.
CVE-2022-3786
X.509 Email Address Variable Length Buffer Overflow
The vulnerability resides in the parsing of a TLS certificate after validation. This results in a four-byte overflow on the stack. An attacker can create a malicious email address in a certificate to overflow a number of bytes containing the ‘.’ (decimal 46) character on the stack.
CVE-2022-3602
X.509 Email Address 4-byte Buffer Overflow
CVE-2022-3602 is caused after the parsing of a TLS certificate. The difference is that the vulnerability occurs after the name constraint check. It helps to note that a trusted CA would need to sign a malicious certificate in order to succeed.
Statistics, or how we can understand the threat level
So how big is the problem?
Clearly, we don’t have a new version of Heartbleed. The below examples demonstrate how less instances are affected compared to Heartbleed. We collected data about instances that run vulnerable versions of OpenSSL from Shodan.
As you can see, there are around 550.000 instances running vulnerable OpenSSL versions. It’s important to note that not all those instances are actually vulnerable because important factors such as stack layout and protections play a major role.
Most of them are using OpenSSL 3.0.0 where the punycode decode function was first introduced.
The latest OpenSSL versions are included in the most recent releases of multiple popular Linux distributions, such as Redhat Enterprise Linux 9, Ubuntu 22.04+, CentOS Stream9, Kali 2022.3, Debian 12, and Fedora 36.
Docker also estimates that about 1,000 image repositories could be impacted across various Docker Official Images and Docker Verified Publisher images.
Akamai did a study on their infrastructure where they found out that approximately 50% of monitored environments had at least one machine with at least one process that depends on a vulnerable version of OpenSSL. Of those networks, the percentage of machines in the network that had some dependence on a vulnerable OpenSSL version ranged from 0.2% to 33%.
The security community has a lot of work on its hands for the next couple of months. (Why does this always happen at the end of the year?)
Deep dive into CVE-2022-3602
In addition to a Denial of Service(DoS), this CVE can lead to RCE. Let’s understand how this vulnerability works in detail. For this, we have to unpack where this all started.
Ok, but where’s the developers’ mistake that led to this?
Programmers have a joke that goes like “If the code works, don’t touch it!”, except this time we apply this in a security context. The developers from OpenSSL introduced in OpenSSL 3.0.0 a new function called ossl_punycode_decode that provides decoding functionality of punycode domain names.
Now, you may wonder what punycode is and how it’s causing such a high-risk vulnerability.
Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA). It uniquely and reversibly transforms a Unicode string into an ASCII string.
Computers convert IDNA domains into Punycode domains. Within OpenSSL, osslpunycodedecode takes a string buffer of a punycode domain and converts it to Unicode for additional processing.
Since this vulnerability is a buffer overflow, somewhere, data exceeds the buffer and leads to overwriting adjacent memory locations.
In CVE-2022-3602, this happens during the X.509 certificate verification. This coding vulnerability appears in the osslpunycodedecode function, where it’s used to convert Punycode domains to Unicode.
This coding vulnerability allows remote attackers to execute code on the machine using a signed malicious TLS certificate.
You can see the repository with the vulnerable function here.
Even if an attacker succeeds in overcoming every other challenge, they are only able to write one 4-byte item to the stack. Four bytes used to frequently be sufficient to replace a return pointer on a stack and execute arbitrary code back in the day, but not today. This it’s because protections such as ASLR and Canaries will easily stop this attack.
How can I know if I’m vulnerable?
There are several ways you can find out if your instance is using a vulnerable version. You need to know first that only OpenSSL 3.0.0-3.0.6 versions are vulnerable to these CVEs. Let’s go through all the methods and detect those vulnerable versions.
If you want to manually check your machine/s, you will need to go through a series of steps to detect what OpenSSL version is running.
System
Typing the following in a Linux operating system will show us the OpenSSL version used on the system. If the version is between 3.0.0-3.0.6, you are at risk and should update immediately.
openssl version
Dynamically Linked
Next up, we need to dig deeper and look for dynamically loaded processes. We’ll do that using the lsof command.
lsof | grep libssl.so.3
We also found these scripts to be useful in detection
Linux & *Nix Scanner (Bash Script): https://github.com/MalwareTech/SpookySSLTools/blob/main/openssl_scan.sh
Windows scanner (PowerShell): https://github.com/MalwareTech/SpookySSLTools/blob/main/openssl_scan.ps1
Source: malwaretech.com
Statically Linked Software
Now comes the hardest part, for statically compiled software lsof will not detect the OpenSSL versions and neither those scripts. That’s why for statically compiled software we’ll need to use the readelf command.
readelf -a [binary] | grep -i osslpunycodedecode
Another method we found useful is applying the below regex directly on the binary:
Unix-like: strings /path/to/executable | grep “^OpenSSL\s*[0-9].[0-9].[0-9]”
Windows: select-string -Path C:\path\to\executable.exe -Pattern “OpenSSL\s*[0-9].[0-9].[0-9]” -AllMatches | % { $.Matches } | % { $.Value }
Source: malwaretech.com
I am vulnerable, what should I do now?
The good part is that it’s very easy to patch your system. You can easily mitigate the threat by updating the OpenSSL version.
Follow these steps to update your OpenSSL version to 3.0.7
chmod +x openssl-3.0.7.tar.gz
tar -zxf openssl-3.0.7.tar.gz
cd openssl-3.0.7/
./config
sudo apt install make gcc
sudo make
sudo make test
sudo mv /usr/bin/openssl ~/tmp
sudo make install
sudo ldconfig /usr/local/lib64/
sudo ln -s /usr/local/bin/openssl /usr/bin/openssl
sudo ldconfig
After all these commands we get the OpenSSL 3.0.7 version and we are now one step in front of the attackers.
Exploitation prerequisites
Now that we learned how to patch our system, let’s see the conditions that we need for a successful attack. There are two important conditions for a successful attack to take place.
First and most important, the attack relies either on a Certificate Authority (CA) to sign the malicious certificate or the user to skip the warnings and the application to not properly check the certificate.
Then, the stack layouts and protections appear. If the first condition fails, these two factors can easily make the threat disappear.
Given the above, plus the fact that these attacks are complex and hard to achieve, we believe that gaining Remote Code Execution(RCE) with CVE-2022-3602 is very hard to pull off.
How concerned should you be?
Thanks to open-minded individuals that worked to make security better, we now have protections (ASLR, NX stack, stack cookies) that make exploitation of stack overflows very complex and difficult to achieve. Also, given that this vulnerability is pretty much client-side, you can expect to get warnings. So these CVEs are perfect for users who click “yes” on everything without reading first.
To answer the question, you should not neglect it and think that it’s too hard for an attacker to exploit these CVEs. You should do a security update to OpenSSL 3.0.7 as soon as you can.
FAQ
Q: Are all OpenSSL versions vulnerable to these vulnerabilities?
A: No, the bugs were introduced as part of Punycode decoding functionality (currently only used for processing email address name constraints in X.509 certificates). This code was first introduced in OpenSSL 3.0.0. OpenSSL 1.0.2, 1.1.1, and other earlier versions are not affected.
Q: Do I need to replace my TLS server certificates?
A: No.
Q: Are these vulnerabilities the same as Heartbleed?
A: No, due to the prerequisite that a client or server must be configured to verify a malicious email address within a certificate.
Q: Was it possible to prevent these vulnerabilities earlier?
A: The answer is YES. This vulnerability could have been found earlier with a little bit of fuzzing.
Q: What is the CVSS score for these vulnerabilities?
A: Both CVEs have been assigned a CVSS score of 7.5 (High).
Conclusion
Many people from the cybersecurity community criticized the way OpenSSL handled the announcement and remediation of these vulnerabilities. They put some stress on people by announcing it as CRITICAL and downgrading later to HIGH.
Maybe it would have been nice to get a heads-up about the downgrade, but, when you have a small security team that needs to triage and analyze until the last moment, it's not easy.
We have to appreciate their effort to make this public and that we didn't encounter a scenario where the vulnerability gets upgraded at the last moment.
This pre-announcement has given companies time to prepare for the worst and map their critical assets for a quick fix.
