Critical Cache Poisoning Vulnerability in Dnsmasq

Post by supernetworks » Tue, Aug 19, 2025, 3:20 PM UTC

JdeBP wrote: post #18

dc396 wrote: post #5

I'm confused. There are no "special characters" in domain names -- they're length-tagged 8-bit clean. Hostnames (as opposed to domain names) are limited by convention to a subset of ASCII, but that shouldn't impact resolver logic. What resolvers silently discard (or do anything else weird with) requests with QNAMES that have non-hostname queries (which aren't "malformed")? The "special character" thing sounds like a…

Yes. RFC 2181 § 11 explicitly contradicts this report. That said, I should point out that there is nowadays a loophole for special-casing labels that begin with underscore, called out by the SVCB document. The loophole does not allow for dropping the client requests, though. On the gripping hand, all that this report boils down to is a rediscovery that if the queried server does not answer immediately, there's a wind…

Post by dc396 » Tue, Aug 19, 2025, 3:29 PM UTC

supernetworks wrote: post #22

JdeBP wrote: post #18

Earlier quoted context omitted.

Yes. RFC 2181 § 11 explicitly contradicts this report. That said, I should point out that there is nowadays a loophole for special-casing labels that begin with underscore, called out by the SVCB document. The loophole does not allow for dropping the client requests, though. On the gripping hand, all that this report boils down to is a rediscovery that if the queried server does not answer immediately, there's a wind…

Novel or not, this seems like it can be actively exploited?

Post by mike_d » Tue, Aug 19, 2025, 3:57 PM UTC

dc396 wrote: post #17

rwmj wrote: post #14

A bit surprising that the transaction ID is only 16 bits. Presumably the source port doesn't even need to be guessed if someone is on the path between dnsmasq and the upstream DNS server.

This is why DNSSEC was created.

Post by karel-3d » Tue, Aug 19, 2025, 4:01 PM UTC

forkerenok wrote: post #4

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.

Post by tptacek » Tue, Aug 19, 2025, 4:03 PM UTC

dc396 wrote: post #15

Beretta_Vexee wrote: post #10

Earlier quoted context omitted.

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.

No. They aren't "invalid requests". You can put literally anything in a domain name (see RFC 2181, section 11) and the upstream should respond. I'm curious what resolvers are dropping these requests. The correct behavior is for dnsmasq to forward requests to the upstream regardless of the content of the QNAME. If dnsmasq doesn't get a response back in some reasonable amount of time, it should (probably) return SERVFA…