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

[Simon Kelley]

I'm confused.

Dnsmasq doesn't wait forever: it waits 40 seconds for a reply in the 
default configuration. If your average time to complete an attack is 
9,469 seconds, something doesn't compute. This may be explained by the 
fact that the time-out of old queries occurs in the query-record 
allocation code path, so if you tested against an instance of dnsmasq 
that was otherwise completely idle, you would see the results you 
report. Introducing any amount of query traffic will disrupt the attack.

Fundamental information such as WHAT VERSION of dnsmasq you tested would 
be useful here.

You missed a trick in your description of the attack: as described the 
attack only allows records with "illegal" characters to be inserted into 
the cache. The attack can be extended to inserting arbitrary records by 
leveraging CNAME records in the replies.

How do you infiltrate the vulnerable queries? This is normally done via 
web pages or similar, but it's not clear to me that that route works 
with the illegal characters.

Simon.


On 8/19/25 13:17, 苗发生 wrote:
> 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
> 
>  1.
> 
>     Dnsmasq forwards queries with special characters (e.g., |~, !, *,
>     _|) to upstream recursive resolvers.
> 
>  2.
> 
>     Some upstream recursive resolvers *silently discard* such malformed
>     queries (no NXDomain/ServFail response).
> 
>  3.
> 
>     Dnsmasq does not validate or detect this situation, and *waits
>     silently*, creating a large *attack window*.
> 
>  4.
> 
>     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 <https://
>     datatracker.ietf.org/doc/html/rfc1034>
> 
>   *
> 
>     RFC2182: https://datatracker.ietf.org/doc/html/rfc2182 <https://
>     datatracker.ietf.org/doc/html/rfc2182>
> 
>   *
> 
>     SADDNS: https://www.saddns.net/ <https://www.saddns.net/>
> 
>   *
> 
>     Tudoor: https://tudoor.net/ <https://tudoor.net/>
> 
>   *
> 
>     PowerDNS Mitigation: https://docs.powerdns.com/recursor/
>     settings.html#spoof-nearmiss-max <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.
> 
> Best regards,
> Fasheng Miao (Tsinghua University)
> Xiang Li (AOSP Laboratory, Nankai University)
> 
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss