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

101–110 of 118 posts

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#101

Post by tptacek »

aspenmayer wrote: post #100
tptacek wrote: post #99

Earlier quoted context omitted.

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

I'm just giving you shit. Thanks for posting it. You're not wrong: I have longstanding strong feelings (much further back than that post) about DNSSEC, both because I had to implement it, and because I remember it being used as an excuse not to randomize DNS requests. Also: I tilt at a lot of windmills, and this particular evil giant is on the verge of collapsing!

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#102

Post by aspenmayer »

tptacek wrote: post #101
aspenmayer wrote: post #100

Earlier quoted context omitted.

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

I'm just giving you shit. Thanks for posting it. You're not wrong: I have longstanding strong feelings (much further back than that post) about DNSSEC, both because I had to implement it, and because I remember it being used as an excuse not to randomize DNS requests. Also: I tilt at a lot of windmills, and this particular evil giant is on the verge of collapsing!

> Also: I tilt at a lot of windmills, and this particular evil giant is on the verge of collapsing!

Is it largely being replaced by EDNS, or what?

Now that we have that giant out of the way, what’s the next one you’re tilting at?

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#103

Post by tptacek »

aspenmayer wrote: post #102
tptacek wrote: post #101

Earlier quoted context omitted.

I'm just giving you shit. Thanks for posting it. You're not wrong: I have longstanding strong feelings (much further back than that post) about DNSSEC, both because I had to implement it, and because I remember it being used as an excuse not to randomize DNS requests. Also: I tilt at a lot of windmills, and this particular evil giant is on the verge of collapsing!

> Also: I tilt at a lot of windmills, and this particular evil giant is on the verge of collapsing! Is it largely being replaced by EDNS, or what? Now that we have that giant out of the way, what’s the next one you’re tilting at?

Single family zoning.

I think there's a lot of reasons why DNSSEC is moribund. It was a necessary accompaniment to IPSEC back in the mid-1990s when everybody assumed we'd be all v6 all IPSEC by 2000. Then Kashpureff's bailiwick attack happened, and we got this:

https://mailman.nanog.org/pipermail/nanog/1997-July/122606.h...

... but the bailiwick caching behavior was a straight-up bug, and rand(3) was enough to make QID spoofing more annoying to exploit than it was worth. Something like 5 years later we had the birthday attack, but I don't recall anybody taking it especially seriously --- maybe because at roughly the same time, DNSSEC was going through the "typecode roll" that took us from DNSSEC to DNSSECbis, and nobody was confident about pushing DNSSEC at that point; the TLDs weren't even signed.

Then 5 years after that we got Kaminsky. There's a spark of interest in DNSSEC after that... but all the vendors who hadn't already adopted DJB's randomization immediately did, and Kaminsky's attack stopped mattering.

By this point I think it was clear to everybody that protecting transactions wasn't going to be the motivating use case for DNSSEC, so people shifted to DANE: using DNSSEC as a global PKI to replace the X.509 certificate authorities. But DANE flat-out never worked; you couldn't deploy it in a way that was resilient against downgrades, so there was simply no point.

Then Google and Mozilla killed several of the largest CAs, and used their market power to force CT on the remaining (and thoroughly cowed) CAs. And LetsEncrypt happened. So modern concern over replacing the X.509 CAs registers somewhere in seriousness alongside Linux on the Desktop.

People try to come up with increasingly exotic reasons why we'll be forced to use DNSSEC with the WebPKI; it's not so much DANE anymore as it is resilience against BGP attacks and validation of ACME DNS challenges. It's all pretty unserious.

Meanwhile: unlike DNSSEC, which has seen only marginal adoption over 30 years, DoH has caught fire. Within the next 5 years, it's not unlikely that we'll come up with some deployment scenario whereby CAs can use DoH to secure lookups all the way to authority servers. We'll see. It's a lot more likely than a global deployment of DNSSEC.

There's just no reason for it to exist anymore.

I have a lot more reasons than this not to like DNSSEC --- I actively dislike it as a protocol and as a cryptosystem. But those are just my takes, and what I've related in this comment is I think pretty much objectively verifiable.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#104

Post by otterley »

aspenmayer wrote: post #100
tptacek wrote: post #99

Earlier quoted context omitted.

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

There’s no conflict of interest associated with pointing to your correspondent’s own website, or one referring to their own.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#105

Post by charcircuit »

kj4ips wrote: post #97
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 dnssec…

That's surprising to me that DNS records received for domains not queried for can be set. I would expect DNS to require a query before being able to handle a response. I don't know why such behavior would ever be wanted.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#106

Post by JdeBP »

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

