DNS Vulnerabilities

Impact

This document will cover several BIND vulnerabilities that malicious users can exploit to both gain unauthorized, privileged access to target machines and/or disrupt service on target machines.

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 this vulnerability. Please read the rest of this document to learn about possible solutions and/or workarounds. If the bullet is brown, then we were not able to detect which version of DNS is being used. In this case, caution should be exercised, and it might be best to continue reading through this document to avoid any problems.

Background

The Berkeley Internet Name Daemon (BIND) is an implementation of the Domain Name Service (DNS) written primarily for UNIX Systems. BIND consists of three parts:

The Problems/Resolutions


Cache Poisoning

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.


Inverse Query Buffer Overrun in BIND 4.9 and BIND 8 Releases

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:

To fix this vulnerability, it is recommended that you disable inverse queries until you can apply a patch or upgrade to BIND 8.1.2, which is now available. For more information on patches for BIND 8 and BIND 4.9, as well as the BIND 8.1.2 upgrade, please read CERT Advisory 98.05.


Denial-of-Service Vulnerabilities in BIND 4.9 and BIND 8 Releases

BIND 4.9 releases prior to BIND 4.9.7 and BIND 8 releases prior to BIND 8.1.2 do not properly bounds check many memory references in the server and the resolver. An improperly or maliciously formatted DNS message can cause the server to read from invalid memory locations, yielding garbage record data or crashing the server. Many DNS utilities that process DNS messages (e.g., dig, nslookup) also fail to do proper bounds checking. Any system running BIND 4.9 prior to BIND 4.9.7 or BIND 8 prior to BIND 8.1.2 is vulnerable.

The resolution to this vulnerability is to upgrade as soon as possible ( there are no workarounds for this vulnerability). For those running BIND 8, upgrade to BIND 8.1.2. For those running BIND 4.9, upgrade to BIND 4.9.7.


Denial-of-Service Vulnerability in BIND 8 Releases

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 BIND 8.1.2. If this is not feasible, you can apply a patch, or use a workaround, described in CERT Advisory 98.05.

Where can I read more about this?

In addition to CERT Advisories 97.22 and 98.05 mentioned earlier, you may also wish to read CERT Summaries 98.05 and 98.04, which detail other DNS vulnerabilities of which you should be aware.