Critical Cache Poisoning Vulnerability in Dnsmasq

Many router firmwares have dnsmasq for DNS but may never be upgraded?

There are a number of other DNS servers which are not written in C, which support transport-secured DNS like DoH (DNS-over-HTTP), DoT, and DoQ; but do they correctly handle this malformed input?

From the mailing list disclosure, which doesn't yet have a CVE FWIU? https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/20... :

  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.

[...]

  We recommend adding:

  Detection mechanisms when upstream resolvers remain silent.

  Rate limiting and spoof-detection techniques, similar to those in PowerDNS

> PowerDNS Mitigation: https://docs.powerdns.com/recursor/settings.html#spoof-nearm...

  spoof-nearmiss-max

I thought they have accidentally "responsibly disclosed" the vulnerability directly into a public mailing list, but the attached pdf is dated >3 months ago.

So assume it's a bit of an inaccurate phrasing.

EDIT: nope, the email itself seeks disclosure coordination etc. So yeah, oops.

Would an effective mitigation be to drop inbound DNS queries that match those special characters using DPI?

I think the issue is that dnsmasq will happily forward requests that contain characters outside the ASCII subset, but the upstream resolver will silently drop them after correctly determining that they're invalid. So the special characters are a way of reliably triggering the silent drop upstream. This is required because it takes many attempts for the brute force attack to succeed.

Dnsmasq forwards invalid requests (containing invalid characters) to the resolver. The resolver silently ignores these requests.

However, Dnsmasq continues to wait for a response. The attacker only needs to brute force 32 bits (source port and TxID) to falsify a response and poison the cache.

The correct and expected behaviour of Dnsmasq would have been not to forward invalid requests to the resolver.