Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Critical Cache Poisoning Vulnerability in Dnsmasq

lists.thekelleys.org.uk

Post reply on HN
Print view View original

41–50 of 118 posts

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#41

Post by tptacek »

dc396 wrote: post #39
tptacek wrote: post #30

Earlier quoted context omitted.

Query ID prediction attacks are not in fact the point of DNSSEC, which will not actually meaningfully address this attack because almost nothing in the DNS is signed.

> Query ID prediction attacks are not in fact the point of DNSSEC Do you deny DNSSEC's goal is to protect DNS data? Do you deny "Query ID prediction attacks" (or more generally, flooding attacks) aim to corrupt DNS data? Do you deny the 16-bit transaction ID allows for effective flooding attacks? As for "almost nothing in the DNS is signed", while it's true the percentage of second-level domains aren't signed, the DN…

I deny that query ID protection was the impetus for the development of DNSSEC and that the earliest advocacy for it as an operational security tool, rather than a (government-funded) design improvement for the entire TCP/IP stack, was about query ID prediction. Like you, I was there at the time; if the NANOG archives go back that far, you'll see me on the threads babbling about this.

This notion of DNSSEC signatures being widespread comes up in every thread about the protocol. Here's a little thingy I threw together because I got tired of typing out the bash "dig" loop to regenerate it in threads:

https://dnssecmenot.fly.dev/

Note that the Tranco list is international, so captures popular zones in places that have automatic (and security-theatric) DNSSEC signatures, as well as amplifying the impact of vendors like Cloudflare who have several different zones in the top 1000. Even with all that included: single digits.

It's been over 30 years of tooling work on DNSSEC --- in recent time intervals, DNSSEC adoption in North America has gone down. Stick a fork in it.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#42

Post by tptacek »

dc396 wrote: post #36
mike_d wrote: post #26

Earlier quoted context omitted.

DNSSEC was created because we needed to put root and gTLD servers in Russia and China (lying authoritatives). Transport security like dnscrypt and DoH were created to solve this problem. DNS cookies are also strong mitigations.

> DNSSEC was created because we needed to put root and gTLD servers in Russia and China (lying authoritatives). Interesting assertion -- do you have anything to back this up? While DNSSEC can prevent a name server operator from effectively modifying zone data (at least without the signing key and for resolvers that bother to validate), protecting against an authoritative name server operator from maliciously modifyin…

Transport security decisively addresses query ID prediction attacks, without requiring forklift upgrades of the entire DNS infrastructure of the Internet, and has the benefit of working for individual sites even when not widely deployed elsewhere. If the concern is transactional attacks like this dnsmasq thing, advocating for DNSSEC instead of DoH/DoT seems like engineering malpractice.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#43

Post by teddyh »

tptacek wrote: post #41
dc396 wrote: post #39

Earlier quoted context omitted.

> Query ID prediction attacks are not in fact the point of DNSSEC Do you deny DNSSEC's goal is to protect DNS data? Do you deny "Query ID prediction attacks" (or more generally, flooding attacks) aim to corrupt DNS data? Do you deny the 16-bit transaction ID allows for effective flooding attacks? As for "almost nothing in the DNS is signed", while it's true the percentage of second-level domains aren't signed, the DN…

I deny that query ID protection was the impetus for the development of DNSSEC and that the earliest advocacy for it as an operational security tool, rather than a (government-funded) design improvement for the entire TCP/IP stack, was about query ID prediction. Like you, I was there at the time; if the NANOG archives go back that far, you'll see me on the threads babbling about this. This notion of DNSSEC signatures…

> in recent time intervals

If you get to pick the specific time interval, you can prove anything.

Why don’t you link the full graph? https://www.verisign.com/en_US/company-information/verisign-...>

(The graph shows that DNSSEC usage is instead increasing since the end of last year, and at that time, its lowest point, was only ever as low as it was back in 2023.)

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#44

Post by dc396 »

tptacek wrote: post #32
dc396 wrote: post #20

Earlier quoted context omitted.

No. RFC 2181, section 11 states explicitly: "Those [length] restrictions aside, any binary string whatever can be used as the label of any resource record. Dnsmasq should (MUST in RFC 2119 language) forward requests -- it would be a bug not to. The upstream resolver shouldn't (MUST NOT in RFC 2119 language) silently drop them -- it would be a bug if they did. Brute forcing transaction/port ID collisions to poison the…

No it didn't. The DNSSEC was a DoD/TIS project meant to make the DNS security model cohere with IPSEC, which at the time people believed would be the standard transport on the Internet. Then, when DNSSEC began to be taken more seriously as an operational security measure, it was because of the difficulty in authenticating additional data records in DNS responses --- the attacks Eugene Kashpureff used during his weird…

