Vulnerability Note VU#800113
Multiple DNS implementations vulnerable to cache poisoning
Deficiencies in the DNS protocol and common DNS implementations facilitate DNS cache poisoning attacks.
The Domain Name System (DNS) is responsible for translating host names to IP addresses (and vice versa) and is critical for the normal operation of internet-connected systems. DNS cache poisoning (sometimes referred to as cache pollution) is an attack technique that allows an attacker to introduce forged DNS information into the cache of a caching nameserver. DNS cache poisoning is not a new concept; in fact, there are published articles that describe a number of inherent deficiencies in the DNS protocol and defects in common DNS implementations that facilitate DNS cache poisoning. The following are examples of these deficiencies and defects:
Because attacks against these vulnerabilities all rely on an attacker's ability to predictably spoof traffic, the implementation of per-query source port randomization in the server presents a practical mitigation against these attacks within the boundaries of the current protocol specification. Randomized source ports can be used to gain approximately 16 additional bits of randomness in the data that an attacker must guess. Although there are technically 65,535 ports, implementers cannot allocate all of them (port numbers <1024 may be reserved, other ports may already be allocated, etc.). However, randomizing the ports that are available adds a significant amount of attack resiliency. It is important to note that without changes to the DNS protocol, such as those that the DNS Security Extensions (DNSSEC) introduce, these mitigations cannot completely prevent cache poisoning. However, if properly implemented, the mitigations reduce an attacker's chances of success by several orders of magnitude and make attacks impractical.
An attacker with the ability to conduct a successful cache poisoning attack can cause a nameserver's clients to contact the incorrect, and possibly malicious, hosts for particular services. Consequently, web traffic, email, and other important network data can be redirected to systems under the attacker's control.
Apply a patch from the vendor
Administrators, particularly those who are unable to apply a patch, can limit exposure to this vulnerability by restricting sources that can ask for recursion. Note that restricting access will still allow attackers with access to authorized hosts to exploit this vulnerability. The document "Securing an Internet Name Server" contains instructions for restricting recursion in ISC BIND.
Systems Affected (Learn More)
|Vendor||Status||Date Notified||Date Updated|
|Alcatel-Lucent||Affected||21 Apr 2008||14 Aug 2008|
|Apple Computer, Inc.||Affected||05 May 2008||08 Oct 2008|
|Avaya, Inc.||Affected||21 Apr 2008||16 Jul 2008|
|Blue Coat Systems||Affected||-||21 Nov 2008|
|BlueCat Networks, Inc.||Affected||05 May 2008||22 Jul 2008|
|Cisco Systems, Inc.||Affected||01 May 2008||10 Jul 2008|
|Debian GNU/Linux||Affected||05 May 2008||09 Jul 2008|
|dnsmasq||Affected||09 Jul 2008||11 Jul 2008|
|F5 Networks, Inc.||Affected||21 Apr 2008||14 Jul 2008|
|Force10 Networks, Inc.||Affected||21 Apr 2008||08 Oct 2008|
|FreeBSD, Inc.||Affected||05 May 2008||14 Jul 2008|
|Fujitsu||Affected||21 Apr 2008||18 Jul 2008|
|Funkwerk Enterprise Communications||Affected||-||22 Aug 2008|
|Gentoo Linux||Affected||06 Jun 2008||12 Jul 2008|
|Hewlett-Packard Company||Affected||21 Apr 2008||16 Jul 2008|
CVSS Metrics (Learn More)
Thanks to Dan Kaminsky of IOActive for identifying the effectiveness and practicality of DNS cache poisoning, and to Paul Vixie of Internet Systems Consortium (ISC) for raising the urgency of these issues. Daniel J. Bernstein is credited with the original idea and implementation of randomized source ports in the DNS resolver.
This document was written by Chad R Dougherty.
- CVE IDs: CVE-2008-1447
- US-CERT Alert: TA08-190B
- Date Public: 08 Jul 2008
- Date First Published: 08 Jul 2008
- Date Last Updated: 03 Jun 2009
- Severity Metric: 27.54
- Document Revision: 104
If you have feedback, comments, or additional information about this vulnerability, please send us email.