Here's what we know for sure:
Note to programmers: You can and should switch from libresolv to the djbdns client library, which has always been covered by the djbdns security guarantee. I've put the .[ch] files (dns.h, dns_dfd.c, dns_domain.c, dns_dtda.c, dns_ip.c, dns_ipq.c, dns_mx.c, dns_name.c, dns_nd.c, dns_packet.c, dns_random.c, dns_rcip.c, dns_rcrw.c, dns_resolve.c, dns_sortip.c, dns_transmit.c, dns_txt.c) and all necessary lower-level .[ch] files into the public domain.
Solution Use a local caching DNS server Using a local caching DNS server that reconstructs DNS responses will prevent malicious responses from reaching systems using vulnerable DNS resolver libraries. For example, BIND 9 reconstructs responses in this way, with the exception of forwarded dynamic DNS update messages. Note that BIND 8 does not reconstruct all responses; therefore this workaround may not be effective when using BIND 8 as a caching DNS server.
On 2002.07.04, I sent the following comments to the bugtraq mailing list:
BIND company official David Conrad writes: > My understanding is that this will work with BINDv9 since the cache > synthesizes all responses returned to the requestor and a bad response > wouldn't be synthesized. What exactly do you mean by ``work,'' and by ``bad response''? And what exactly do you mean when you say that a BINDv9 cache ``can be used to prevent malformed answers reaching vulnerable clients''? Are you saying that clients are protected if /etc/resolv.conf points to a BINDv9 cache? That's obviously not true: the attacker can forge a packet that appears to come from the cache. Are you saying that clients are protected if /etc/resolv.conf points to a BINDv9 cache and local forgeries are prevented by, say, IPSEC? Are you promising that BINDv9 will protect clients in this situation? Will you treat a flaw in this protection as (another) BINDv9 security hole? A few people seem to think that this is what you're saying, and that they don't need to panic, because they're using BINDv9 caches and IPSEC, and they don't mind their caches having root access to all the clients. Yes or no: Are they in danger? I presume that your statement is based on at least this much content: you've figured out _one_ type of packet that will trigger these buffer overflows, and you're sure that BINDv9 will never produce _that_ type of packet. But are you saying that _none_ of the packets produced by BINDv9 will trigger these buffer overflows? If so, can you justify that statement? Exactly what packets do you consider to be ``bad''? Why do you think that BINDv9 will never produce ``bad'' packets? Why do you think that these buffer overflows can't be triggered except by ``bad'' packets? Perhaps clients using the BIND company's buggy client libraries really can be protected by the BINDv9 cache (or by dnscache). But I haven't seen the analysis necessary to justify this claim. At this point it isn't even clear whether the BIND company is making that claim.
On 2002.07.05, I sent the following comments to the dns mailing list:
Terminology: a ``bad packet'' is a DNS packet where CNAME records appear after A/AAAA records in the answer section. BIND 9 and dnscache never send bad packets to clients. They always put CNAME records at the top of the answer section. (Irrelevant exception: BIND 9 reportedly sends bad packets in some dynamic-update situations.) The BIND company believes, apparently, that these libresolv bugs can't be triggered unless libresolv sees a bad packet. In particular, they won't be triggered by packets from BIND 9 or dnscache. This leaves three concerns. First, and most importantly, an attacker can send bad packets directly to vulnerable clients, without going through the cache. Second, an attacker who takes over a BIND 9 machine can then take over all the client machines; this is a violation of security policy at some sites. Third, the BIND company may be wrong; there certainly hasn't been a careful public analysis of these libresolv bugs.As it turned out, the BIND company was wrong.
On 2002.07.08, I sent the following statement to CERT:
djbdns does not have these bugs. djbdns has never used any BIND-derived code. djbdns, including the djbdns client library, is covered by a $500 security guarantee. The djbdns client library is free for use by other packages in place of BIND's libresolv. See https://cr.yp.to/djbdns.html. Elsewhere in this advisory, CERT and the BIND company suggest that administrators do not need to rush to upgrade their libresolv-based clients if they are using BIND 9 caches. The idea is that (1) BIND 9 caches never put CNAME records into the answer section of a DNS packet except at the top and (2) the BIND company believes that these libresolv bugs cannot be triggered by answer sections with all CNAME records at the top. dnscache, the caching component of djbdns, is like the BIND 9 cache in all relevant respects. Specifically, it never puts CNAME records into the answer section except at the top. (This is the normal behavior for DNS caches; BIND 4 and BIND 8 are abnormal.) However, it is simply not true that clients are protected by caches. Attackers can send unusual packets directly to clients, using the same well-known techniques used to selectively forge DNS responses. I do not endorse the suggestion of relying on caches (whether BIND 9 or dnscache) as a ``solution'' to the libresolv bugs. All libresolv-based clients must be upgraded immediately. There are exceptions. Sites that use a local dnscache on every machine, with local firewalls preventing forgery of 127.0.0.1 and with proper IP-address checks in client libraries, are immune to cache-to-client packet forgery, as are sites that use IPSEC. However, even at those sites, libresolv-based clients should be upgraded immediately; the ability of the cache to take control of client programs, rather than simply providing DNS data, is a violation of standard security policy.CERT did not add this statement to their advisory until 2002.07.25.
On 2002.08.27, CERT and the BIND company retracted their ``solution,'' and stopped claiming that BIND 9 caches would protect clients:
Use of a local caching DNS server is not an effective workaround When this advisory was initially published, it was thought that a caching DNS server that reconstructs DNS responses would prevent malicious code from reaching systems with vulnerable resolver libraries. This workaround is not sufficient. It does not prevent some DNS responses that contain malicious code from reaching clients, whether or not the responses are reconstructed by a local caching DNS server. DNS responses containing code that is capable of exploiting the vulnerabilities described in VU#803539 and VU#542971 can be cached and reconstructed before being transmitted to clients. Since the server may cache the responses, the malicious code could persist until the server's cache is purged or the entries expire.
On 2002.09.11, I sent CERT the following updated statement:
djbdns does not have these bugs. djbdns has never used any BIND-derived code. djbdns, including the djbdns client library, is covered by a $500 security guarantee. The djbdns client library is free for use by other packages in place of BIND's libresolv. See https://cr.yp.to/djbdns.html. In the first version of this advisory, CERT and the BIND company suggested that administrators did not need to rush to upgrade their libresolv-based clients if they were using BIND 9 caches. The BIND company believed, at the time, that BIND 9 caches could not generate unusual packets that trigger these libresolv bugs. That suggestion was irresponsible. In typical network configurations, caches cannot protect clients, no matter how restrictive the caches are. Attackers can send unusual packets directly to clients, using the same well-known techniques used to selectively forge DNS responses. The current version of this advisory withdraws the suggestion, but for the wrong reason. It continues to implicitly promote the irresponsible notion of using caches to protect clients; it merely says that BIND 9 caches are not restrictive enough. Users need to understand that they cannot protect clients by upgrading caches. All libresolv-based clients must be upgraded immediately.As of 2002.11.03, CERT still hadn't updated their advisory.
Are we sure that this bug is exploitable in the first place? The BIND company says that it is, and I have no reason to believe otherwise, but I still want to see justification for their claims. As I wrote in the information for contributors to the securesoftware mailing list: ``You are encouraged to publish portable, documented, readable software that exploits the security hole. This is by far the easiest way for other computer security researchers to verify your discovery and for administrators to confirm that they are vulnerable.'' The information available about this bug right now falls far short of this standard.