Vulnerability Details
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.
X.509 Email Address 4-byte Buffer Overflow (CVE-2022-3602)
==========================================================
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)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.
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 }
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)
See Also: Critical zero-day bug, first since Heartbleed, identified in OpenSSL
Suggest an edit to this article
Stay informed of the latest Cybersecurity trends, threats and developments. Sign up for our Weekly Cybersecurity Newsletter Today.
Remember, CyberSecurity Starts With You!
- Globally, 30,000 websites are hacked daily.
- 64% of companies worldwide have experienced at least one form of a cyber attack.
- There were 20M breached records in March 2021.
- In 2020, ransomware cases grew by 150%.
- Email is responsible for around 94% of all malware.
- Every 39 seconds, there is a new attack somewhere on the web.
- An average of around 24,000 malicious mobile apps are blocked daily on the internet.
