All You Need To Know About 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 .

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.
• Impact:
  • 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

CVE-2022-3602

• 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.

CVE-2022-3786

• 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

OS level

To see what version you have at the OS level, just type:

openssl version

Application level

At the application level, it can be more difficult to detect what you’re using. There are 2 situations:

• Applications 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 bash strings command (Linux) or SysInternals Strings (Windows).

See the OpenSSL advisory here.