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.
Critical Cache Poisoning Vulnerability in Dnsmasq
31–40 of 118 posts
Re: Critical Cache Poisoning Vulnerability in Dnsmasq
#32Earlier quoted context omitted.
I think the issue is that dnsmasq will happily forward requests that contain characters outside the ASCII subset, but the upstream resolver will silently drop them after correctly determining that they're invalid. So the special characters are a way of reliably triggering the silent drop upstream. This is required because it takes many attempts for the brute force attack to succeed.
No. RFC 2181, section 11 states explicitly: "Those [length] restrictions aside, any binary string whatever can be used as the label of any resource record. Dnsmasq should (MUST in RFC 2119 language) forward requests -- it would be a bug not to. The upstream resolver shouldn't (MUST NOT in RFC 2119 language) silently drop them -- it would be a bug if they did. Brute forcing transaction/port ID collisions to poison the…
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 AlterNIC coup attempt. These aren't ID collision attacks at all.
It wasn't until Kaminsky combined transaction IDs with additional data poisoning in 2008 --- an entirely novel attack --- that BIND began randomizing and gave up on holding out for DNSSEC. You'll notice that since 2008 DNS cache poisoning has basically vanished as a real operational security concern. That's not because of DNSSEC.
Re: Critical Cache Poisoning Vulnerability in Dnsmasq
#33Re: Critical Cache Poisoning Vulnerability in Dnsmasq
#34Earlier quoted context omitted.
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 wind…
Novel or not, this seems like it can be actively exploited?
It 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.
Re: Critical Cache Poisoning Vulnerability in Dnsmasq
#35I thought they have accidentally "responsibly disclosed" the vulnerability directly into a public mailing list, but the attached pdf is dated >3 months ago. So assume it's a bit of an inaccurate phrasing. EDIT: nope, the email itself seeks disclosure coordination etc. So yeah, oops.
dnsmasq has no security contact
Sure, but the author publishes their email address on the main dnsmasq page:
Contact.
There is a dnsmasq mailing list at http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss which should be the first location for queries, bugreports, suggestions etc. The list is mirrored, with a search facility, at https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/. You can contact me at simon@thekelleys.org.uk.Re: Critical Cache Poisoning Vulnerability in Dnsmasq
#36Earlier quoted context omitted.
This is why DNSSEC was created.
DNSSEC was created because we needed to put root and gTLD servers in Russia and China (lying authoritatives). Transport security like dnscrypt and DoH were created to solve this problem. DNS cookies are also strong mitigations.
> DNSSEC was created because we needed to put root and gTLD servers in Russia and China (lying authoritatives).
Interesting assertion -- do you have anything to back this up?
While DNSSEC can prevent a name server operator from effectively modifying zone data (at least without the signing key and for resolvers that bother to validate), protecting against an authoritative name server operator from maliciously modifying the zone data in their server was not a significant consideration in any of the IETF/implementation discussions I was in (back in the late 90s, I ran ISC during the development of BIND 9.0 and participated quite heavily in DNS-related working groups).
Transport security obviously only protects the channel of communication. It does nothing for ensuring the authenticity of the data. In order to protect the data so it doesn't matter where the data comes from (authoritative, resolver, off the back of a truck, etc.), you have to take the steps DNSSEC takes. This was recognized as far back as 1993.
Re: Critical Cache Poisoning Vulnerability in Dnsmasq
#37I'm confused. There are no "special characters" in domain names -- they're length-tagged 8-bit clean. Hostnames (as opposed to domain names) are limited by convention to a subset of ASCII, but that shouldn't impact resolver logic. What resolvers silently discard (or do anything else weird with) requests with QNAMES that have non-hostname queries (which aren't "malformed")? The "special character" thing sounds like a…
I can't think of a recursing resolver which discards / disallows non-hostname queries. The only case I've run into, ever, is the stub resolver in the Ignition SCADA platform (running Java on top of the Azul JVM).
(It's on my list to try loading the Python 2 version of dnspython and see if that works. Yeah, Ignition's internal scripting layer is running Jython, at version 2.)
Edit: that's not to say that some middlebox isn't dropping them in the name of "securitah".
Re: Critical Cache Poisoning Vulnerability in Dnsmasq
#38Earlier quoted context omitted.
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 wind…
A nit: we've known about the flaw since 1993 (see https://www.cerias.purdue.edu/assets/pdf/bibtex_archive/94-0... )
If 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.
Re: Critical Cache Poisoning Vulnerability in Dnsmasq
#39Earlier quoted context omitted.
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…
Query ID prediction attacks are not in fact the point of DNSSEC, which will not actually meaningfully address this attack because almost nothing in the DNS is signed.
> 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 DNS root is signed, all generic top-level domains, and the vast majority of country code TLDs are signed. In some countries (e.g., The Netherlands) more than 50% of the zones in their ccTLD are signed. As we've seen empirically, with improved automation/tools and authoritative servers that turn on DNSSEC-signing by default, the percentage will go up.
Re: Critical Cache Poisoning Vulnerability in Dnsmasq
#40Earlier 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.
> The attacker only needs to brute force 32 bits (source port and TxID) to falsify a response and poison the cache. And to be clear: while there are 4.3 billion numbers, the birthday paradox means you only need to spam 65,535 UDP packets to succeed
I've not read the details, but given that things aren't being matched against themselves--
Seems like you need to send ~ 2^16 requests and then ~ 2^16 spoofed replies.