X.509 extensions wrapper tag mutation silently strips all certificate extensions

[afldl]

Found an issue where mbedTLS silently drops all X.509 extensions when the [3] EXPLICIT wrapper tag is changed to [1] or [2]. Tested on mbedTLS 2.28.

RFC 5280 §4.1.2.9 says the extensions field must use tag 0xa3 ([3] EXPLICIT). If you take a valid cert and change just that one byte to 0xa1 (issuerUniqueID tag) or 0xa2 (subjectUniqueID tag), mbedTLS accepts the cert but produces a mbedtls_x509_crt with:

• ext_types == 0
• ca_istrue == 0
• key_usage == 0
• max_pathlen == 0

All critical constraints just disappear. The cert DER bytes are still there but the parsed structure reports no extensions.

The bug: In library/x509_crt.c::x509_get_crt_ext(), when the tag isn't [3], the function treats it as "extensions absent" and returns success:

if( ( ret = mbedtls_asn1_get_tag( p, end, &len,
        MBEDTLS_ASN1_CONTEXT_SPECIFIC | MBEDTLS_ASN1_CONSTRUCTED | 3 ) ) != 0 )
{
    if( ret == MBEDTLS_ERR_ASN1_UNEXPECTED_TAG )
        return( 0 );   /* ← silently skips on wrong wrapper tag */
    ...
}

The OPTIONAL-skip on UNEXPECTED_TAG is correct when extensions are genuinely absent, but wrong when a different context-specific tag is present — that's a malformed cert, not an optional field.

12 other implementations reject it:
OpenSSL 3.x, OpenSSL 4.x, LibreSSL, BoringSSL, GnuTLS, wolfSSL, Botan, NSS, ANSSI x509-parser, rusticata x509-parser, rustls-webpki, briansmith webpki — all reject with parse errors. Only mbedTLS and BearSSL accept.

Reproduction:

# Generate a cert with critical extensions
openssl req -x509 -newkey rsa:2048 -keyout /tmp/k.pem -out /tmp/c.pem \
    -days 365 -nodes -subj "/CN=Test" -sha256 \
    -addext "keyUsage=critical,digitalSignature" \
    -addext "basicConstraints=critical,CA:FALSE"
openssl x509 -in /tmp/c.pem -outform DER -out /tmp/base.der

# Mutate the extensions wrapper tag 0xa3 → 0xa2
python3 -c "
data = bytearray(open('/tmp/base.der','rb').read())
for i in range(len(data) - 2):
    if data[i] == 0xa3 and data[i+2] == 0x30:
        data[i] = 0xa2
        break
open('/tmp/poc.der','wb').write(data)
"

# mbedTLS accepts (ext_types=0), everyone else rejects

Fix: Only accept the optional-skip when there's genuinely no more data:

- if( ret == MBEDTLS_ERR_ASN1_UNEXPECTED_TAG )
-     return( 0 );
+ if( ret == MBEDTLS_ERR_ASN1_UNEXPECTED_TAG && *p == end )
+     return( 0 );    /* genuinely absent */
+ if( ret == MBEDTLS_ERR_ASN1_UNEXPECTED_TAG )
+     return( MBEDTLS_ERROR_ADD( MBEDTLS_ERR_X509_INVALID_EXTENSIONS, ret ) );

Found through 14-implementation differential fuzzing (PathDiff diff_fuzz_v2). BearSSL has the same bug; I'll file separately with them.

[ronald-cron-arm]

Hi, thanks for you interest in Mbed TLS. We do not support 2.28 anymore. Is the issue still present in 3.6.6 and/or development?
Otherwise in 2.28.10 (last release of 2.28, commit 2fc8413) I cannot find the code

if( ( ret = mbedtls_asn1_get_tag( p, end, &len,
        MBEDTLS_ASN1_CONTEXT_SPECIFIC | MBEDTLS_ASN1_CONSTRUCTED | 3 ) ) != 0 )
{
    if( ret == MBEDTLS_ERR_ASN1_UNEXPECTED_TAG )
        return( 0 );   /* ← silently skips on wrong wrapper tag */
    ...
}

The closest I have is:

