Fedora Account System
Red Hat Associate
Red Hat Customer
Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process. The DTLS retransmission logic does not correctly handle a handshake message write that is suspended part-way through. The retransmitted message can be read past the message buffer and the retransmission overwrites the internal state the suspended write needs to resume correctly.
VE Impact Analysis: DTLS Out-of-bounds Read vs. clevis-pin-trustee Verdict: NOT AFFECTED The CVE targets OpenSSL's DTLS retransmission logic — code that lives in libssl, specifically the DTLS handshake message fragmentation and retransmission path. clevis-pin-trustee never exercises this code. --- How clevis-pin-trustee Uses OpenSSL. OpenSSL is basically used by jose-kit and reqwest dependencies: A - josekit: ------------ The dependency chain is: clevis-pin-trustee (binary) └── jose-kit v0.1.2 ├── jose-sys v0.1.2 → libjose.so (dynamic, via pkg-config) └── openssl v0.10.72 └── openssl-sys v0.9.107 → libcrypto.so (dynamic, via pkg-config) Why DTLS Is Unreachable 1. No libssl usage: The jose C library and jose-kit only use libcrypto for cryptographic primitives (AES, HMAC, key agreement). The DTLS code lives in libssl, which is never called. 2. No SSL/TLS context creation: The binary never creates SSL_CTX, SSL objects, or performs handshakes. It does no protocol-level SSL/TLS/DTLS operations whatsoever. 3. No network sockets: DTLS requires UDP transport. clevis-pin-trustee creates no sockets of any kind — all network communication is delegated to the separately-installed trustee-attester binary, which is spawned as a subprocess. 4. JWE-only crypto: The only OpenSSL functionality exercised is: - jose_jwe_enc() — encrypt a symmetric key into a JWE token - jose_jwe_dec() — decrypt a JWE token back to a symmetric key These are purely data-transformation operations using libcrypto, with no protocol state machines involved. 5. Certificate files are pass-through: Although the code writes server certificates to /run/trustee/cert_*.pem, these are passed as file paths to trustee-attester — the Rust binary never uses them for TLS negotiation itself. B - reqwest -> native-tls -> openssl: ------------------------------------- - native-tls exclusively uses SslMethod::tls(), never SslMethod::dtls() At native-tls-0.2.18/src/imp/openssl.rs:287, the connector is built with: let mut connector = SslConnector::builder(SslMethod::tls())?; This creates a standard TLS context (TLS over TCP). The native-tls crate has zero DTLS support — it doesn't expose SslMethod::dtls() anywhere in its public or private API. - reqwest operates over HTTP(S) / TCP only reqwest is an HTTP client built on hyper, which operates exclusively over TCP streams. HTTP does not use UDP, and therefore DTLS is never involved. The clevis-pin-trustee CLI uses reqwest::blocking::Client (line 139, 425, 429) to make HTTPS PUT requests to Trustee servers — all over TCP. - The DTLS retransmission mechanism is unreachable The CVE's vulnerable code path — the DTLS handshake retransmission logic that reads past the message buffer — is only triggered when: - An SSL object is created with DTLS_method() / DTLS_client_method() / DTLS_server_method() - A DTLS handshake is in progress over a datagram (UDP) BIO - A handshake message write is suspended and then retransmitted