djbdns Information for VU#803539
Multiple vendors' Domain Name System (DNS) stub resolvers vulnerable to buffer overflows
- Vendor Information Help Date Notified: 27 Jun 2002
- Statement Date:
- Date Updated: 16 Apr 2003
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 http://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.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
If you have feedback, comments, or additional information about this vulnerability, please send us email.