[Dnsmasq-discuss] [Security Report] Critical Cache Poisoning Vulnerability in Dnsmasq

[David Conrad]

Hi,

You appear to have rediscovered the transaction ID flaw in the DNS protocol, first discussed in 1993 (see https://www.cerias.purdue.edu/assets/pdf/bibtex_archive/94-05.pdf for a full writeup).  As far as I can tell this has nothing to do with “special characters” (which don’t exist in domain names, see RFC 2181, section 11). Hostnames, which are a subset of domain names (see RFC 1123) do have limitations on what characters are permitted, but that shouldn’t (MUST NOT in RFC 2119 language) impact resolution. If there are upstream resolvers that are silently dropping those queries, that would be a bug in those resolvers. 

This protocol flaw, which necessarily exists in all DNS resolver implementations, was the reason DNSSEC was created.

I believe dnsmasq is doing the right thing in forwarding queries with arbitrary values as QNAMEs. Handling of dropped queries/responses is required for all resolvers, particularly given DNS mostly uses UDP. I believe dnsmasq has options (—fast-dns-retry) to handle dropped queries/responses when the originating client doesn’t do so effectively.

The correct mitigation for this issue is turning on DNSSEC (I believe via “—dnssec”).

Regards,
-drc
> Dear Dnsmasq Security Team,
> 
> We would like to responsibly disclose a critical cache poisoning vulnerability affecting the Dnsmasq DNS software. The issue allows attackers to inject arbitrary malicious DNS resource records and poison domain names without requiring advanced techniques, only by leveraging a single special character.
> 
> Report Summary
> 
> Vulnerability Type: Logic flaw in cache poisoning defense
> 
> Affected Software: Dnsmasq (all versions)
> 
> Severity: Critical
> 
> Exploitability: Off-path attackers can brute-force TxID and source port within an extended attack window
> 
> Attack Name:SHAR Attack (Single-character Hijack via ASCII Resolver-silence)
> 
> Success Rate: 20/20 successful attack attempts
> 
> Average Execution Time: ~9,469 seconds
> 
> Key Findings
> 
> Dnsmasq forwards queries with special characters (e.g., ~, !, *, _) to upstream recursive resolvers.
> 
> Some upstream recursive resolvers silently discard such malformed queries (no NXDomain/ServFail response).
> 
> Dnsmasq does not validate or detect this situation, and waits silently, creating a large attack window.
> 
> During this window, attackers can brute-force TxID (16-bit) and source port (16-bit) with a high probability of success (birthday paradox effect).
> 
> Security Impact
> 
> Attackers can poison any cached domain name in Dnsmasq.
> 
> Attack is feasible off-path without IP fragmentation or side-channels.
> 
> This vulnerability also amplifies known cache poisoning attacks such as SADDNS and Tudoor.
> 
> Undermines DNS security assumptions that resolver silence is benign.
> 
> Proof of Concept
> 
> We tested against a real domain (viticm.com) and demonstrated that queries containing certain crafted characters lead to upstream silence. This allowed us to reliably poison Dnsmasq caches in all trials.
> 
> Suggested Mitigation
> 
> We recommend adding:
> 
> Detection mechanisms when upstream resolvers remain silent.
> 
> Rate limiting and spoof-detection techniques, similar to those in PowerDNS.
> 
> References
> 
> RFC1034: https://datatracker.ietf.org/doc/html/rfc1034
> 
> RFC2182: https://datatracker.ietf.org/doc/html/rfc2182
> 
> SADDNS: https://www.saddns.net/
> 
> Tudoor: https://tudoor.net/
> 
> PowerDNS Mitigation: https://docs.powerdns.com/recursor/settings.html#spoof-nearmiss-max
> 
> We believe this issue requires urgent attention due to the wide deployment of Dnsmasq. Please let us know how we can assist further with coordinated disclosure, additional PoC details, or testing.
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20250819/0aa541cd/attachment.htm>