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

71–80 of 118 posts

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#71

Post by dc396 »

magicalhippo wrote: post #59
dc396 wrote: post #15

Earlier quoted context omitted.

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…

> AFAIK, dnsmasq supports DNSSEC, so the right answer is to turn on validation. Just disabled DNSSEC in my PiHole. Too many domains which are incorrectly configured leading to non-existing domain errors. And at least as far as I could find, PiHole has no way to selectively disable DNSSEC validation for certain domains.

> Too many domains which are incorrectly configured leading to non-existing domain errors.

That's an interesting and somewhat surprising data point given the use of DNSSEC validation at public resolvers (e.g., 1.1.1.1, 8.8.8.8, etc.). Might be something that would be useful to track by those following DNSSEC deployment.

For selectively disabling DNSSEC validation, I gather PiHole+dnsmasq doesn't support Reverse Trust Anchors (RTA). Unfortunate.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#72

Post by furgot »

tptacek wrote: post #69
furgot wrote: post #66

Earlier quoted context omitted.

I took a look at it. It comports much closer with what GP was saying. It shows adoption being flat as a percentage and rising in absolute terms.

It's still not loading for me but as I recall from the last time this was posted, it showed 2023 with a 15% (!) drop in North American signed zones, and us still well below the peak --- that peak being less than 1% of all North American zones.

https://web.archive.org/web/20250720163940/https://www.veris...

There is a 15% drop like you describe, but as the other commenter said, it doesn't show usage falling for the past year (as you had implied).

I have no dog in this race, I don't care about DNSSEC. If you can't access the page, that's your business. But it bothers me that you would assert this data agrees with your point without even looking at it. That's pretty uncharitable.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#73

Post by karel-3d »

JdeBP wrote: post #70
karel-3d wrote: post #65

Earlier quoted context omitted.

is this "avunit" someone from the reporting team? it seems created few hours ago, and it's using 8.8.8.8 which does not timeout as they claim; and the crux of the attack there is just that local UDP is faster than remote UDP edit: the only github account of the reporter is github.com/idealeer . this avunit is something random

Hint: Look at the mailing list post and the repository's "About" blurb. There are probably only 2 people in the world who want their own new coined name for this old hat stuff to stick. (-: They put their demonstration code up and sent out their mailing list post just over 130 minutes apart.

I think someone misunderstood the mailing list post and made a PoC. Because google's 8.8.8.8 does NOT timeout...

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#74

Post by obvious_sock »

tptacek wrote: post #54
dc396 wrote: post #45

Earlier quoted context omitted.

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 (no…

At multiple points on this thread you tell other people here that DNSSEC is the correct solution both for this dnsmasq security issue and for query ID prediction attacks generally. All of those are channel attacks that have nothing to do with the authenticity of DNS records. I happen to think DNSSEC, writ large, is also engineering malpractice, but when I use that term just upthread, I was referring to your insistenc…

You're all over this thread and every other DNS thread, even the ones that don't have much to do with DNSSEC, constantly complaining about DNSSEC. Why?

Last time you were arguing DNSSEC wouldn't solve BGP hijacks because whoever was hijacking the DNS server would just hijack the web server instead.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#75

Post by obvious_sock »

dc396 wrote: post #68
philodeon wrote: post #52

Earlier quoted context omitted.

DNSSEC most certainly does _not_ protect any data that an end user cares about.

So you're saying the end user does not care about the data (IP addresses, mail servers, etc.) for the domain names they're trying to reach and they'd be perfectly happy (say) going to the IP address of an attacker controlled website instead of their bank? Interesting position.

They're being contrarian and pedantic for the sake of being contrarian and pedantic. No, DNSSEC doesn't protect anything the user cares about because it protects IP addresses and the user doesn't care about IP addresses. Yes, DNSSEC protects the user because it blocks one vector by which they can be redirected to a phishing site.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#76

Post by teddyh »

furgot wrote: post #72
tptacek wrote: post #69

Earlier quoted context omitted.

It's still not loading for me but as I recall from the last time this was posted, it showed 2023 with a 15% (!) drop in North American signed zones, and us still well below the peak --- that peak being less than 1% of all North American zones.

https://web.archive.org/web/20250720163940/https://www.veris... There is a 15% drop like you describe, but as the other commenter said, it doesn't show usage falling for the past year (as you had implied). I have no dog in this race, I don't care about DNSSEC. If you can't access the page, that's your business. But it bothers me that you would assert this data agrees with your point without even looking at it. That's…

> it doesn't show usage falling for the past year (as you had said).

Note how he cleverly did not say that; he said “in recent time intervals”. And you can certainly count the time from 2023-2024 as being “recent”. He technically was not wrong, and technically did not lie.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#77

Post by furgot »

teddyh wrote: post #76
furgot wrote: post #72

Earlier quoted context omitted.

https://web.archive.org/web/20250720163940/https://www.veris... There is a 15% drop like you describe, but as the other commenter said, it doesn't show usage falling for the past year (as you had implied). I have no dog in this race, I don't care about DNSSEC. If you can't access the page, that's your business. But it bothers me that you would assert this data agrees with your point without even looking at it. That's…

> it doesn't show usage falling for the past year (as you had said). Note how he cleverly did not say that; he said “in recent time intervals”. And you can certainly count the time from 2023-2024 as being “recent”. He technically was not wrong, and technically did not lie.

Alright. I've edited my comment to "implied." I'm assuming he's engaging in reasonably good faith and would temper his statement if he learned that adoption has been rising for a year. If I believed otherwise I wouldn't bother engaging at all.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#78

Post by aaronmdjones »

dc396 wrote: post #33
supernetworks wrote: post #25

Earlier quoted context omitted.

encrypted DNS goes a long way towards mitigating this as well.

Does dnsmasq have a way to forward via DOH/DOT? (I've no idea: I don't use it myself)

Not at the moment; to achieve this, you typically put it behind something like dnsproxy [1][2].

I have done this on my router, along with a couple firewall rules to prevent plaintext DNS queries leaking out of the WAN port. dnsmasq is configured to talk to dnsproxy, and dnsproxy is configured to use DNS over TLS with 1.1.1.1 [3]

[1] https://github.com/AdguardTeam/dnsproxy

[2] https://openwrt.org/docs/guide-user/services/dns/dot_dnsmasq...

[3] https://news.ycombinator.com/item?id=44429118

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#79

Post by noinsight »

1vuio0pswjnm7 wrote: post #55

Wishful thinking: OpenWRT userland can now replace dnsmasq with two separate programs. The DHCP server, odhcpd, is already included (for DHCP6). They just need to write the DNS software. I always disable/remove dnsmasq when I can. Compared to the alternatives, I have never liked it. This is at least the second major dnsmasq coding mistake that has been published in recent memory.^1 Pi-Hole was based on dnsmasq which…

You can just use Unbound for DNS.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#80

Post by charcircuit »

How would this even be exploited? What software would try and use such an invalid domain? It would always fail, so such a thing would never be shipped to end users. The only thing I can think of is some kind of social engineering attack, but at that point I feel like you can just use a normal attacker controlled domain instead of trying to do something special.
Post reply on HN