static int x509_get_crt_ext(unsigned char **p,                                  
                            const unsigned char *end,                           
                            mbedtls_x509_crt *crt,                              
                            mbedtls_x509_crt_ext_cb_t cb,                       
                            void *p_ctx)                                        
{                                                                               
    int ret = MBEDTLS_ERR_ERROR_CORRUPTION_DETECTED;                            
    size_t len;                                                                 
    unsigned char *end_ext_data, *start_ext_octet, *end_ext_octet;              
                                                                                
    if (*p == end) {                                                            
        return 0;                                                               
    }                                                                           
                                                                                
    if ((ret = mbedtls_x509_get_ext(p, end, &crt->v3_ext, 3)) != 0) {           
        return ret;                                                             
    }

Is it the equivalent of the code you refer to?

[afldl]

Hi Ronald,

Yes, still present in both 3.6.x and the development branch (tested on commit 5cd6337). The x509_get_crt_ext code you quoted is fine — it does reject a wrong tag. But that's not where the bug is.

The problem is that x509_get_crt_ext never even gets called when the tag is [1] or [2], because x509_get_uid eats the extensions data first.

The parsing order in x509_crt_parse_der is:

x509_get_uid(&p, end, &crt->issuer_id,  1);   // looks for [1]
x509_get_uid(&p, end, &crt->subject_id, 2);   // looks for [2]
x509_get_crt_ext(&p, end, crt, cb, p_ctx);    // looks for [3]

When I flip the 0xa3 byte to 0xa1, here's what happens:

1. x509_get_uid(..., 1) tries to match CONTEXT_SPECIFIC | CONSTRUCTED | 1. The mutated tag is 0xa1, so it matches. The function sets uid->p = *p; *p += uid->len; and skips over the entire extensions blob, treating it as the issuer unique identifier.

2. x509_get_uid(..., 2) checks *p == end — true, since all remaining data was consumed in step 1 — returns 0.

3. x509_get_crt_ext() checks *p == end — still true — returns 0 with v3_ext.len == 0.

Certificate parses successfully. Zero extensions. Every critical extension is gone.

I confirmed this against mbedTLS 2.28.0 (Debian package) with a real cert:

$ openssl req -x509 -newkey rsa:2048 -keyout /dev/null -out cert.pem \
    -days 3650 -nodes -subj "/CN=TestCA" \
    -addext "basicConstraints=critical,CA:TRUE"
$ openssl x509 -in cert.pem -outform DER -out cert.der

Then flip one byte at the 0xa3 offset (offset 414 in my 775-byte cert):

Original (tag=0xa3):  v3_ext.len=83  ca_istrue=1   → accepted, extensions present
Mutated  (tag=0xa1):  v3_ext.len=0   ca_istrue=0   → accepted, extensions GONE
Mutated  (tag=0xa2):  v3_ext.len=0   ca_istrue=0   → accepted, extensions GONE

The x509_get_uid code hasn't changed between 2.28 and the current development branch — same function, same line numbers, same logic:

// library/x509_crt.c, x509_get_uid():
uid->p = *p;
*p += uid->len;
return 0;

It doesn't validate the content at all. A UID is IMPLICIT UniqueIdentifier which is a BIT STRING, so the content should start with a bit-string tag or at least not a SEQUENCE. But the function just blindly advances the pointer.

A simple fix would be to reject the match when the content starts with 0x30 (SEQUENCE tag), since a BIT STRING would never start with that:

if ((ret = mbedtls_asn1_get_tag(p, end, &uid->len,
                                MBEDTLS_ASN1_CONTEXT_SPECIFIC | MBEDTLS_ASN1_CONSTRUCTED |
                                n)) != 0) {
    if (ret == MBEDTLS_ERR_ASN1_UNEXPECTED_TAG) {
        return 0;
    }
    return MBEDTLS_ERROR_ADD(MBEDTLS_ERR_X509_INVALID_FORMAT, ret);
}

/* UID is IMPLICIT UniqueIdentifier (BIT STRING). If the content starts
 * with a SEQUENCE tag, this is almost certainly a mutated extensions
 * wrapper, not a real UID. */
if (uid->len > 0 && **p == (MBEDTLS_ASN1_CONSTRUCTED | MBEDTLS_ASN1_SEQUENCE)) {
    return MBEDTLS_ERR_X509_INVALID_FORMAT;
}

uid->p = *p;
*p += uid->len;

Another option: since RFC 5280 says UIDs "should" not be used in new certificates and the version field has already been parsed, you could require that if version == 3 and there's data left after the UIDs but no [3] tag, that's a parse error rather than "no extensions." But that might break some weird legacy certs.

Happy to send the test program if you want to reproduce it locally.