6 ms·

Critical Cache Poisoning Vulnerability in Dnsmasq

130 points by westurner 1y ago

westurner 1y 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? From the mailing list disclosure, which doesn't yet have a CVE FWIU? https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2025q3/018288.html https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/20... : 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 > PowerDNS Mitigation: https://docs.powerdns.com/recursor/settings.html#spoof-nearmiss-max https://docs.powerdns.com/recursor/settings.html#spoof-nearm... spoof-nearmiss-max
dzogchen 1y ago
Oops, accidentally posted to public mailing list?
forkerenok 1y ago
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.
- karel-3d 1y ago
  dnsmasq has no security contact
  - marcusb 1y ago
    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.
dc396 1y 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?
- pixl97 1y ago
  > are limited by convention to a subset of ASCII, My hostnames with emojis in them might disagree.
  - Palomides 1y ago
    are your hostnames with emoji using punycode?
  - dc396 1y 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?)
- beala 1y 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.
  - deleted 1y ago
    [deleted]
  - dc396 1y ago
teeray 1y ago
Would an effective mitigation be to drop inbound DNS queries that match those special characters using DPI?
- recsv-heredoc 1y 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.
- dc396 1y 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.
  - deleted 1y ago
    [deleted]
  - karel-3d 1y ago
    Better solution that doesn't rely on DNSSEC is use stub resolver that can forward requests on DoH; like unbound or dnsdist. dnsmasq cannot do this and just forwards UDP to UDP and TCP to TCP. (and doesn't know DoT or DoH) DoH (and DoT, DNS over TLS) doesn't have this problem, as the whole thing is secured. (Well, this concrete problem might actually be prevented just by using plain old DNS over TCP, but I am not sure about that.)
rwmj 1y 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 1y ago
  This is why DNSSEC was created.
  - supernetworks 1y ago
    encrypted DNS goes a long way towards mitigating this as well.
    - dc396 1y ago
      Does dnsmasq have a way to forward via DOH/DOT? (I've no idea: I don't use it myself)
      - aaronmdjones 1y ago
        Not at the moment; to achieve this, you typically put it behind something like dnsproxy [1][2]. I have done this on my router, along with a couple firewall rules to prevent plaintext DNS queries leaking out of the WAN port. dnsmasq is configured to talk to dnsproxy, and dnsproxy is configured to use DNS over TLS with 1.1.1.1 [3] [1] https://github.com/AdguardTeam/dnsproxy https://github.com/AdguardTeam/dnsproxy [2] https://openwrt.org/docs/guide-user/services/dns/dot_dnsmasq_dnsproxy https://openwrt.org/docs/guide-user/services/dns/dot_dnsmasq... [3] https://news.ycombinator.com/item?id=44429118 https://news.ycombinator.com/item?id=44429118
  - mike_d 1y 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.
karel-3d 1y ago
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.
- JdeBP 1y ago
  See https://news.ycombinator.com/item?id=44954517 https://news.ycombinator.com/item?id=44954517 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.
  - karel-3d 1y ago
    so the special characters are a red herring? and all they are doing is sending UDP responses locally faster than the recursive resolver? 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?
- mzajc 1y ago
  Same for 1.1.1.1 and 9.9.9.9. My ISP's resolver also returns NXDOMAIN immediately. Quick way to test: dig 'test~!*_' @resolver-ip
