5 ms·

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 co

by 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
  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.
  - tptacek 1y ago
    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.
    - dc396 1y ago
      It's unclear to me what "make the DNS security model cohere with IPSEC" means. DNSSEC was a direct response to the vulnerabilities identified by a number of folks and documented by Christoph Schuba (https://www.cerias.purdue.edu/assets/pdf/bibtex_archive/94-05.pdf https://www.cerias.purdue.edu/assets/pdf/bibtex_archive/94-0...). ISC was hired as a sub-contractor by TIS (I signed the contract for ISC) to implement DNSSEC in BIND specifically to address the transaction ID flood vulnerability.
      - tptacek 1y ago
        I have around here somewhere the mail spool of the mailing list contemporaneous to the time and stand by my interpretation (the dns-security@tis.com list) --- I also worked "at TIS" (at Network Associates), writing the DNS security checks for NAI's security scanner (which included serverside components that actively exploited all these attacks) --- but that was a year or two after the contract, as I understand it. The COAST paper you're citing predates practical exploitation of QID prediction by 2 years, and the most significant DNS spoofing exploits of the time (the ones Kashpureff used) did not involve QID prediction. I think the Kremlinology here is super interesting and I'm happy to keep digging with you, but again: DNS spoofing was a live issue for a couple months in 1995, when it was resolved by QID randomization in BIND (and then QID+port randomization in djbdns), and then a live issue again for about a month and a half in 2008, when it was finally resolved by QID+port randomization in BIND. DNSSEC had nothing at all to do with it.
Beretta_Vexee 1y 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 1y 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 1y 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.
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 ago
  A 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 ago
    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.
    - JdeBP 1y ago
      The 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.
m3047 1y ago
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".

by dc396 1y ago

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
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.
- tptacek 1y ago
  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.
  - dc396 1y ago
    It's unclear to me what "make the DNS security model cohere with IPSEC" means. DNSSEC was a direct response to the vulnerabilities identified by a number of folks and documented by Christoph Schuba (https://www.cerias.purdue.edu/assets/pdf/bibtex_archive/94-05.pdf https://www.cerias.purdue.edu/assets/pdf/bibtex_archive/94-0...). ISC was hired as a sub-contractor by TIS (I signed the contract for ISC) to implement DNSSEC in BIND specifically to address the transaction ID flood vulnerability.
    - tptacek 1y ago
      I have around here somewhere the mail spool of the mailing list contemporaneous to the time and stand by my interpretation (the dns-security@tis.com list) --- I also worked "at TIS" (at Network Associates), writing the DNS security checks for NAI's security scanner (which included serverside components that actively exploited all these attacks) --- but that was a year or two after the contract, as I understand it. The COAST paper you're citing predates practical exploitation of QID prediction by 2 years, and the most significant DNS spoofing exploits of the time (the ones Kashpureff used) did not involve QID prediction. I think the Kremlinology here is super interesting and I'm happy to keep digging with you, but again: DNS spoofing was a live issue for a couple months in 1995, when it was resolved by QID randomization in BIND (and then QID+port randomization in djbdns), and then a live issue again for about a month and a half in 2008, when it was finally resolved by QID+port randomization in BIND. DNSSEC had nothing at all to do with it.

Beretta_Vexee 1y 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 1y 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 1y 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.

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 ago
A 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 ago
  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.
  - JdeBP 1y ago
    The 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.

m3047 1y ago

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".