Re: Remote buffer overflow in resolver code of libc

["D. J. Bernstein" <djb () cr yp to>]

Note that djbdns includes a DNS client library. Documentation:

   http://cr.yp.to/djbdns/blurb/library.html (features)
   http://cr.yp.to/djbdns/dns.html (high-level interface)
   http://cr.yp.to/djbdns/dns_domain.html (low-level name functions)
   http://cr.yp.to/djbdns/dns_packet.html (low-level packet functions)
   http://cr.yp.to/djbdns/dns_transmit.html (async interface)
   http://cr.yp.to/djbdns/dns_random.html (randomization interface)

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 are now in the
public domain.

Note also that the list in http://cr.yp.to/djbdns/guarantee.html has
always included ``Buffer overflows allowing attackers to take over DNS
clients,'' although I didn't have a BIND example before now.

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.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago