Quick Links
**Updates**
2022-11-01
Details of two high-severity vulnerabilities patched in OpenSSL version 3.0.7 are now available (CVE-2022-3786, CVE-2022-3602). Both are buffer overflows in the X.509 certificate verification process, “specifically in name constraint checking.”
The first, CVE-2022-3786, allows a threat actor to “craft a malicious email address in a certificate to overflow an arbitrary number of bytes containing the `.` character.” The second, CVE-2022-3602, is similar, but in this case, a threat actor could “craft a malicious email to overflow four attacker-controlled bytes on the stack.” These could result in a denial of service or remote code execution.
While both OpenSSL servers and clients are vulnerable to this attack, it is more likely that an attacker will exploit a client than a client exploiting a server. But in servers configured with bi-directional authentication where both sides of the connection exchange and verify certificates, it is possible that a client could exploit a server by sending a malicious or malformed certificate.
And while this type of setup is rare, it’s not out of the question. But even with a successful attack, many other variables, such as anti-buffer-overflow systems like stack canaries and ASLR (Address Space Layout Randomization), come into the picture to thwart exploitation.
Because of this complexity and system safeguards, OpenSSL developers reduced the criticality of the CVE from CRITICAL to HIGH.
If you’re running OpenSSL versions 3.0.0-3.0.6, we recommend upgrading to the newest release of OpenSSL (currently 3.0.7) to protect you from potential attacks.
Introduction
OpenSSL is a software library that allows applications to communicate securely with other networked applications using a wide variety of cryptographic features. This library is widely deployed on the Internet and is a critical part of many organizations’ infrastructure. With that in mind, the OpenSSL team warned all users that a critical vulnerability had been identified in the OpenSSL codebase last Tuesday. This is quite a big deal, as the last time we had a bug of this criticality was back in 2014 with the now infamous Heartbleed vulnerability (CVE-2014-0160), which still haunts us today.
While we don’t have specific details about this vulnerability, multiple sources have claimed that the vulnerability only affects OpenSSL version 3.0.0 and above (software that uses OpenSSL 1.0.2 or 1.1.1 are not affected). The 3.x tree is a relatively new addition to the OpenSSL lineup, which was released in September 2021. Given that this version has only been out for a short time, widespread adoption seems to have been minimal. But, once this vulnerability has been publicly disclosed and new releases go live, administrators running version 3.0.0 or above should immediately upgrade to the fixed version of 3.0.7.
Identifying Vulnerable Versions of OpenSSL
Determining whether a host is vulnerable to this unreleased bug is still hazy as we do not have all the details. But, we can look at services on the Internet that advertise what specific version of OpenSSL they are running to get a general idea of what will be vulnerable. We are currently unaware of any technique outside of checking HTTP headers to determine the exact version of OpenSSL being used, but we are still investigating alternatives. This means that while we can see many potentially vulnerable servers, we do not have insight into them all, and the statistics in this post are the lower bounds of what exists.
Luckily, some Internet servers, such as Apache, will offer information that gives us insight into what specific versions of OpenSSL are being used. For example, in the following output, we see that Apache has added all of its loaded modules into the output of the “Server” header. One is the version of OpenSSL that the mod_ssl module was compiled against:
