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

91–100 of 118 posts

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#91

Post by mike_d »

colmmacc wrote: post #89
dc396 wrote: post #51

Earlier quoted context omitted.

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.

I remember tearing my hair out in the pre-2008 era as folks tried to get source-port randomization into Bind. The response was "That's what DNSSEC is for" ... which further supports your narrative. But it's still very damning. Source port randomization, BCP38, and then the 0x20 qname capitalization trick, all turned out to be far more practical mitigations for query-id concerns and others prioritized them. "We really…

Wow this brings up memories. I was at OpenDNS when Dan gave us the heads up.

I'll just leave this here: https://blog.netherlabs.nl/articles/2008/07/09/some-thoughts...

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#92

Post by aspenmayer »

cnst wrote: post #63
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?

In the past, this has been the case. I looked and didn’t see anything on the forum about this news, but it may be too soon to hit the forum? I don’t visit it very often.

https://forum.openwrt.org/t/security-advisory-2021-01-19-1-d...

https://openwrt.org/advisory/2021-01-19-1

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#93

Post by aspenmayer »

tptacek wrote: post #61
yjftsjthsd-h wrote: post #60

Earlier quoted context omitted.

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

I think there were two sets of 7 total vulnerabilities at the same time so they might be perceived as one event? I don’t know for sure, the wording was kind of ambiguous.

https://openwrt.org/advisory/2021-01-19-1

> Dnsmasq has two sets of vulnerabilities, one set of memory corruption issues handling DNSSEC and a second set of issues validating DNS responses. These vulnerabilities could allow an attacker to corrupt memory on the target device and perform cache poisoning attacks against the target environment.

> These vulnerabilities are also tracked as ICS-VU-668462 and referred to as DNSpooq.

https://web.archive.org/web/20250121143405/https://www.jsof-...

> DNSpooq - Kaminsky attack is back!

> 7 new vulnerabilities are being disclosed in common DNS software dnsmasq, reminiscent of 2008 weaknesses in Internet DNS Architecture

Some less breathless sourcing, though I can’t blame OP for being excited in the above post:

https://www.kb.cert.org/vuls/id/434904

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

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#94

Post by JdeBP »

throw0101c wrote: post #87
1vuio0pswjnm7 wrote: post #85

Earlier quoted context omitted.

I use tinydns or nsd You can use unbound I do not use a cache For HTTP I use a localhost-bound TLS forward proxy that has the DNS data in memory; I gather the DNS data in bulk from various sources using various methods; there are no remote DNS queries when I make HTTP requests Unbound is overkill for how I use DNS on the local network

Unbound is a recursive-only resolver. NSD is an authoritative-only resolver. Those are different use cases.

Psst! NSD isn't a "resolver" at all. Traditional DNS terminology is tricky to use (given that what is covered by "resolver" in the RFCs does not match how most people see the system as divided up) but something that does not do the resolving part at all is definitely not a resolver.

* https://jdebp.uk/FGA/dns-server-roles.html

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#95

Post by colmmacc »

mike_d wrote: post #91
colmmacc wrote: post #89

Earlier quoted context omitted.

I remember tearing my hair out in the pre-2008 era as folks tried to get source-port randomization into Bind. The response was "That's what DNSSEC is for" ... which further supports your narrative. But it's still very damning. Source port randomization, BCP38, and then the 0x20 qname capitalization trick, all turned out to be far more practical mitigations for query-id concerns and others prioritized them. "We really…

Wow this brings up memories. I was at OpenDNS when Dan gave us the heads up. I'll just leave this here: https://blog.netherlabs.nl/articles/2008/07/09/some-thoughts...

I found that post so cathartic.

This whole episode reminds me of the story of the Citigroup Center in New York. Years after its completion, an architecture student uncovered that key supports for the building had been done incorrectly and unsafely. It was at risk of collapse in high winds.

The structural engineer worked with the building owner and city to repair the building in secret, before everything was eventually made public. It makes for a story of a folk hero, and it's a great narrative of recovery. Meanwhile the stories of the structural engineers and construction supervisors who weren't woefully negligent and who just quietly built safe buildings go uncelebrated.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#96

Post by 1vuio0pswjnm7 »

throw0101c wrote: post #87
1vuio0pswjnm7 wrote: post #85

Earlier quoted context omitted.

I use tinydns or nsd You can use unbound I do not use a cache For HTTP I use a localhost-bound TLS forward proxy that has the DNS data in memory; I gather the DNS data in bulk from various sources using various methods; there are no remote DNS queries when I make HTTP requests Unbound is overkill for how I use DNS on the local network

