GHSA-3xxc-pwj6-jgrj: rfc3161-client Has Improper Certificate Validation
SummaryAn Authorization Bypass vulnerability in `rfc3161-client`'s signature verification allows any attacker to impersonate a trusted TimeStamping Authority (TSA). By exploiting a logic flaw in how the library extracts the leaf certificate from an unordered PKCS#7 bag of certificates, an attacker can append a spoofed certificate matching the target `common_name` and Extended Key Usage (EKU) requirements. This tricks the library into verifying these authorization rules against the forged certificate while validating the cryptographic signature against an actual trusted TSA (such as FreeTSA), thereby bypassing the intended TSA authorization pinning entirely.DetailsThe root cause lies in `rfc3161_client.verify.Verifier._verify_leaf_certs()`. The library attempts to locate the leaf certificate within the parsed TimeStampResponse PKCS#7 `SignedData` bag using a naive algorithm:This loop erroneously assumes that the valid leaf certificate is simply the first certificate in the bag that does not issue any other certificate. It does **not** rely on checking the `ESSCertID` or `ESSCertIDv2` cryptographic bindings specified in RFC 3161 (which binds the signature securely to the exact signer certificate).An attacker can exploit this by:Acquiring a legitimate, authentic TimeStampResponse from *any* widely trusted public TSA (e.g., FreeTSA) that chains up to a Root CA trusted by the client.Generating a self-signed spoofed "proxy" certificate `A` with the exact `Subject` (e.g., `CN=Intended Corporate TSA`) and `ExtendedKeyUsage` (`id-kp-timeStamping`) required by the client's `VerifierBuilder`.Generating a dummy certificate `D` issued by the *actual* FreeTSA leaf certificate.Appending both `A` and `D` to the `certificates` list in the PKCS#7 `SignedData` of the TimeStampResponse.When `_verify_leaf_certs()` executes, the dummy certificate `D` disqualifies the authentic FreeTSA leaf from being selected (because FreeTSA now technically "issues" `D` within the bag). The loop then evaluates the spoofed certificate `A`, realizes it issues nothing else in the bag, and selects it as `leaf_certificate_found`.The library then processes the `common_name` and EKU checks exactly against `A`. Since `A` was explicitly forged to pass these checks, verification succeeds. Finally, the OpenSSL `pkcs7_verify` backend validates the actual cryptographic signature using the authentic FreeTSA certificate and trusted roots (ignoring the injected certs). The application wrongly trusts that the timestamp was granted by the pinned TSA.PoCThe environment simulation and the PoC script have been included in the `poc.py` and `Dockerfile` artifacts:**Dockerfile (`poc/Dockerfile`)**:The attack flow locally demonstrated in `poc/poc.py`:Requests a timestamp from `https://freetsa.org/tsr`.Generates a fake cert with `common_name="Spoofed TSA"` and `ExtendedKeyUsage=TIME_STAMPING`.Parses the authentic TS response, injects a dummy cert issued by FreeTSA's leaf.Injects the fake cert into the bag.Invokes `decode_timestamp_response()` on the malicious bytes.Runs `VerifierBuilder(common_name="Spoofed TSA", ...).verify_message(malicious_resp, msg)`.Observes a successful verification bypassing the `common_name` constraint.Impact**Vulnerability Type:** Authorization Bypass / Improper Certificate Validation / Trust Boundary Confusion
**Impact:** High. Applications relying on `rfc3161-client` to guarantee the origin of a timestamp via `tsa_certificate` or `common_name` pinning are completely exposed to impersonation. An attacker can forge the identity of the TSA as long as they hold *any* valid timestamp from a CA trusted by the Verifier.
CVSS v3.1: 6.2