Listen to this Post
The vulnerability resides in the `httpsig-hyper` Rust crate, which is used to implement HTTP Message Signatures based on RFC9421 . A critical flaw exists in how the library verifies the `Digest` header, which is meant to ensure the integrity of the HTTP message body. The issue stems from the misuse of Rust’s `matches!` macro in the verification logic. Specifically, the code used a pattern if matches!(digest, _expected_digest). In Rust, the `matches!` macro checks if a value matches a specific pattern. Here, `_expected_digest` in this context is treated as a new pattern that matches any value, binding the value to the variable name _expected_digest, rather than comparing the `digest` against the actual expected digest value. This effectively causes the `matches!` expression to always evaluate to true. As a direct result, the digest verification check would incorrectly succeed even when the computed digest of the message body did not match the `Digest` header value provided. An attacker could exploit this by modifying the HTTP message body while leaving the original `Digest` header unchanged. The library would incorrectly validate the digest, passing the integrity check despite the tampering. The severity of this vulnerability is considered medium because it bypasses a key integrity check; however, its impact is highly dependent on the application’s overall security architecture. If the application relies on this digest verification as the sole method to detect body tampering, the impact is critical. The maintainers have patched this issue in version 0.0.23 by replacing the faulty `matches!` usage with a proper value comparison. As a defense-in-depth measure, they also introduced a constant-time comparison function for digest verification to mitigate potential timing side-channel attacks .
Platform: Rust crate
Version: < 0.0.23
Vulnerability : Digest Bypass
Severity: Medium
date: 2024-04-11
Prediction: Patched in 0.0.23
What Undercode Say:
Analytics
- Vulnerable Code Component: The flaw was located in the function responsible for verifying the `Digest` header, where the `matches!` macro was used incorrectly.
- Vulnerable Versions: All versions of `httpsig-hyper` prior to 0.0.23 are affected.
- Fix Commit: The patch was introduced in version 0.0.23, which replaces the pattern match with a direct value comparison and adds constant-time comparison logic.
Exploit:
The core of the exploit lies in sending a request where the body has been tampered with but the `Digest` header is left unaltered from a previous, valid request.
Vulnerable Code Snippet (Conceptual):
// Incorrect usage that causes the bypass
// let expected_digest = compute_digest(&body);
if matches!(digest_header_value, _expected_digest) {
// This block ALWAYS executes, even if the digests don't match.
return Ok(());
} else {
return Err(());
}
Fixed Code Snippet (Conceptual):
// let expected_digest = compute_digest(&body);
if digest_header_value == expected_digest {
// Correctly verifies the digest.
// Additionally, a constant-time comparison is now used.
return Ok(());
} else {
return Err(());
}
Protection from this CVE
- Immediate Upgrade: The primary and only fully effective mitigation is to upgrade the `httpsig-hyper` crate to version 0.0.23 or later.
- Defense in Depth: If immediate upgrading is not possible, applications should not rely solely on this library’s digest verification. Implement additional application-layer checks to validate the integrity of critical message bodies, such as comparing a manually computed hash against the `Digest` header.
- Layered Signatures: Ensure that full HTTP message signature verification is enforced and covers components beyond just the digest, making it harder to tamper with messages without invalidating the signature.
Impact
A successful exploit allows an attacker to tamper with the body of an HTTP message without invalidating its signature or digest verification. The impact is broad, as it breaks the core integrity guarantee of the protocol. In applications where this verification is the primary defense against request/response tampering, an attacker could:
– Modify Data: Change the contents of a request (e.g., a financial transaction amount) or response (e.g., critical data returned from an API) after it has been signed.
– Bypass Security Controls: Inject malicious payloads into messages that are trusted by the backend service.
– Undermine Non-Repudiation: Since the signature appears valid, it becomes impossible to cryptographically prove that a message was altered after it was originally signed.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
