Note: While the stoplight on this page indicates the highest possible severity level (and thus the most dire consequences if this vulnerability is indeed exploited), consult the bullet next to the link to this tutorial to check your actual susceptibility to this vulnerability. If the bullet is green, then we have checked the version of DNS being used and it is protected against this vulnerability (in other words, you need not worry about this particular vulnerability). If it is red, however, then we have detected a version of DNS that is susceptible to a vulnerability which could allow remote access. Please read the rest of this document to learn about possible solutions and/or workarounds. If the bullet is brown, then we were either unable to gather sufficient information to tell whether or not DNS is vulnerable, or we have detected a version of DNS that is susceptible to a denial-of-service vulnerability. In this case, caution should be exercised, and it might be best to continue reading through this document to avoid any problems.
BIND 8.2 through BIND 8.2.2 (all patch levels) send the program to an error handling routine when an invalid transaction signature is detected. This error handling procedure initializes variables differently from the normal procedure, such that when a valid signature is then processed a buffer overflow condition is created. This condition along with other buffer overflow exploitation techniques could allow an attacker to gain unauthorized access to the system.
Note: 8.2.3 beta versions are also vulnerable.
BIND 4.9 through BIND 4.9.7 use a fixed-length buffer to build error messages to send to syslog. An attacker could overflow this buffer by sending a specially crafted DNS query, allowing arbitrary code to be executed.
By sending a specially crafted DNS query to the server, a remote attacker could access the program stack, thus gaining knowledge of program variables. BIND 4 through BIND 4.9.7 and BIND 8 through BIND 8.2.2 (all patch levels) are affected by this vulnerability.
BIND 8.2 and BIND 8.2.1 fail to properly validate NXT records. An attacker could exploit this problem and gain access to the name server by causing a buffer to overflow. BIND 4.9 and BIND 8 prior to BIND 8.2 are not vulnerable to this problem but have other problems (see below).
The fix for this vulnerability is to upgrade to BIND 8.2.2 or higher.
Cache poisoning occurs when malicious or misleading data received from a remote name server is saved (cached) by another name server. This "bad" data is then made available to programs that request the cached data through the client interface. Cache poisoning is being used to adversely affect the mapping between host names and IP addresses. Once this mapping has been changed, any information sent between hosts on a network may be subjected to inspection, capture, or corruption.
The fix for this vulnerability is to install a patch from your vendor. If this is not possible, a workaround is described in CERT Advisory 97.22. As a good security practice in general, filter at the router all name-based authentication services so that DNS information is not relied on for authentication. This includes the services rlogin, rsh (rcp), xhost, NFS and any other locally installed services that provide trust based on domain information.
BIND 4.9 releases prior to BIND 4.97 and BIND 8 releases prior to BIND 8.1.2 do not properly bound check a memory copy when responding to an inverse query request. An improperly or maliciously formatted inverse query on a TCP stream might allow a remote intruder to gain root level access on a name server or disrupt the normal operations of the name server.
The inverse query feature is disabled by default, so only systems that have been explicitly configured to allow it are vulnerable. To determine if a system is vulnerable:
CVE 1999-0010
CVE 1999-0011
CVE 1999-0835
CVE 1999-0837
CVE 1999-0848
CVE 1999-0849
CVE 1999-0851
CVE 2000-0887
CVE 2000-0888
BIND 8 releases prior to BIND 8.2.2-P7 and all BIND 4.9 releases have a variety of problems which could allow an improperly or maliciously formatted DNS message to crash the server or yield garbage record data. Many DNS utilities that process DNS messages (e.g., dig, nslookup) also fail to do proper bounds checking. Any system running BIND 4.9 or BIND 8 prior to BIND 8.2.2-P7 is vulnerable.
The resolution to these vulnerabilities is to upgrade as soon as possible to the latest version of BIND. There are no workarounds for some of these vulnerabilities.
Assume that the following self-referential resource record is in the cache on a name server:
foo.example. IN A CNAME foo.example.The actual domain name used does not matter; the important thing is that the target of the CNAME is the same name. The record could be in the cache either because the server was authoritative for it or because the server is recursive and someone asked for it. Once this record is in the cache, issuing a zone transfer request using its name (e.g., "dig @my_nameserver foo.example. axfr") will cause the server to abort(). Most sites will not contain such a record in their configuration files. However, it is possible for an attacker to engineer such a record into the cache of a vulnerable nameserver and thus cause a denial of service.
If the BIND 8 server is not recursive and does not fetch glue, then the problem may be exploited only if the self-referential resource record is in a zone for which the server is authoritative. If the global zone transfer ACL in the options block has been set to deny access and has no self-referential CNAMEs in its authoritative zones, then the server is not vulnerable. Otherwise, the server is probably vulnerable to this hack. The nameserver is recursive by default, fetches glue by default and the default global transfer ACL allows all hosts; so many BIND 8 servers will be vulnerable to this problem.
To resolve this problem, upgrade to the latest version of BIND. If this is not feasible, you can apply a patch, or use a workaround, described in CERT Advisory 98.05.