Many router firmwares have dnsmasq for DNS but may never be upgraded?
There are a number of other DNS servers which are not written in C, which support transport-secured DNS like DoH (DNS-over-HTTP), DoT, and DoQ; but do they correctly handle this malformed input?
Dnsmasq forwards queries with special characters (e.g., ~, !, *, _) to upstream recursive resolvers.
Some upstream recursive resolvers silently discard such malformed queries (no NXDomain/ServFail response).
Dnsmasq does not validate or detect this situation, and waits silently, creating a large attack window.
During this window, attackers can brute-force TxID (16-bit) and source port (16-bit) with a high probability of success (birthday paradox effect).
Security Impact
Attackers can poison any cached domain name in Dnsmasq.
[...]
We recommend adding:
Detection mechanisms when upstream resolvers remain silent.
Rate limiting and spoof-detection techniques, similar to those in PowerDNS
I'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 red herring: IIUC, dnsmasq isn't dealing with lost responses correctly, creating a window for birthday collision attack?
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.
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 SERVFAIL to its client.
Further, DNS mostly uses UDP which is unreliable -- all DNS clients must deal with the query or response being lost. Dnsmasq's timeouts might be overly long (I didn't bother to check), but this is a minor configuration issue.
This sounds like the (well known) birthday attack, the defense of which is precisely the point of DNSSEC. AFAIK, dnsmasq supports DNSSEC, so the right answer is to turn on validation.
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".
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".
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.
"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 cache is a long known flaw in the DNS protocol (it has been known since at least 1993) that led to the creation of DNSSEC.
Your hostnames with emojis are violating RFC 1123 as modified by RFC 2181. But as I said, it is a convention and, of course, RFCs aren't laws of physics, you can violate them at the risk of potential interoperability failure (e.g., maybe what this disclosure stumbled on?)
I 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.
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.
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 turned me off that as well.
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.
While the functionality/complexity of dnsmasq makes me nervous and I use it (I don't have a use case for it), it isn't clear to me that dnsmasq is doing anything wrong in this particular case.
Unbound unfortunately has some a pair of issues ([1][2]) that in some situations (adblocking, source address based dns selection) can make it a less than optimal match for some use-cases.
"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
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
A bit surprising that the transaction ID is only 16 bits. Presumably the source port doesn't even need to be guessed if someone is on the path between dnsmasq and the upstream DNS server.
Correct. And this isn't surprising to those of us who have been involved in this stuff for years. This is a very well known problem, is not specific to dnsmasq, and not a novel discovery by these people in any way.
If you can sniff traffic from the originating server, you don't need to guess either; if you are in a position to read the source port, you can read the transaction id and vice-versa.
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.
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.
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.
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.
They're giving Google Public DNS as example of a failure here. Whereas what happens in my testing is that it's a cache miss for Google Public DNS, which takes a little over 1 second to look everything up from cold in my part of the world for ~.www.example.com .
And in that second they have more than enough time, at LAN speeds (since they are injecting the forged responses from the dnsmasq client machine), to send a tonne of forged DNS/UDP responses which are only around a hundred bytes long each.
Readit News
There are a number of other DNS servers which are not written in C, which support transport-secured DNS like DoH (DNS-over-HTTP), DoT, and DoQ; but do they correctly handle this malformed input?
From the mailing list disclosure, which doesn't yet have a CVE FWIU? https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/20... :
[...] > PowerDNS Mitigation: https://docs.powerdns.com/recursor/settings.html#spoof-nearm...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 red herring: IIUC, dnsmasq isn't dealing with lost responses correctly, creating a window for birthday collision attack?
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.
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 SERVFAIL to its client.
Further, DNS mostly uses UDP which is unreliable -- all DNS clients must deal with the query or response being lost. Dnsmasq's timeouts might be overly long (I didn't bother to check), but this is a minor configuration issue.
This sounds like the (well known) birthday attack, the defense of which is precisely the point of DNSSEC. AFAIK, dnsmasq supports DNSSEC, so the right answer is to turn on validation.
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
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
The DNS protocol is a terrible protocol. This report is not some novel discovery.
(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".
"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 cache is a long known flaw in the DNS protocol (it has been known since at least 1993) that led to the creation of DNSSEC.
Deleted Comment
My hostnames with emojis in them might disagree.
So assume it's a bit of an inaccurate phrasing.
EDIT: nope, the email itself seeks disclosure coordination etc. So yeah, oops.
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 turned me off that as well.
1.
https://www.jsof-tech.com/wp-content/uploads/2021/01/DNSpooq...
https://www.cisa.gov/news-events/ics-advisories/icsa-21-019-...
https://www.malwarebytes.com/blog/news/2021/01/dnspooq-the-b...
https://web.archive.org/web/20210119133618if_/https://www.js...
https://seclists.org/oss-sec/2021/q1/49
Anyway, never gonna happen. Just wishful thinking.
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?
https://forum.openwrt.org/t/security-advisory-2021-01-19-1-d...
https://openwrt.org/advisory/2021-01-19-1
What was the first?
[1]: https://github.com/NLnetLabs/unbound/issues/132
[2]: https://github.com/NLnetLabs/unbound/issues/210
"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
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
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.
They're giving Google Public DNS as example of a failure here. Whereas what happens in my testing is that it's a cache miss for Google Public DNS, which takes a little over 1 second to look everything up from cold in my part of the world for ~.www.example.com .
And in that second they have more than enough time, at LAN speeds (since they are injecting the forged responses from the dnsmasq client machine), to send a tonne of forged DNS/UDP responses which are only around a hundred bytes long each.
I cannot believe this is true because that would be too dumb
edit: I don't see how is the avunit github related to the report. I don't think it is?