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.
dc396 · 2h ago
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?
Beretta_Vexee · 1h ago
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.
dc396 · 53m ago
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 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.
0xbadcafebee · 50m ago
(bug in HN, have to have this for next block to format correctly)
--fast-dns-retry=[<initial retry delay in ms>[,<time to continue retries in ms>]]
Under normal circumstances, dnsmasq relies on DNS clients to do retries; it does not generate timeouts itself. Setting this option instructs dnsmasq to generate its own retries starting after a delay which defaults to 1000ms. If the second parameter is given this controls how long the retries will continue for otherwise this defaults to 10000ms. Retries are repeated with exponential backoff. Using this option increases memory usage and network bandwidth. If not otherwise configured, this option is activated with the default parameters when --dnssec is set.
--dnssec
Validate DNS replies and cache DNSSEC data. When forwarding DNS queries, dnsmasq requests the DNSSEC records needed to validate the replies. The replies are validated and the result returned as the Authenticated Data bit in the DNS packet. In addition the DNSSEC records are stored in the cache, making validation by clients more efficient. Note that validation by clients is the most secure DNSSEC mode, but for clients unable to do validation, use of the AD bit set by dnsmasq is useful, provided that the network between the dnsmasq server and the client is trusted. Dnsmasq must be compiled with HAVE_DNSSEC enabled, and DNSSEC trust anchors provided, see --trust-anchor. Because the DNSSEC validation process uses the cache, it is not permitted to reduce the cache size below the default when DNSSEC is enabled. The nameservers upstream of dnsmasq must be DNSSEC-capable, ie capable of returning DNSSEC records with data. If they are not, then dnsmasq will not be able to determine the trusted status of answers and this means that DNS service will be entirely broken.
0xbadcafebee · 53m ago
> 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
beala · 1h ago
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.
dc396 · 43m ago
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 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.
JdeBP · 51m 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".
Novel or not, this seems like it can be actively exploited?
dc396 · 32m ago
Sure. As it is a fundamental flaw in the DNS protocol itself, it is not unique to dnsmasq (it applies to any resolver).
pixl97 · 1h ago
> are limited by convention to a subset of ASCII,
My hostnames with emojis in them might disagree.
Palomides · 1h ago
are your hostnames with emoji using punycode?
dc396 · 1h ago
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?)
dzogchen · 2h ago
Oops, accidentally posted to public mailing list?
rwmj · 53m ago
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.
dc396 · 52m ago
This is why DNSSEC was created.
mike_d · 3m ago
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.
tptacek · 50s ago
We did get a ~10 year delay in transaction security for DNS while the IETF working group held out for deployment of DNSSEC, which would not have addressed vulnerabilities like this one. It was only after Kaminsky's 2008 attacks that the BIND maintainers pushed for effective query randomization.
supernetworks · 16m ago
encrypted DNS goes a long way towards mitigating this as well.
teeray · 1h ago
Would an effective mitigation be to drop inbound DNS queries that match those special characters using DPI?
dc396 · 37m ago
No. The special characters thing is a red herring. All resolvers must handle a lack of response via timeout (particularly since DNS mostly uses UDP).
The correct mitigation is turning on DNSSEC. This sort of attack, known since 1993, is why DNSSEC was created.
recsv-heredoc · 59m ago
Setting your upstream to 1.1.1.1 or 8.8.8.8 should mitigate this, as these appear to respond with NXDOMAIN to invalid domains rather than fail silently which would close the window for the attack.
westurner · 2h ago
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
So assume it's a bit of an inaccurate phrasing.
EDIT: nope, the email itself seeks disclosure coordination etc. So yeah, oops.
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
"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.
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.
My hostnames with emojis in them might disagree.
The correct mitigation is turning on DNSSEC. This sort of attack, known since 1993, is why DNSSEC was created.
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...