[yyin]

Is djbdns vulnerable? It does not use these routines.

I've never needed ENDS0, but maybe the need will arise someday. Meanwhile...

Short term, I'd prefer to expunge all "C networking code" originating from BIND authors, e.g., libresolv.

[cft]

Relatedly, if I point dnscache in djbdns to Google's DNS server as a temp fix (8.8.8.8) in /etc/resolv.conf , will that mitigate the threat?

[JdeBP]

The fact that djbdns doesn't use BIND code is not really relevant. The problem at hand is in the BIND DNS client library that is compiled and linked into applications. It's triggered by sending responses larger than 2048 bytes to those applications. The only way that djbdns factors into it is whether an attacker, running a content DNS server out on Internet, can manage to get such a DNS response through a DNS proxy server such as dnscache, to that BIND DNS client library code running in the application.

Now one might think that the discussion at https://news.ycombinator.com/item?id=11110646 already covers this. All that the content DNS server has to do is set the TC flag in the DNS/UDP response, and it can quite happily get the proxy DNS server to re-try via DNS/TCP. The interesting point is that in fact that discussion does not cover this.

This is because the idea that one can exploit this with a malicious content DNS server has as its unstated premise that DNS/UDP and DNS/TCP responses are passed straight through caching DNS proxies. This is the case for some DNS proxy softwares, where if the data have just come in from the back end and form a complete answer, they are passed through as the front-end answer. It isn't the case for dnscache. dnscache always answers from cache, even if the data have just arrived from a back-end transaction.

So those "crafted DNS responses" beginning with 2048 bytes of valid protocol, that the malicious content DNS server has to generate, have to survive being unpacked, stuffed into dnscache's cache, extracted back out of dnscache's cache, and turned into an answer response by dnscache's from-scratch answer construction code. And this without being able to use the authority or additional sections, without being able to use more than one (non-CNAME) RRset in the answer section, and without any guarantee of any given RRset ordering. This is ... somewhat difficult.

The devil in the details of this problem lies in one sentence of the analysis that accompanies the patch:

> Overflowing bytes are entirely under the control of the attacker and are the result of a crafted DNS response.

If you've done as the people at https://news.ycombinator.com/item?id=11112527 and https://www.reddit.com/r/netsec/comments/462xx0/glibc_getadd... did, you might have convinced yourself how simple it is to exploit this. Just set up a malicious content DNS server that does what this does, and Bob's Your Uncle. But in fact those demonstrations are not how DNS lookups work. People do not point the BIND DNS client library at (malicious) content DNS servers. The DNS client library is pointed at the front end of a proxy DNS server, which performs back-end lookups to the (malicious) content DNS servers.

* http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dn...

So one has to take into account what the proxy DNS server does in between its back end and its front end. The response returned to the BIND DNS client library from the front end is not "entirely under the control of the attacker". As in the case of dnscache, where front end responses are constructed from cache and from scratch, it's actually quite difficult for the attacker to control it at all, let alone cause dnscache to send a valid-flawed-valid response sequence. It's not just dnscache where this is a difficulty for an attacker, either.

Which is why the analysis talks of man-in-the-middle attacks. To exploit this with far greater chance of success, one gets in between the BIND DNS client library and the proxy DNS server, or just plain supplants/subverts the proxy DNS server. Which is yet another reason why it's a good idea to run a proxy DNS server locally, on each machine or at least on the LAN, and make sure that "local" traffic is blocked at relevant machine/LAN borders. An attacker who can field DNS traffic to [::1]:53 or 127.0.0.1:53 in order to be that man in the middle has already had to overcome some quite tricky obstacles. (-:

* http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dn...

It's worth noting that we've been here before. A lot.

* https://cr.yp.to/djbdns/res-disaster.html

* http://www.kb.cert.org/vuls/id/542971

* http://www.kb.cert.org/vuls/id/803539

* http://www.kb.cert.org/vuls/id/844360

... And so on.

[yyin]

"The fact that djbdns doesn't use BIND code is not really relevant."

It is to me.

It's true that in this case it's not what mitigates this vulnerability. Although it has certainly mitigated many others over the years and, sadly, probably will do so a few more times in the future. There's just no getting rid of the BIND legacy.

Correct me if I am wrong, but using a local dnscache and the fact that dnscache does not implement ENDS0 should be enough to mitigate this one.

I have been running a local tinydns root.zone and dnscache for many years. Really like the software.