CVE-2014-1492 is a significant vulnerability found in the Mozilla Network Security Services (NSS) library, specifically in the way it checks SSL certificates for valid hostnames. If you’re not deeply into cybersecurity, you might not realize how a simple bug in domain name handling can put your private information at risk. In this post, we’ll break down how this bug works, show some code, and explain how an attacker might exploit it—with practical and accessible explanations.

What Is NSS and What Went Wrong?

Mozilla’s Network Security Services (NSS) is a set of libraries used for SSL/TLS and other cryptographic standards. Products like Firefox and Thunderbird make heavy use of NSS for secure communication.

The vulnerability exists in a function called cert_TestHostName (inside lib/certdb/certdb.c). This function is supposed to check if the hostname in an SSL certificate is valid for the server the client is connecting to. That check needs to be bulletproof: if someone can fake a match, users can be tricked into thinking they’re talking to a trusted website when they’re actually talking to an attacker.

The problem arises when the function is handling wildcards (like *.example.com) in an internationalized domain name (IDN)—one containing non-ASCII characters (Unicode domains, commonly encoded with Punycode in DNS).

Here’s what went wrong:
NSS wrongly allowed a wildcard (*) within the U-label (Unicode representation) of an IDN, rather than only at the very beginning of an ASCII hostname label as allowed by RFCs.

The Real-World Impact

With this bug, an attacker could create and buy a valid-looking SSL certificate with a wildcard in the internationalized portion of the domain name, and trick NSS into accepting it as valid for non-related, sensitive hostnames.

For example, the browser could be fooled that a certificate for xn--*oogle-wmc.com matches google.com.

Looking at the Vulnerable Code

Here’s a simplified snippet showing the logic inside cert_TestHostName prior to the fix (drawn from NSS codebase):

static PRBool cert_TestHostName(const char * cn, const char *hn)
{
    // Check for wildcards and hostname/label comparison
    // ...
    if (strchr(cn, '*')) {
        // incorrectly allows wildcards embedded in IDN U-labels
        if (/* wildcard matches */) {
            return PR_TRUE;
        }
    }
    // ...
    // Fallback: exact match
    return PL_strcasecmp(hn, cn) == ;
}

Before the patch, the code didn’t restrict wildcards inside the "U-label" part of a domain. RFC 6125 and common sense say the only valid position for a wildcard is to replace the entire leftmost label (*.example.com), not somewhere like f*o.example.com or inside an IDN.

The actual fix in NSS 3.16 involved properly checking the wildcard location and strictly following the RFCs.

Let’s see how an attacker could use this bug

1. Register a Tricky Domain: The attacker registers an IDN domain where the Unicode form includes a *, which when encoded as Punycode, looks like for example: xn--*oogle-wmc.com.
2. Get a Certificate: The attacker requests an SSL certificate for this domain (some Certificate Authorities might be tricked).
3. Man-in-the-Middle (MitM) Attack: On a public Wi-Fi, for example, the attacker intercepts HTTPS requests for google.com, presents their crafted cert with the * embedded in the IDN, and NSS wrongly validates it.

Demo: Crafting a Certificate (Illustration)

Here’s a pseudo-command using OpenSSL to generate a self-signed certificate for an IDN containing a wildcard (for illustration; real-world exploitation is more complex):

openssl req -x509 -nodes -newkey rsa:2048 \
    -subj "/CN=xn--*oogle-wmc.com" \
    -days 365 -keyout server.key -out server.crt

*This certificate, when presented by a malicious server, could trick older NSS versions into trusting it for google.com.*

Here’s a simplified version of the fixed logic

if (is_ascii(cn) && starts_with_wildcard(cn) && valid_wildcard_position(cn)) {
    // Ok
} else {
    // No match if wildcard is anywhere else or in an IDN
}

References

- NSS 3.16 Release Notes
- Official Mozilla Bug Report (Bug 985510)
- Patch on NSS Source Tree
- CERT Advisory VU#585222
- RFC 6125: Wildcard Certificates

Conclusion

CVE-2014-1492 is a powerful example of how internationalization and wildcard domains—usually good features—can introduce subtle but serious security holes. The takeaway? _Always keep your security libraries up to date, and never underestimate domain parsing logic in cryptographic code._

If you’re building or maintaining software that depends on NSS or accepts SSL connections, make sure you’re running NSS 3.16 or later. This two-character mistake in a hostname can crack the biggest security promises.

Timeline

Published on: 03/25/2014 01:00:00 UTC
Last modified on: 04/12/2025 10:46:40 UTC