Just remember that it was never a "Kaminsky Bug" in the first place, and there's a whole community of people who had spotted it years before, who had been pooh-poohed and naysayed by BIND people for years about all this.

* https://dns.cr.yp.narkive.com/fAkXdiM0/update-on-the-djb-bug...

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#107

Post by tptacek »

JdeBP wrote: post #106
mike_d wrote: post #91

Earlier quoted context omitted.

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

Just remember that it was never a "Kaminsky Bug" in the first place, and there's a whole community of people who had spotted it years before, who had been pooh-poohed and naysayed by BIND people for years about all this. * https://dns.cr.yp.narkive.com/fAkXdiM0/update-on-the-djb-bug...

I'd be interested in more reliable sourcing for this claim.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#108

Post by ectospheno »

charcircuit wrote: post #105
kj4ips wrote: post #97

Earlier quoted context omitted.

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

That's surprising to me that DNS records received for domains not queried for can be set. I would expect DNS to require a query before being able to handle a response. I don't know why such behavior would ever be wanted.

RFC 2181 section 5.4.1 covers this a bit. Search for “additional data section”. So since at least 1997 you shouldn’t trust it. Subsequent rfcs also reference this topic a bit.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#109

Post by JdeBP »

tptacek wrote: post #107
JdeBP wrote: post #106

Earlier quoted context omitted.

Just remember that it was never a "Kaminsky Bug" in the first place, and there's a whole community of people who had spotted it years before, who had been pooh-poohed and naysayed by BIND people for years about all this. * https://dns.cr.yp.narkive.com/fAkXdiM0/update-on-the-djb-bug...

I'd be interested in more reliable sourcing for this claim.

M. Anderson was not wrong in this particular case. Indeed, Bernstein xyrself was on the bind-users mailing list discussing the vulnerability to packet forgery, just after the turn of the 21st century. The reason that the famous djbdns security guarantee excluded forgery is that it was well known then that there were basic protocol problems in this area, and basically it was speed and luck that had been keeping them at bay.

It should tell you something that even I, who am and was on a different continent to all of these people, knew about this stuff well before it became an ISC press release. I'd like to say that it was Paul Jarc who went into the consequences of what one could do with response forgeries, on Bernstein's dns mailing list, but I might be remembering the wrong person. Certainly, list regulars had read Bernstein's discussion of DNS security and realized the implications.

The logical consequences of being able to forge whatever response one likes were readily apparent. Bert Hubert noted publicly at the time of the Kaminsky announcements that xe had been not only aware of this for years,

* https://mailman.powerdns.com/pipermail/pdns-users/2008-July/...

but had even been trying to get an IETF draft approved about port+ID randomization, and bailiwick checking, acknowledging the factors involved and promoting the adoption of the well-known mitigations as mandatory.

Amusingly for the instant case of researchers rediscovering the well-known, you can read M. Hubert's first draft from a year and a half before the ISC press release, and it lays out there exactly what I laid out here elsewhere in this very discussion, about a query to Google Public DNS taking a second from cold to answer for ~.www.example.com and that being more than enough time to send a tonne of forged responses at 2006 network speeds.

* https://datatracker.ietf.org/doc/html/draft-ietf-dnsext-forg...

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#110

Post by tptacek »

JdeBP wrote: post #109
tptacek wrote: post #107

Earlier quoted context omitted.

I'd be interested in more reliable sourcing for this claim.

M. Anderson was not wrong in this particular case. Indeed, Bernstein xyrself was on the bind-users mailing list discussing the vulnerability to packet forgery, just after the turn of the 21st century. The reason that the famous djbdns security guarantee excluded forgery is that it was well known then that there were basic protocol problems in this area, and basically it was speed and luck that had been keeping them a…

This draft does not describe Kaminsky's attack; it describes the vanilla Birthday Attack from 2002. Kaminsky's discovery was the combination of random bogus query names and spoofed authority sections, which dramatically expanded the number of "bites at the apple" attackers had to match query IDs from spoofed responses to original requests.

Daniel Bernstein was right in the late 1990s about randomizing source ports, and randomization did effectively foreclose on Kaminsky's vulnerability. But I'm unaware of a cite in which he outlines Kaminsky's attack in any detail. His djbdns countermeasure was a sensible response to BIND's QID prediction problem, which Paul Vixie was reluctant to fix because the QID only gave him 16 bits of randomness to work with.

I'm not saying you're certainly wrong that other people had discovered the random-name / authority spoofing attack Kaminsky came up with, only that I'm intimately familiar with this whole line of security research and I'm unaware of a source laying it out --- I am thus skeptical of the claim.

Post reply on HN