3 ms·
Yes. RFC 2181 § 11 explicitly contradicts this report. That said, I should point out that there is nowadays a loophole for special-casing labels that begin wi
by JdeBP 1y ago
Yes. RFC 2181 § 11 explicitly contradicts this report.
That said, I should point out that there is nowadays a loophole for special-casing labels that begin with underscore, called out by the SVCB document. The loophole does not allow for dropping the client requests, though.
On the gripping hand, all that this report boils down to is a rediscovery that if the queried server does not answer immediately, there's a window for an attacker with access to the path between client and server (or at least the ability to blindly route packets into that path with forged source addresses) to inject forged responses; that the message ID and random port number system is woefully inadequate for making brute forcing hard at even late 1990s network speeds; and that most of the mitigation techniques for forgery (including the PowerDNS one called out in this report) are useless if the attacker can see the query packet go by in the first place. The right answer is proper cryptography, not nonsense about punctuation characters that are supposedly "malformed".
Something we have known since 2002.
* https://cr.yp.to/djbdns/forgery.html https://cr.yp.to/djbdns/forgery.html
The DNS protocol is a terrible protocol. This report is not some novel discovery.
- dc396 1y agoA nit: we've known about the flaw since 1993 (see https://www.cerias.purdue.edu/assets/pdf/bibtex_archive/94-05.pdf https://www.cerias.purdue.edu/assets/pdf/bibtex_archive/94-0...)
- m3047 1y agoIf 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.
- JdeBP 1y agoThe 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/local-poc.py 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 in their default setting. The claim in the code is that it is Google Public DNS that is failing to respond to queries where the domain name has had an extra label prepended, and that label is 1 character long and the character is a tilde. Google Public DNS has no such non-response problems with ~.www.example.com in my part of the world. However, note that they are injecting the forged responses from the very same machine that sent the initial query to dnsmasq, with no delay whatsoever. Whereas it takes Google Public DNS a second or so to look up ~.www.example.com here. So really there's no methodologically sound evidence that Google Public DNS even has the fault with these punctuation characters as claimed.
- karel-3d 1y agois 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
- JdeBP 1y agoHint: 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.
- karel-3d 1y agoI think someone misunderstood the mailing list post and made a PoC. Because google's 8.8.8.8 does NOT timeout...
- supernetworks 1y agoNovel or not, this seems like it can be actively exploited?
- dc396 1y agoSure. As it is a fundamental flaw in the DNS protocol itself, it is not unique to dnsmasq (it applies to any resolver).
- tptacek 1y agoIt can be actively exploited in the same way that TCP initial sequence numbers can be exploited: when something else goes horribly wrong in the protocol stack. Contra the claim across the thread that the fundamental fix to this problem is DNSSEC (which is never going to happen), the real fix for all this stuff is not to trust this layer of the TCP/IP stack for authentication in the first place: you do cryptography, at the transport layer (not in the name lookup) so that IP address spoofing doesn't matter in the first place.