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

51–60 of 118 posts

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#51

Post by dc396 »

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…

I guess you and I were at different meetings. I was at meetings at NSF with TIS folks that resulted in funding for DNSSEC implementation in BIND where the presentation focused on the 16-bit transaction field (and included a live demonstration), so I'll stand by my view that the point of DNSSEC was to address that particular flaw.

In any event, that's a nice site that provides useful stats.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#52

Post by philodeon »

dc396 wrote: post #45
tptacek wrote: post #42

Earlier quoted context omitted.

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

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

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#53

Post by mzajc »

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.

Same for 1.1.1.1 and 9.9.9.9. My ISP's resolver also returns NXDOMAIN immediately. Quick way to test:

  dig 'test~!*_' @resolver-ip

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#54

Post by tptacek »

dc396 wrote: post #45
tptacek wrote: post #42

Earlier quoted context omitted.

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 (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 insistence that people deploy a top-down data authentication mechanism in order to resolve a trivial transaction spoofing attack, given the availability of multiple existing tools that decisively address those kinds of problems without any of the expense and coordination required for DNSSEC.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#55

Post by 1vuio0pswjnm7 »

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 turned me off that as well.

1.

https://www.jsof-tech.com/wp-content/uploads/2021/01/DNSpooq...

https://www.cisa.gov/news-events/ics-advisories/icsa-21-019-...

https://www.malwarebytes.com/blog/news/2021/01/dnspooq-the-b...

https://web.archive.org/web/20210119133618if_/https://www.js...

https://seclists.org/oss-sec/2021/q1/49

Anyway, never gonna happen. Just wishful thinking.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#56

Post by tptacek »

dc396 wrote: post #44
tptacek wrote: post #32

Earlier quoted context omitted.

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

I have around here somewhere the mail spool of the mailing list contemporaneous to the time and stand by my interpretation (the dns-security@tis.com list) --- I also worked "at TIS" (at Network Associates), writing the DNS security checks for NAI's security scanner (which included serverside components that actively exploited all these attacks) --- but that was a year or two after the contract, as I understand it. The COAST paper you're citing predates practical exploitation of QID prediction by 2 years, and the most significant DNS spoofing exploits of the time (the ones Kashpureff used) did not involve QID prediction.

I think the Kremlinology here is super interesting and I'm happy to keep digging with you, but again: DNS spoofing was a live issue for a couple months in 1995, when it was resolved by QID randomization in BIND (and then QID+port randomization in djbdns), and then a live issue again for about a month and a half in 2008, when it was finally resolved by QID+port randomization in BIND. DNSSEC had nothing at all to do with it.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#57

Post by tptacek »

dc396 wrote: post #51
tptacek wrote: post #41

Earlier quoted context omitted.

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…

I guess you and I were at different meetings. I was at meetings at NSF with TIS folks that resulted in funding for DNSSEC implementation in BIND where the presentation focused on the 16-bit transaction field (and included a live demonstration), so I'll stand by my view that the point of DNSSEC was to address that particular flaw. In any event, that's a nice site that provides useful stats.

Thanks! For what it's worth: I think hashing out the origins of DNSSEC is a super interesting conversation to have, and I'm happy you're here pushing back on what I'm saying (the truth is going to be somewhere in between the two of us).

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#58

Post by tptacek »

teddyh wrote: post #43
tptacek wrote: post #41

Earlier quoted context omitted.

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

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!

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#59

Post by magicalhippo »

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…

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

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#60

Post by yjftsjthsd-h »

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?

Post reply on HN