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
This archive was generated by hypermail 2b30 : Thu Jul 04 2002 - 09:55:51 PDT