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

61–70 of 118 posts

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#61

Post by tptacek »

yjftsjthsd-h wrote: post #60
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…

> This is at least the second major dnsmasq coding mistake that has been published in recent memory. What was the first?

There was like a memory corruption RCE not long ago.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#62

Post by karel-3d »

JdeBP wrote: post #49
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 respo…

so the special characters are a red herring? and all they are doing is sending UDP responses locally faster than the recursive resolver?

I cannot believe this is true because that would be too dumb

edit: I don't see how is the avunit github related to the report. I don't think it is?

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#63

Post by cnst »

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…

Would OpenWrt even be vulnerable in the first place?

If you're using dnsmasq behind NAT or a stateful firewall, how would an attacker be able to access the service in the first place?

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#64

Post by dc396 »

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…

While the functionality/complexity of dnsmasq makes me nervous and I use it (I don't have a use case for it), it isn't clear to me that dnsmasq is doing anything wrong in this particular case.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#65

Post by karel-3d »

JdeBP wrote: post #47
m3047 wrote: post #38

Earlier quoted context omitted.

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 i…

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

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#66

Post by furgot »

tptacek wrote: post #58
teddyh wrote: post #43

Earlier quoted context omitted.

> 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.)

That page doesn't load right now, but when it does, I encourage people to click through to it and see what I was talking about. Thanks for sourcing it for me!

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.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#67

Post by dc396 »

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…

I'm unclear there is a security issue with dnsmasq -- maybe leaving a transaction alive too long (but then again, what does "too long" mean these days?). However, I haven't looked into the "vulnerability" referenced to be sure (the "malformed name" aspect of the report doesn't fill me with confidence).

I contend that creating signatures over the data at the sending side and then validating those signatures at the receiving end is superior protection to encrypting the channel over which the data is transmitted. Protecting the data is end-to-end. Protecting the channel is hop-by-hop. If you could ensure that the client speaks directly to the authoritative(s), the protection would be equivalent. But that's not how the DNS is operationally deployed (dnsmasq is a perfect example: forwarders really shouldn't exist).

I would agree with you that operationally, DNSSEC deployment is lacking (i.e., water is wet) and the requirement for both the authoritative side and resolving side to simultaneously implement is a (very) heavy lift. However, even your Tranco stats show that there are pockets of non-trivial deployment (e.g., governments) and I believe the trend is increased deployment over the long term globally.

Fortunately, it's not either/or. I personally prefer DoT/DoH to a trusted (i.e., that I run) resolver that DNSSEC validates. Unfortunately, as dnsmasq doesn't appear to implement forwarding to DoT/DoH resolvers, you're left with DNSSEC or not using dnsmasq (which is what I gather you're recommending).

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#68

Post by dc396 »

philodeon wrote: post #52
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…

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.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#69

Post by tptacek »

furgot wrote: post #66
tptacek wrote: post #58

Earlier quoted context omitted.

That page doesn't load right now, but when it does, I encourage people to click through to it and see what I was talking about. Thanks for sourcing it for me!

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.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#70

Post by JdeBP »

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

Earlier quoted context omitted.

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 i…

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.
Post reply on HN