All you need to know about OpenSSL 3.0.7 / CVE-2022-3602 / CVE-2022-3786
The OpenSSL organization finally released version 3.0.7 of its famous cryptographic library. The InfoSec community waited for this release for a week, as OpenSSL gave organizations a head-start by announcing the patching of a Critical security vulnerability.
Now we finally have more details. This article attempts to summarize everything that you need to know about CVE-2022-3602 and CVE-2022-3786 .
Common to CVE-2022-3602 & CVE-2022-3786
Both vulnerabilities are buffer overruns that can be triggered during X.509 certificate verification, specifically in name constraint checking of the certificate email field.
Issues happen after certificate chain signature verification. So exploitation requires either a CA to have signed a malicious certificate or for an application to continue certificate verification despite failure to construct a path to a trusted issuer.
Severity: High (3602 was downgraded from the initial Critical severity).
Both vulnerabilities can be triggered in:
a TLS client (when the server is malicious).
To exploit a TLS client you would have to make a user or application connect to a malicious TLS server that sends over a crafted certificate.
a TLS server (when using mutual TLS and the client is malicious).
To exploit a TLS server you would have to configure the TLS client to use a crafted certificate. Fortunately, mutual TLS is not used that frequently in the web context.
OpenSSL versions 3.0.0 to 3.0.6 are vulnerable to both issues.
OpenSSL 1.1.1 and 1.0.2 are not affected.
Mitigation: OpenSSL 3.0 users should upgrade to OpenSSL 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) or potentially remote code execution.
Many platforms implement stack overflow protections which would mitigate against the risk of remote code execution. The risk may be further mitigated based on stack layout for any given platform/compiler.
Exploitation could be easier on platforms that don’t use memory mitigations such as ASLR or DEP/NX.
No public exploit exists at the time.
An attacker can craft a malicious email address in a certificate to overflow an arbitrary number of bytes containing the ‘.’ character (decimal 46) on the stack.
This buffer overflow could result in a crash (causing a denial of service).
Detecting what version of OpenSSL you have
To see what version you have at the OS level, just type: openssl version
At the application level, it can be more difficult to detect what you’re using. There are 2 situations:
Apps that ship OpenSSL as a set of libraries (dynamically linked) – these can be either .so (Linux) or .dll (Windows). These are usually called libcrypto (handles cryptographic algorithms like RSA, AES, etc) and libssl (handles TLS implementations).
Apps that embed OpenSSL (statically linked) – in this case, libraries are embedded into the main executable and it’s more difficult to detect. A possible way is to search/grep for the “OpenSSL” string using “strings” (Linux) or SysInternals Strings (Windows).
OSCE3, OSEP, OSED, OSWE, OSCP certified. Over 10 years of experience in the IT industry, now working in Product Security and leading a Red Team. Huge Offensive Security and CTF nerd. I enjoy music, teaching and hiking.