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.