RUSTSEC-2024-0008: 
Rust vulnerability analysis and mitigation

RUSTSEC-2024-0008 is associated with CVE-2024-23644, affecting the trillium-http (versions < 0.3.12) and trillium-client (versions < 0.5.4) Rust crates. The vulnerability was discovered by divergentdave and involves improper validation of outbound header values that could lead to request splitting or response splitting attacks (GitHub Advisory).

The vulnerability stems from insufficient validation of outbound header values in both trillium-http::HeaderValue and trillium-http::HeaderName components. These could be constructed infallibly and were not checked for illegal bytes when sending requests from the client or responses from the server. This oversight could allow attackers to inject \r\n sequences if they have sufficient control over header values or names, potentially leading to request/response splitting attacks (GitHub Advisory).

If exploited, this vulnerability could allow attackers to get the client and server out of sync, potentially leading to data exfiltration from other requests and Server-Side Request Forgery (SSRF) attacks. The impact is particularly severe in scenarios where attackers have control over outbound headers and can insert "\r\n" sequences (GitHub Advisory).

The vulnerability has been patched in trillium-http version 0.3.12 and trillium-client version 0.5.4. For trillium-http, invalid header names in server response headers are now omitted from network transmission, and invalid header values are individually omitted while preserving other valid values with the same header name. For trillium-client, any invalid header name or value in client request headers returns an Error::MalformedHeader before network access. As a workaround, applications should sanitize or validate untrusted input used in header values and names, ensuring carriage return, newline, and null characters are not allowed (GitHub Advisory).

The vulnerability was reported by divergentdave and initially faced a delay in response. The maintainers acknowledged this delay and updated their security policy to prevent similar delays in the future. Patches were issued within 24 hours of the vulnerability being noticed by the maintenance team (GitHub Advisory).