GHSA-pwjx-qhcg-rvj4: Certificate Revocation Bypass via Iterator Exhaustion in rustls-webpki

The rustls-webpki crate functions as a web PKI certificate verification library for the Rust ecosystem. It is responsible for validating X.509 certificate chains and managing revocation checks against Certificate Revocation Lists (CRLs). The GHSA-pwjx-qhcg-rvj4 vulnerability affects the precise logic governing how CRL authority is established during this validation process.

RFC 5280 strictly requires verifiers to ensure that a CRL is authoritative for a given certificate. The verification process involves matching the URI names located in the CRL's Issuing Distribution Point (IDP) extension against the URI names specified in the certificate's CRL Distribution Point (DP) extension. A failure to match these extensions means the CRL cannot be used to determine the certificate's revocation status.

The implementation within rustls-webpki contains a fundamental logic error involving the exhaustion of one-shot DER iterators during this matching sequence. When multiple URIs are present in both the certificate DP and the CRL IDP, the verifier fails to perform a complete cross-product comparison. The iterator is drained prematurely, causing subsequent valid comparisons to be skipped entirely.

Because the matching process fails, the verifier incorrectly concludes that the CRL is not authoritative for the presented certificate. If the relying application configures rustls-webpki with a permissive unknown status policy, the verifier defaults to accepting the revoked certificate. This bypasses the intended cryptographic security controls established by the Certificate Authority.

The root cause resides in the IssuingDistributionPoint::authoritative_for() function located in src/crl/types.rs. This specific function executes the logic required to determine if a provided CRL covers the revocation status of the target X.509 certificate. The defect originates from how the function handles DER-encoded sequence iteration.

The matching algorithm utilizes DER iterators to process the idp_general_names and the certificate DP fullName entries. These iterators operate as one-shot streams that consume their underlying data sequentially as they are traversed. The vulnerable code parses the idp_general_names exactly once at the beginning of the function and then begins iterating over the certificate's DP URIs.

For each DP URI extracted from the certificate, the inner logic attempts to locate a matching IDP URI. During the first iteration of the outer DP loop, the inner loop consumes the entire IDP iterator while searching for a match. When the outer loop advances to process the second DP URI, the inner IDP iterator is already empty and provides no elements for comparison.

Consequently, any valid matching URI pairs that occur after the first element are completely ignored by the verifier. The function exits the evaluation loop without finding the required match, forcing the broader verification logic to categorize the perfectly valid CRL as non-authoritative for the target certificate.

The vulnerable implementation in src/crl/types.rs demonstrates the improper handling of nested iteration over single-pass data structures. The sequence of comparisons drains the iterator state during the initial pass, leaving no data for subsequent checks.

// Abstracted vulnerable pattern representing the logic in src/crl/types.rs
let mut idp_uris = parse_general_names(idp_ext);
for dp_uri in dp_uris {
    // The idp_uris iterator is consumed completely on the first pass
    // Subsequent dp_uri iterations will check against an empty iterator
    if uri_name_in_common(dp_uri, &mut idp_uris) {
        return true;
    }
}

The patch resolves the iterator exhaustion by ensuring the IDP URIs are either collected into a reusable collection or reparsed for each individual DP URI. This architectural adjustment guarantees a complete Cartesian product comparison between the two sets of URIs.

// Abstracted patched pattern
for dp_uri in dp_uris {
    // The IDP URIs are reparsed/refreshed for each DP URI
    let mut fresh_idp_uris = parse_general_names(idp_ext);
    if uri_name_in_common(dp_uri, &mut fresh_idp_uris) {
        return true;
    }
}

By snapshotting or reparsing the IDP state, the inner loop always operates on a complete sequence of IDP URIs for every iteration of the outer DP loop. This aligns the rustls-webpki implementation with the strict requirements of RFC 5280 regarding authoritative Distribution Point matching.

Exploitation of this vulnerability requires an attacker to possess a compromised or explicitly revoked certificate that contains multiple URI entries within its CRL Distribution Point extension. The attacker must target a system utilizing a vulnerable version of rustls-webpki that relies on CRLs for revocation checking.

The attacker initiates a standard TLS handshake with the vulnerable client or server, presenting the specifically crafted revoked certificate. The rustls-webpki verifier extracts the DP URIs, fetches the corresponding CRL, and attempts to establish authority by matching the IDP URIs.

The iterator bug triggers reliably when the matching URI is located in the second (or subsequent) position within both the DP and IDP lists. Because the verifier skips the evaluation, it concludes the CRL cannot authorize the revocation status of the certificate.

The final prerequisite for successful exploitation is a permissive verifier configuration. The target application must be instantiated with UnknownStatusPolicy::Allow. This specific policy instructs the verifier to proceed when revocation status cannot be definitively established, culminating in the successful acceptance of the revoked certificate.

The vulnerability holds a CVSS v3.1 score of 4.4, categorizing it as Medium severity. This score is heavily influenced by the high attack complexity (AC:H) and high privileges required (PR:H). The attacker requires the ability to obtain or manipulate certificates populated with multiple DPs and IDPs, which limits the pool of potential threat actors.

Despite the moderate overall score, the localized integrity impact is high (I:H). The primary objective of the webpki library is to establish cryptographic trust between endpoints. Bypassing the revocation enforcement mechanism undermines this trust model entirely for connections fulfilling the exploit prerequisites.

An attacker successfully exploiting this vulnerability gains the ability to establish authenticated sessions using a certificate that the issuing Certificate Authority has explicitly invalidated. This facilitates man-in-the-middle attacks, data interception, or unauthorized access to backend services relying on mutual TLS (mTLS) authentication.

Applications incorporating rustls-webpki remain exposed if they do not manually enforce strict revocation checking policies. Known downstream projects, including components of Cloudflare's Pingora and Tauri applications, inherently rely on this underlying validation logic and inherit the associated risks.

The primary remediation strategy requires upgrading the rustls-webpki dependency to a secure version. Maintainers have released versions 0.103.10 and 0.104.0-alpha.5 to explicitly address the iterator exhaustion flaw and restore proper RFC 5280 compliance.

Software engineering teams must audit their dependency trees utilizing standard cargo tooling to identify any transitive dependencies on vulnerable versions of the crate. Cargo lockfiles must be regenerated to ensure the patched versions are incorporated into all compiled binaries.

For deployments where immediate dependency patching is unfeasible, systems administrators and developers must apply a configuration workaround. Applications utilizing rustls should instantiate the TLS configuration with UnknownStatusPolicy::Deny rather than the permissive alternative.

Implementing the strict denial policy ensures that if the verifier fails to establish CRL authority due to the iterator bug, the connection terminates safely. While this mitigation introduces a theoretical availability risk via false positives for revocation checks, it guarantees cryptographic integrity is maintained.