It's unclear to me what "make the DNS security model cohere with IPSEC" means. DNSSEC was a direct response to the vulnerabilities identified by a number of folks and documented by Christoph Schuba (https://www.cerias.purdue.edu/assets/pdf/bibtex_archive/94-0...). ISC was hired as a sub-contractor by TIS (I signed the contract for ISC) to implement DNSSEC in BIND specifically to address the transaction ID flood vulnerability.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#45

Post by dc396 »

tptacek wrote: post #42
dc396 wrote: post #36

Earlier quoted context omitted.

> DNSSEC was created because we needed to put root and gTLD servers in Russia and China (lying authoritatives). Interesting assertion -- do you have anything to back this up? While DNSSEC can prevent a name server operator from effectively modifying zone data (at least without the signing key and for resolvers that bother to validate), protecting against an authoritative name server operator from maliciously modifyin…

Transport security decisively addresses query ID prediction attacks, without requiring forklift upgrades of the entire DNS infrastructure of the Internet, and has the benefit of working for individual sites even when not widely deployed elsewhere. If the concern is transactional attacks like this dnsmasq thing, advocating for DNSSEC instead of DoH/DoT seems like engineering malpractice.

Transport security protects the channel, not the data. DNSSEC protects the data so that the channel doesn't matter. Given how the DNS is deployed particularly in enterprise environments, there have been too many times when protecting the channel simply meant data corruption crept in someplace in the sometimes ridiculous chains of forwarders and caches.

Oh, and it doesn't appear dnsmasq supports DoH/DoT forwarding (not positive as I don't use it and haven't looked at the code). It does support DNSSEC.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#46

Post by JdeBP »

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.

Correct. And this isn't surprising to those of us who have been involved in this stuff for years. This is a very well known problem, is not specific to dnsmasq, and not a novel discovery by these people in any way.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#47

Post by JdeBP »

m3047 wrote: post #38
dc396 wrote: post #21

Earlier quoted context omitted.

A nit: we've known about the flaw since 1993 (see https://www.cerias.purdue.edu/assets/pdf/bibtex_archive/94-0... )

If the report is correct, then I think something else is being inferred / implied. If dnsmasq was only caching the ANSWER section, then the only thing which could be poisoned would be the qname. If cache poisoning for arbitrary domain names is being observed, then it would seem that information from the ADDITIONAL or AUTHORITY is being cached as well.

The report and others are calling this "cache poisoning". That's a misnomer. It is not cache poisoning in the long-standing sense of the phrase. It is very simply equally long-standing simple DNS/UDP brute force response forgery.

* https://github.com/Avunit/Dnsmasq-Cache-Poisoning/blob/main/...

They're also relying upon the random source port being allocated from a subset of the available port range, 32768 to 61000 in their default setting.

The claim in the code is that it is Google Public DNS that is failing to respond to queries where the domain name has had an extra label prepended, and that label is 1 character long and the character is a tilde.

Google Public DNS has no such non-response problems with ~.www.example.com in my part of the world.

However, note that they are injecting the forged responses from the very same machine that sent the initial query to dnsmasq, with no delay whatsoever. Whereas it takes Google Public DNS a second or so to look up ~.www.example.com here. So really there's no methodologically sound evidence that Google Public DNS even has the fault with these punctuation characters as claimed.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#48

Post by karel-3d »

dc396 wrote: post #23
teeray wrote: post #6

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

No. The special characters thing is a red herring. All resolvers must handle a lack of response via timeout (particularly since DNS mostly uses UDP). The correct mitigation is turning on DNSSEC. This sort of attack, known since 1993, is why DNSSEC was created.

Better solution that doesn't rely on DNSSEC is use stub resolver that can forward requests on DoH; like unbound or dnsdist.

dnsmasq cannot do this and just forwards UDP to UDP and TCP to TCP. (and doesn't know DoT or DoH)

DoH (and DoT, DNS over TLS) doesn't have this problem, as the whole thing is secured. (Well, this concrete problem might actually be prevented just by using plain old DNS over TCP, but I am not sure about that.)

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#49

Post by JdeBP »

karel-3d wrote: post #31

google's dns resolver 8.8.8.8 correctly resolves the "special character" domains btw; so if you have 8.8.8.8 as your recursive resolver in dnsmasq, this doesn't seem to be an issue.

See https://news.ycombinator.com/item?id=44954517

They're giving Google Public DNS as example of a failure here. Whereas what happens in my testing is that it's a cache miss for Google Public DNS, which takes a little over 1 second to look everything up from cold in my part of the world for ~.www.example.com .

And in that second they have more than enough time, at LAN speeds (since they are injecting the forged responses from the dnsmasq client machine), to send a tonne of forged DNS/UDP responses which are only around a hundred bytes long each.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#50

Post by tonymet »

there are easily 300m+ installs of dnsmasq that will never be updated, because they are buried in forked , unmaintained firmwares on consumer routers.

We truly need a "right to repair" for IOT & consumer networking devices. Any device not receiving monthly security updates should have the firmware keys & source published so the community can take over.

Post reply on HN