Unbound is a recursive-only resolver. NSD is an authoritative-only resolver. Those are different use cases.

"Unbound is a recursive-only resolver"

https://raw.githubusercontent.com/NLnetLabs/unbound/master/d...

https://raw.githubusercontent.com/NLnetLabs/unbound/master/d...

Unbound can also answer queries from data in a text file read into memory at startup, like an authoritative nameserver would; no recursion

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#97

Post by kj4ips »

charcircuit wrote: post #80

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.

I think the idea here is to induce the request to a garbage domain (such as by using it as an email domainpart, to get an SPF and/or DKIM lookup), and forge a response with other names in the additional section. This also somewhat fits with DNSSEC as a mitgation, as the additional section (if not discarded outright) should result in a signature chase by the resolver, which should fail if the targeted domain is dnssecd.

Imagine that:

* I have an evil system at 192.0.2.1

* target at 198.51.100.1 which is an MTA, and is it's own resolver with dnsmasq.

* foobar.com has a nameserver that silently drops any request with a ! in the first label

I first send a mail to 192.51.100.1 claiming to be from bob@"foo!bar.foobar.com"

192.51.100.1 sends a request to the auth ns for foobar.com, which gets droped.

While this is happening, I spam the crud out of 192.51.100.1 from 192.0.2.1 with forged answers for foo!bar.foobar.com that contain additional responses stating deb.debian.org is at 192.0.2.1 with a ttl of months.

If I am lucky dnsmasq caches BOTH the foo!bar.foobar.com response, and the deb.debian.org one, meaning that future accesses to deb.debian.org instead go to my attacker-controlled nastybox.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#98

Post by aspenmayer »

obvious_sock wrote: post #74
tptacek wrote: post #54

Earlier quoted context omitted.

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.

They wrote this:

https://web.archive.org/web/20250729043725/http://sockpuppet...

They clearly seem to have strong feelings about the issue. I don’t, and I don’t know much about it either, so I will not comment further.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#99

Post by tptacek »

aspenmayer wrote: post #98
obvious_sock wrote: post #74

Earlier quoted context omitted.

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.

They wrote this: https://web.archive.org/web/20250729043725/http://sockpuppet... They clearly seem to have strong feelings about the issue. I don’t, and I don’t know much about it either, so I will not comment further.

Why are you archive-linking the post? It's the same place it's always been:

https://sockpuppet.org/blog/2015/01/15/against-dnssec/

You'll notice, I didn't bring DNSSEC into this conversation. I agree: it didn't belong here; DNSSEC has nothing to do with this dnsmasq thing.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#100

Post by aspenmayer »

tptacek wrote: post #99
aspenmayer wrote: post #98

Earlier quoted context omitted.

They wrote this: https://web.archive.org/web/20250729043725/http://sockpuppet... They clearly seem to have strong feelings about the issue. I don’t, and I don’t know much about it either, so I will not comment further.

Why are you archive-linking the post? It's the same place it's always been: https://sockpuppet.org/blog/2015/01/15/against-dnssec/ You'll notice, I didn't bring DNSSEC into this conversation. I agree: it didn't belong here; DNSSEC has nothing to do with this dnsmasq thing.

I archive linked it because you’re in this thread, and you operate that site. I’m removing any conflict of interest by posting it as an archive. I even used IA just to remove any hint of bias I suppose. I don’t want you doing timing attacks against me for posting it here now, or against those who may visit it later, nor do I want you to poison my DNS! I don’t even know enough about these exploits to know if it’s technically possible, but I know that you almost certainly do! I don’t think you would do this, but you’re in a position to do so.

I did not mean it as a slight by doing so. I meant it as an acknowledgment of the sensitive nature of these issues, and part of my work as an amateur journalist and archivist. I say amateur because I do not do this work for personal benefit or gain, but because I like researching and learning myself, and I don’t believe in putting a light I also read by under a bushel.

Here’s another archive:

https://archive.is/UB7xN

While searching for your post on archive.today or whatever their name is, I saw that it had also been archived without a trailing “/“ which redirects to the one with a trailing slash, so depending on how I parse what you said and how you originally posted it and how the redirect is implemented, I could see how that statement might be ambiguous but that kind of thing might be handled by your webserver software. I don’t think that it’s worth mentioning, but you did say it’s always been at that URL, which I don’t dispute. I’ve never known it to be at any other URL.

Post reply on HN