Discussion thread: https://updatedsecurity.com/topic/9-openssl-vulnerability-cve-2022-3602-cve-2022-3786/

Vulnerability Details

From https://www.openssl.org/news/secadv/20221101.txt

Severity: High

A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer. 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.

Pre-announcements of CVE-2022-3602 described this issue as CRITICAL. Further analysis based on some of the mitigating factors described above have led this to be downgraded to HIGH. Users are still encouraged to upgrade to a new version as soon as possible.

In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects.

OpenSSL versions 3.0.0 to 3.0.6 are vulnerable to this issue.

OpenSSL 3.0 users should upgrade to OpenSSL 3.0.7.

OpenSSL 1.1.1 and 1.0.2 are not affected by this issue.

This issue was reported to OpenSSL on 17th October 2022 by Polar Bear. The fixes were developed by Dr Paul Dale.

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

X.509 Email Address Variable Length Buffer Overflow (CVE-2022-3786)

The vulnerability is a buffer overflow in the X.509 certificate verification, which is the code used to validate TLS certificates. The vulnerability could potentially be exploited to allow remote code execution via a malicious TLS certificate; however, it requires that the malicious TLS certificate be signed by a trusted CA.

Since certificate verification is typically done on the client side, this vulnerability primarily affects clients not servers. There is a case where servers could be exploited via TLS Client Authentication, which may bypass the CA signing requirements as client certs are usually not required to be signed by a trusted CA. Since client authentication is rare ,and most servers do not have it enabled, server exploitation should be low risk.

Attackers could exploit this vulnerability by directing client to a malicious TLS server which uses a specially crafted certificate to trigger the vulnerability.

Likelihood of exploitation

Give the fact the vulnerability is primarily client-side, requires the malicious certificate to be signed by a trusted CA (or the user to ignore the warning), and is complex to exploit, I estimate a low chance of seeing in-the-wild exploitation.

Affected Systems

Important Note: OpenSSL 3 is not the same as SSLv3. This vulnerability exists only in OpenSSL Version 3 and not SSLv3.

The vulnerability affects only OpenSSL version 3.0.0 to 3.0.6, with the patch being shipped in version 3.0.7. Due to the fact OpenSSL 3.0.0 was released in September 2021, it is far less widespread than previous versions. Given the very recent release date, older appliances with hardcoded OpenSSL version are unlikely to be vulnerable.

NCSC-NL has a helpful list of confirmed affected/unaffected software here: https://github.com/NCSC-NL/OpenSSL-2022/tree/main/software

Detecting OpenSSL Version

There are several ways a system can use OpenSSL; I’ll explain each of them below and specific remedies.

System

The system may have OpenSSL installed, which can be executed by running the command ‘openssl’

How to check the version run the command: ‘openssl version’ (without quotes)

Dynamically Linked

Most software will ship with OpenSSL code contained within a library (a DLL file on Windows, or SO file on Linux).

How To check the version OpenSSL library are typically named libcrypto.so or libssl.so on Linux, and libcrypto.dll or libssl.dll on Windows. The filename may sometimes contain the version number at the end, but this is not always the case. The best method is to extract the OpenSSL version number from the file’s content using a combination of strings and RegEx.

Below I’ve attached an example version scanner for Linux and Windows. Please note, these are only example scripts and not designed for production use. Use with care, and note they are not 100% guaranteed to find every OpenSSL library on the server.

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

Statically Linked Software

Sometimes software is built in such a way that all the libraries (usually DLL or SO) files are simply compiled into the main software executable. This is the worst case and hardest to deal with.

How To Detect
Using something similar method to the above scripts but for executables instead of libraries.

Current Exploitation Status

Proof of Concept: there is no confirmed proof of concept available for this vulnerability yet
Exploitation: there is no confirmed in the wild exploitation of this vulnerability yet
Vulnerability Credit: Polar Bear (SandboxEscaper)