Incorrect decoding of malformed DNS packets causes certain DNS implementations to hang or crash.
RFC1035 (DOMAIN NAMES, IMPLEMENTATION AND SPECIFICATION) defines a mechanism for conserving bytes in a DNS query or reply packet by avoiding repetition of character strings ("labels") in a domain name. Thus if the label "domain.com" appears several times in a query or response packet (i.e. "www.domain.com", "host.subdomain.domain.com", "ns.domain.com"), only the first occurrence need be fully specified - further occurrences of "domain.com" can be alluded to by using a pointer to the first occurrence. Since labels in a DNS packet are preceded by an 8 bit length field, and since individual labels are restricted to 63 characters, there are 2 unused bits in the length field. Setting these two bits 2 to "11" indicates that the following byte is not a label but rather a pointer to a prior occurrence of a label elsewhere in the packet. Programs are not required to encode packets using this label compression scheme, but all programs are required to be able to decode any such packets that are received.
Numerous DNS implementations do not perform sufficient input checking on compressed labels, allowing an attacker to craft a DNS query containing malformed compressed labels. For example, a packet can be constructed that has a pointer that points back to itself, or that contains a pointer that points to another pointer which points back to the first pointer. When vulnerable programs attempt to decode these malformed labels, various undesirable effects can be induced in the decoding process including allocating all of the process's available memory or causing the process to enter an infinite loop.
If a remote, unauthenticated attacker supplies a vulnerable DNS implementation with a specially crafted query, they may be able to cause that DNS software to enter an infinite loop eventually consuming 100% CPU resources. This will cause the DNS software to crash resulting in a denial-of-service condition.
Users are encouraged to check with their vendor to determine the appropriate patch or update to apply.
Thanks to Hugo Breton and firstname.lastname@example.org for reporting this vulnerability. Additional information for this issue was provided by the by the NISCC Vulnerability Management Team.
|Date First Published:||2001-06-18|
|Date Last Updated:||2005-11-15 13:40 UTC|