tonymet 1y ago
there are easily 300m+ installs of dnsmasq that will never be updated, because they are buried in forked , unmaintained firmwares on consumer routers. We truly need a "right to repair" for IOT & consumer networking devices. Any device not receiving monthly security updates should have the firmware keys & source published so the community can take over.
1vuio0pswjnm7 1y ago
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. 1. https://www.jsof-tech.com/wp-content/uploads/2021/01/DNSpooq_Technical-Whitepaper.pdf https://www.jsof-tech.com/wp-content/uploads/2021/01/DNSpooq... https://www.cisa.gov/news-events/ics-advisories/icsa-21-019-01 https://www.cisa.gov/news-events/ics-advisories/icsa-21-019-... https://www.malwarebytes.com/blog/news/2021/01/dnspooq-the-bugs-haunting-dnsmasq https://www.malwarebytes.com/blog/news/2021/01/dnspooq-the-b... https://web.archive.org/web/20210119133618if_/https://www.jsof-tech.com/disclosures/dnspooq/ https://web.archive.org/web/20210119133618if_/https://www.js... https://seclists.org/oss-sec/2021/q1/49 https://seclists.org/oss-sec/2021/q1/49 Anyway, never gonna happen. Just wishful thinking.
- yjftsjthsd-h 1y ago
  > This is at least the second major dnsmasq coding mistake that has been published in recent memory. What was the first?
  - tptacek 1y ago
    There was like a memory corruption RCE not long ago.
    - aspenmayer 1y ago
      I think there were two sets of 7 total vulnerabilities at the same time so they might be perceived as one event? I don’t know for sure, the wording was kind of ambiguous. https://openwrt.org/advisory/2021-01-19-1 https://openwrt.org/advisory/2021-01-19-1 > Dnsmasq has two sets of vulnerabilities, one set of memory corruption issues handling DNSSEC and a second set of issues validating DNS responses. These vulnerabilities could allow an attacker to corrupt memory on the target device and perform cache poisoning attacks against the target environment. > These vulnerabilities are also tracked as ICS-VU-668462 and referred to as DNSpooq. https://web.archive.org/web/20250121143405/https://www.jsof-tech.com/disclosures/dnspooq/ https://web.archive.org/web/20250121143405/https://www.jsof-... > DNSpooq - Kaminsky attack is back! > 7 new vulnerabilities are being disclosed in common DNS software dnsmasq, reminiscent of 2008 weaknesses in Internet DNS Architecture Some less breathless sourcing, though I can’t blame OP for being excited in the above post: https://www.kb.cert.org/vuls/id/434904 https://www.kb.cert.org/vuls/id/434904 https://www.cisa.gov/news-events/ics-advisories/icsa-21-019-01 https://www.cisa.gov/news-events/ics-advisories/icsa-21-019-...
charcircuit 1y ago
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.
- kj4ips 1y ago
  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.
  - charcircuit 1y ago
    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.
    - ectospheno 1y ago
      RFC 2181 section 5.4.1 covers this a bit. Search for “additional data section”. So since at least 1997 you shouldn’t trust it. Subsequent rfcs also reference this topic a bit.

130 points by westurner 1y 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? From the mailing list disclosure, which doesn't yet have a CVE FWIU? https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2025q3/018288.html https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/20... : 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 > PowerDNS Mitigation: https://docs.powerdns.com/recursor/settings.html#spoof-nearmiss-max https://docs.powerdns.com/recursor/settings.html#spoof-nearm... spoof-nearmiss-max

dzogchen 1y ago

Oops, accidentally posted to public mailing list?

forkerenok 1y ago

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.

karel-3d 1y ago
dnsmasq has no security contact
- marcusb 1y ago
  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.

dc396 1y 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?

pixl97 1y ago
> are limited by convention to a subset of ASCII, My hostnames with emojis in them might disagree.
- Palomides 1y ago
  are your hostnames with emoji using punycode?
- dc396 1y 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?)
beala 1y 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.
- deleted 1y ago
  [deleted]
- dc396 1y ago

teeray 1y ago

Would an effective mitigation be to drop inbound DNS queries that match those special characters using DPI?

recsv-heredoc 1y 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.
dc396 1y 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.
- deleted 1y ago
  [deleted]
- karel-3d 1y ago
  Better solution that doesn't rely on DNSSEC is use stub resolver that can forward requests on DoH; like unbound or dnsdist. dnsmasq cannot do this and just forwards UDP to UDP and TCP to TCP. (and doesn't know DoT or DoH) DoH (and DoT, DNS over TLS) doesn't have this problem, as the whole thing is secured. (Well, this concrete problem might actually be prevented just by using plain old DNS over TCP, but I am not sure about that.)

