CVE-2024-6119 - How Certificate Name Checks in X.509 Certificates Can Crash Your TLS Client Applications

On June 2024, a new vulnerability tracked as CVE-2024-6119 was disclosed, affecting applications that perform certificate name checks during TLS connections using X.509 certificates. Although this vulnerability does not compromise confidentiality or integrity, it can still result in a denial of service (DoS) by causing applications to crash. In this post, we break down what CVE-2024-6119 is, how an attacker might use it, and what you can do to stay safe.

Issue Summary

Many secure applications (like web browsers and TLS clients) validate certificates as part of setting up secure connections. They often check if a certificate matches a domain name (DNS), an email address, or even an IP address they expect.

CVE-2024-6119 exposes a problem when apps compare the expected name against the certificate's subjectAltName field—specifically when there’s a malformed otherName value in this field. An attacker who controls this part of a certificate can make the application read an invalid memory address, causing it to throw an exception and crash.

Plainly: If your app checks server certificate names, and it stumbles on a tricky certificate, it might crash.

How: Crashing the entire application process, which disrupts service.

- Affected: TLS clients (not usually servers), especially those that perform certificate name checks.
- Not affected: Apps that only do basic certificate chain validation (signature, dates), or those not using name matching. Also, OpenSSL FIPS modules (versions 3.3, 3.2, 3.1, and 3.) are not impacted.

Desktop and mobile apps using TLS clients

- Automated tools or systems connecting to HTTPS/SSL services (APIs, bots, etc.)

Web browsers (to a certain extent if they use vulnerable libraries and strict name checks)

TLS servers are largely not affected because they normally don’t check a client’s name against a fixed reference.

Technical Details & Example

The bug happens when a client receives an X.509 certificate and checks the subjectAlternativeName extension. This extension can contain multiple types, including DNS, IP, Email, and otherName. If otherName is improperly formed, the client can attempt to read memory in a way it shouldn't—leading to a crash.

Below is an example of vulnerable logic found in some TLS client libraries

for (each subjectAltName in certificate) {
    if (subjectAltName->type == otherName) {
        // Attacker crafts a certificate such that 'name' is not a valid string
        if (strcmp(subjectAltName->name, expected_name) == ) {
            return MATCH;
        }
    }
}

If subjectAltName->name points to invalid memory or isn’t properly checked, the strcmp can cause a segmentation fault.

Real-World Example: OpenSSL

OpenSSL advisory (June 2024) illustrates how certain versions can crash if presented a certificate with a malformed otherName field and the client code is performing a name check:

// Example exploit certificate with crafted SAN
X509v3 Subject Alternative Name: 
    otherName:<malformed>

When the vulnerable OpenSSL code tries to compare this otherName to the client’s expected DNS name, it reads invalid memory and the process crashes.

Exploit Scenario

1. The attacker crafts a malicious certificate with an invalid or broken otherName value in the Subject Alternative Name.

During the TLS handshake, the client validates the certificate and performs a name check.

4. The client attempts to compare its expected name to otherName and reads an invalid memory location.

Crash! The client application terminates unexpectedly.

This doesn’t allow the attacker to read data or run code, but it can disrupt automated systems, client apps, or even waste server resources by knocking clients offline.

Create a bad certificate (with OpenSSL)

[ req ]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no

[ req_distinguished_name ]
CN = bad.othername.test

[ v3_req ]
subjectAltName = otherName:1.2.3.4;UTF8:malformed

Sign and issue the certificate; then connect with a client that checks the name. If the client crashes, it might be vulnerable.

Mitigation & Fixes

- Upgrade your libraries: Check for security updates in all cryptography and TLS libraries (like OpenSSL).
- OpenSSL Security Advisories

Apply patches as soon as possible.

- Do proper bounds checking: If writing custom certificate validation, always make sure that all expected data is present and valid before comparing.

- TLS server operators: Although mostly client-side, ensure your systems aren’t relaying or serving untrusted certificates to clients.

References (Original Sources)

- OpenSSL Security Advisory: June 18, 2024 (CVE-2024-6119)
- NIST CVE-2024-6119
- OpenSSL Vulnerabilities Page
- X.509 Certificate Subject Alternative Name

Conclusion

CVE-2024-6119 may seem “just” a denial-of-service bug, but for systems that depend on stability and uptime, it’s important to patch! Applications that perform name checks during TLS handshakes are at risk of crashing if attackers feed them malformed certificates, especially those with suspect otherName fields in their Subject Alternative Name extension. Use this information to verify, patch, and protect your apps.

Stay safe and keep your TLS stacks up to date!

*This article is exclusive to this post. For in-depth info, always check the references and your software vendor’s support pages for updates related to CVE-2024-6119.*

Timeline

Published on: 09/03/2024 16:15:07 UTC
Last modified on: 09/03/2024 21:35:12 UTC