Ra Tls Clients
Monthly
Time-of-check/time-of-use weakness in Privasys ra-tls-clients before 0.9.1 allows a local, low-privileged attacker on the attested TLS endpoint (the Attester) to modify workload code, data, or configuration after remote attestation has already succeeded, while the verifying peer continues to trust the original Evidence for the remainder of the connection. Exploitation requires prior local access to the Attester plus an attested connection (deterministic or challenge mode) that is still open - the window spans connection establishment to termination, and unattested ('none') connections are out of scope. The flaw is fixed in 0.9.1; no public exploit identified at time of analysis.
Privasys ra-tls-clients verifiers before 0.11.0 accept TEE attestation evidence without binding it to an explicitly authorized platform identity, so an unauthenticated remote attacker (CVSS vector PR:N) who can either forge attestation evidence or extract attestation secrets from a separate compromised-but-still-unrevoked Intel SGX/TDX or AMD SEV-SNP platform can present valid measurements from that other machine and impersonate the attested TLS endpoint to the verifier. Exploitation is gated by high attack complexity (AC:H, AT:P) because the attacker must actually control or forge a genuine unrevoked TEE platform, but confidentiality and integrity impact is rated High (assessed CVSS:3.1 8.1; vendor CVSS 4.0 score 9.1), and affected deployments are precisely those running the default policy with an empty platform allow-list. No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV; the flaw is fixed by ra-tls-clients 0.11.0, which introduces platform allow-listing that fails closed.
Session-substitution in Privasys RA-TLS Clients (the Rust ratls_client crate and the Go ratls package, challenge-mode verifiers) prior to 0.5.0 lets an attacker who already possesses an enclave TLS private key relay a genuine attestation quote onto a different, attacker-terminated TLS connection, so the client accepts that connection as coming from the attested enclave. The flaw is an origin/session-binding gap: the quote's ReportData was checked against the certificate public key and the client nonce but never against the live TLS session, allowing a captured quote to be replayed onto an unrelated handshake and granting full session confidentiality and integrity loss (CVSS 4.0 9.1 Critical, VC:H/VI:H, AV:N with PR:N - unauthenticated from the verifier's perspective). Exploitation is gated by the attacker's pre-existing enclave private key and by the deployment running challenge mode on a build that exposes the RA-TLS channel binder; no public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis, and the vendor-released patch is version 0.5.0.
Time-of-check/time-of-use weakness in Privasys ra-tls-clients before 0.9.1 allows a local, low-privileged attacker on the attested TLS endpoint (the Attester) to modify workload code, data, or configuration after remote attestation has already succeeded, while the verifying peer continues to trust the original Evidence for the remainder of the connection. Exploitation requires prior local access to the Attester plus an attested connection (deterministic or challenge mode) that is still open - the window spans connection establishment to termination, and unattested ('none') connections are out of scope. The flaw is fixed in 0.9.1; no public exploit identified at time of analysis.
Privasys ra-tls-clients verifiers before 0.11.0 accept TEE attestation evidence without binding it to an explicitly authorized platform identity, so an unauthenticated remote attacker (CVSS vector PR:N) who can either forge attestation evidence or extract attestation secrets from a separate compromised-but-still-unrevoked Intel SGX/TDX or AMD SEV-SNP platform can present valid measurements from that other machine and impersonate the attested TLS endpoint to the verifier. Exploitation is gated by high attack complexity (AC:H, AT:P) because the attacker must actually control or forge a genuine unrevoked TEE platform, but confidentiality and integrity impact is rated High (assessed CVSS:3.1 8.1; vendor CVSS 4.0 score 9.1), and affected deployments are precisely those running the default policy with an empty platform allow-list. No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV; the flaw is fixed by ra-tls-clients 0.11.0, which introduces platform allow-listing that fails closed.
Session-substitution in Privasys RA-TLS Clients (the Rust ratls_client crate and the Go ratls package, challenge-mode verifiers) prior to 0.5.0 lets an attacker who already possesses an enclave TLS private key relay a genuine attestation quote onto a different, attacker-terminated TLS connection, so the client accepts that connection as coming from the attested enclave. The flaw is an origin/session-binding gap: the quote's ReportData was checked against the certificate public key and the client nonce but never against the live TLS session, allowing a captured quote to be replayed onto an unrelated handshake and granting full session confidentiality and integrity loss (CVSS 4.0 9.1 Critical, VC:H/VI:H, AV:N with PR:N - unauthenticated from the verifier's perspective). Exploitation is gated by the attacker's pre-existing enclave private key and by the deployment running challenge mode on a build that exposes the RA-TLS channel binder; no public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis, and the vendor-released patch is version 0.5.0.