Live data from Hacker News

Critical Cache Poisoning Vulnerability in Dnsmasq

lists.thekelleys.org.uk

111–118 of 118 posts

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#111
post #109

Earlier quoted context omitted.

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, a…

I think you're talking past each other and saying the same thing. There never was a Kaminsky bug. There was no new vulnerability. There was a new attack.

Kaminsky figured out how to build a much more practical way to exploit what was known already. This was very significant, and it's one of the ultimate examples of PoC||GTFO finally triggering action. He deserves a lot of credit.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#112

Earlier quoted context omitted.

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, a…

I think you're talking past each other and saying the same thing. There never was a Kaminsky bug. There was no new vulnerability. There was a new attack. Kaminsky figured out how to build a much more practical way to exploit what was known already. This was very significant, and it's one of the ultimate examples of PoC||GTFO finally triggering action. He deserves a lot of credit.

Sure! I feel like repeated spoofing bids through authority records on responses to random in-bailiwick queries is a novel protocol vulnerability but wouldn't die on the hill of it being instead a new class of attack; we all agree that inadequate randomness is the original sin here.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#113

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.

From https://github.com/NLnetLabs/unbound/issues/132

"Some users of our service (NextDNS), discovered this issue since edgekey.net has been added to some anti-tracker blocklists, resulting in the blocking of large sites like apple.com, airbnb.com, ebay.com when used with unbound."

As Pi-Hole is a modified dnsmasq, NextDNS may be a modified unbound

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#114
post #88
post #84

Earlier quoted context omitted.

Without commenting on the "cleverness", either it doesn't match your description of the data, or their criticism that the interval was cherry picked is spot on. Only one of these can be true.

I appreciate you saying I'm commenting in good faith (I am), but I think you and 'teddyh are overthinking this a bit. All I'm saying is that I find it remarkable that DNSSEC adoption in North America sharply dropped over the course of 2023 --- that, and the fact that the graph tops out at 7MM zones, a big-looking number that is in fact very small. I think it's funny that the graph serves my argument better than 'tedd…

> But really, I think [the graph] ultimately meaningless.

Then why did you use the graph — or at least the information it displays – as the finishing slam dunk point of your post?

> The Verisign graph 'teddyh keeps posting

I “keep posting” it because it’s a good solid counterargument, and it’s also very funny; I originally got the link from you, but as time goes by, the graph keeps proving you wrong.

> why the hell they had it enabled.

Yes, why does a security team have a security feature enabled? It is truly a mystery.

But wait, your main argument, in this post, is that nobody “popular” uses DNSSEC, but do you mean that you actually personally pressure all the popular ones who do use it, to stop? Does not that severely skew your data into irrelevance?

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#115
post #114
post #88

Earlier quoted context omitted.

I appreciate you saying I'm commenting in good faith (I am), but I think you and 'teddyh are overthinking this a bit. All I'm saying is that I find it remarkable that DNSSEC adoption in North America sharply dropped over the course of 2023 --- that, and the fact that the graph tops out at 7MM zones, a big-looking number that is in fact very small. I think it's funny that the graph serves my argument better than 'tedd…

> But really, I think [the graph] ultimately meaningless. Then why did you use the graph — or at least the information it displays – as the finishing slam dunk point of your post? > The Verisign graph 'teddyh keeps posting I “keep posting” it because it’s a good solid counterargument, and it’s also very funny; I originally got the link from you , but as time goes by, the graph keeps proving you wrong. > why the hell…

The answer, regarding the security team, is that it happened over their objection.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#116

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…

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

As an amateur correspondent myself, the correspondents I’m concerned about doing right by would be other visitors to their site who click my link. I’m protecting link-clickers from my source, and my source from others. In this case, I’d view 'tptacek as both as my source, and as a potential operational security concern to me as an investigator due to not knowing them well enough to know their motives, and not knowing who is watching them and everyone who visits their site, which is the larger and more legitimate concern about doing security research, in my view.

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#117

Earlier quoted context omitted.

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

As an amateur correspondent myself, the correspondents I’m concerned about doing right by would be other visitors to their site who click my link. I’m protecting link-clickers from my source, and my source from others. In this case, I’d view 'tptacek as both as my source, and as a potential operational security concern to me as an investigator due to not knowing them well enough to know their motives, and not knowing…

What’s the nature of the security threat?

Re: Critical Cache Poisoning Vulnerability in Dnsmasq

#118

Earlier quoted context omitted.

As an amateur correspondent myself, the correspondents I’m concerned about doing right by would be other visitors to their site who click my link. I’m protecting link-clickers from my source, and my source from others. In this case, I’d view 'tptacek as both as my source, and as a potential operational security concern to me as an investigator due to not knowing them well enough to know their motives, and not knowing…

What’s the nature of the security threat?

Site operators can serve you malware or log your IP address or any manner of other things.
Post reply on HN