Listen to this Post
The vulnerability lies in the NSEC3 closest‑encloser proof validation logic inside `DnssecDnsHandle` for affected versions of `hickory-proto` (0.25.0‑alpha.3 … 0.25.2) and `hickory-net` (0.26.0‑alpha.1 … 0.26.0). When validating a NoData or NXDomain response, the code walks upward from the QNAME to the SOA owner name, building a vector of candidate encloser names. The loop assumes the QNAME is a descendant of the SOA owner and terminates only when the current candidate equals the SOA name. If the SOA record in the authority section comes from a zone that is not an ancestor of the QNAME – for example, due to an insecure CNAME chain crossing zone boundaries – the iteration reaches the DNS root but never matches the SOA owner. The loop then continues indefinitely, repeatedly calling `Name::base_name()` and pushing newly allocated `Name` and hashed‑name entries onto the vector. A `debug_assert_ne!(name, Name::root())` guards the loop body: in debug builds this triggers a panic on the first iteration past the root, causing a crash; in release builds the assertion is compiled out, leading to an unbounded allocation loop until process memory is exhausted. The issue is reachable by any caller of `DnssecDnsHandle` (resolver, recursor, client) built with the `dnssec‑ring` or `dnssec‑aws‑lc‑rs` feature and configured to perform DNSSEC validation. An upstream attacker who can return a crafted response (mismatched SOA owner in authority section) can thus crash a debug build or cause a memory‑exhaustion DoS in a release build. The fix is applied in `hickory-net` 0.26.1.
dailycve form:
Platform: Hickory DNS
Version: 0.25.0‑alpha.3…0.25.2,0.26.0‑alpha.1…0.26.0
Vulnerability : Infinite loop DoS
Severity: Medium
date: 2025‑03‑21
Prediction: Already released (0.26.1)
Analytics under What Undercode Say:
Check installed hickory-proto/hickory-net version cargo tree | grep hickory-proto cargo tree | grep hickory-net Simulate affected loop (conceptual) qname="sub.example.com" soa_owner="malicious.zone" while candidate != soa_owner: candidate = candidate.base_name() hangs at root vec.push(candidate)
// Code snippet triggering the bug (simplified)
while let Some(candidate) = iter.next() {
debug_assert_ne!(candidate, Name::root()); // Panic in debug
candidates.push(candidate);
if candidate == soa_name { break; }
}
Exploit:
- Attacker controls a malicious DNS response with authority section containing an SOA record whose owner name is not an ancestor of the QNAME (e.g., SOA owner =
attacker.com, QNAME =victim.example). - Victim resolver performs DNSSEC validation on a NoData/NXDomain response, triggering NSEC3 closest‑encloser proof.
- The loop walks up from QNAME to root, never matching the unrelated SOA owner, causing infinite allocation.
- Release build exhausts memory; debug build crashes via assertion.
Protection from this CVE:
- Upgrade to `hickory-net` 0.26.1 or later.
- If upgrade impossible, disable DNSSEC validation (remove `dnssec-ring` / `dnssec-aws-lc-rs` features).
- Deploy rate‑limiting and response size checks on upstream resolvers to mitigate memory exhaustion.
- Use debug builds only in isolated testing environments.
Impact:
- Debug builds: immediate panic (crash) on crafted response.
- Release builds: unbounded memory allocation leading to process termination (DoS).
- Affects any Hickory DNS component using DNSSEC validation (resolver, recursor, client).
- Attacker with network position to return malicious responses (e.g., rogue upstream server, MITM) can disrupt service.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
