GitHub Security Advisory: GHSA-3xxc-pwj6-jgrj
Package: rfc3161-client (PIP)
Severity: MODERATE (CVSS 6.2)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: <= 1.0.5
Patched in: 1.0.6

Summary: rfc3161-client Has Improper Certificate Validation

Details:
### Summary

An 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.

### Details

The 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:

```python
leaf_certificate_found = None
for cert in certs:
    if not [c for c in certs if c.issuer == cert.subject]:
        leaf_certificate_found = cert
        break
```

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:

1. 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.
2. 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`.
3. Generating a dummy certificate `D` issued by the *actual* FreeTSA leaf certificate.
4. 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.

### PoC

The environment simulation and the PoC script have been included in the `poc.py` and `Dockerfile` artifacts:

**Dockerfile (`poc/Dockerfile`)**:

```dockerfile
FROM python:3.11-slim
RUN apt-get update && apt-get install -y build-essent