rwmj 1y 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 1y ago
This is why DNSSEC was created.
- supernetworks 1y ago
  encrypted DNS goes a long way towards mitigating this as well.
  - dc396 1y ago
    Does dnsmasq have a way to forward via DOH/DOT? (I've no idea: I don't use it myself)
    - aaronmdjones 1y ago
      Not at the moment; to achieve this, you typically put it behind something like dnsproxy [1][2]. I have done this on my router, along with a couple firewall rules to prevent plaintext DNS queries leaking out of the WAN port. dnsmasq is configured to talk to dnsproxy, and dnsproxy is configured to use DNS over TLS with 1.1.1.1 [3] [1] https://github.com/AdguardTeam/dnsproxy https://github.com/AdguardTeam/dnsproxy [2] https://openwrt.org/docs/guide-user/services/dns/dot_dnsmasq_dnsproxy https://openwrt.org/docs/guide-user/services/dns/dot_dnsmasq... [3] https://news.ycombinator.com/item?id=44429118 https://news.ycombinator.com/item?id=44429118
- mike_d 1y 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.

karel-3d 1y ago

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.

JdeBP 1y ago
See https://news.ycombinator.com/item?id=44954517 https://news.ycombinator.com/item?id=44954517 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.
- karel-3d 1y ago
  so the special characters are a red herring? and all they are doing is sending UDP responses locally faster than the recursive resolver? 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?
mzajc 1y ago
Same for 1.1.1.1 and 9.9.9.9. My ISP's resolver also returns NXDOMAIN immediately. Quick way to test: dig 'test~!*_' @resolver-ip

tonymet 1y ago

there are easily 300m+ installs of dnsmasq that will never be updated, because they are buried in forked , unmaintained firmwares on consumer routers. We truly need a "right to repair" for IOT & consumer networking devices. Any device not receiving monthly security updates should have the firmware keys & source published so the community can take over.

1vuio0pswjnm7 1y ago

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. 1. https://www.jsof-tech.com/wp-content/uploads/2021/01/DNSpooq_Technical-Whitepaper.pdf https://www.jsof-tech.com/wp-content/uploads/2021/01/DNSpooq... https://www.cisa.gov/news-events/ics-advisories/icsa-21-019-01 https://www.cisa.gov/news-events/ics-advisories/icsa-21-019-... https://www.malwarebytes.com/blog/news/2021/01/dnspooq-the-bugs-haunting-dnsmasq https://www.malwarebytes.com/blog/news/2021/01/dnspooq-the-b... https://web.archive.org/web/20210119133618if_/https://www.jsof-tech.com/disclosures/dnspooq/ https://web.archive.org/web/20210119133618if_/https://www.js... https://seclists.org/oss-sec/2021/q1/49 https://seclists.org/oss-sec/2021/q1/49 Anyway, never gonna happen. Just wishful thinking.

yjftsjthsd-h 1y ago
> This is at least the second major dnsmasq coding mistake that has been published in recent memory. What was the first?
- tptacek 1y ago
  There was like a memory corruption RCE not long ago.
  - aspenmayer 1y ago
    I think there were two sets of 7 total vulnerabilities at the same time so they might be perceived as one event? I don’t know for sure, the wording was kind of ambiguous. https://openwrt.org/advisory/2021-01-19-1 https://openwrt.org/advisory/2021-01-19-1 > Dnsmasq has two sets of vulnerabilities, one set of memory corruption issues handling DNSSEC and a second set of issues validating DNS responses. These vulnerabilities could allow an attacker to corrupt memory on the target device and perform cache poisoning attacks against the target environment. > These vulnerabilities are also tracked as ICS-VU-668462 and referred to as DNSpooq. https://web.archive.org/web/20250121143405/https://www.jsof-tech.com/disclosures/dnspooq/ https://web.archive.org/web/20250121143405/https://www.jsof-... > DNSpooq - Kaminsky attack is back! > 7 new vulnerabilities are being disclosed in common DNS software dnsmasq, reminiscent of 2008 weaknesses in Internet DNS Architecture Some less breathless sourcing, though I can’t blame OP for being excited in the above post: https://www.kb.cert.org/vuls/id/434904 https://www.kb.cert.org/vuls/id/434904 https://www.cisa.gov/news-events/ics-advisories/icsa-21-019-01 https://www.cisa.gov/news-events/ics-advisories/icsa-21-019-...

charcircuit 1y ago

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.

kj4ips 1y ago
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.
- charcircuit 1y ago
  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.
  - ectospheno 1y ago
    RFC 2181 section 5.4.1 covers this a bit. Search for “additional data section”. So since at least 1997 you shouldn’t trust it. Subsequent rfcs also reference this topic a bit.