BIND version 8.2.2 and prior is vulnerable to root compromise
30 Nov. 1999
Summary
BIND 8.2.2-P3 has been released in order to address vulnerabilities found in earlier versions of BIND. These security holes make the BIND vulnerable to root compromises, DoS attacks, cache poisoning and more. It is advisable that users upgrade their current BIND version to the latest one, BIND 8.2.2-P3.
Credit:
These vulnerabilities were reported by: Internet Software Consortium.
Instructions of how to hide the BIND version were provided by: LaMont Jones
The following vulnerabilities have been discovered in BIND:
1) nxt bug.
A bug in the processing of NXT records can theoretically allow an attacker to gain access to the system running the DNS server at whatever privilege level the DNS server runs at.
2) solinger bug.
It is possible to remotely cause BIND to "pause" for intervals of up to 120 seconds using an abnormal TCP session.
Workaround:
In some systems, it is possible to set the system wide SO_LINGER timeout to a lower value, however this may have unexpected consequences with other applications.
3) fdmax bug.
A bug in the handling of file descriptors results in a vulnerability that will crash the DNS server when more than FD_SETSIZE descriptors are consumed.
Workaround:
Set { files #; } where # is less than FD_SETSIZE (as typically found in /usr/include/sys/select.h) in the "options" section of named.conf
4) sig bug.
Improper validation of SIG record contents can trigger the DNS server crashing resulting in a denial of service attack.
5) naptr bug.
Improper validation of zone data for the NAPTR record being loaded from disk can result in the DNS server crashing. Zone data read from the network cannot trigger this bug. Given the privilege level to modify the zone data is typically the same as running the DNS server, this bug is unlikely to result in an exploit unless zone files have unusual permissions.
Workaround:
Insure permission level required to modify zone files is the same or higher than that of the DNS server.
6) maxdname bug.
The use of sprintf() with data from the network can result in a buffer overflow condition which may result in unexpected behavior. Because of the placement of the buffer that can be overflowed, it is unlikely this bug will result in serious consequences. However the possibility of a remotely triggered server crash cannot be ruled out.
How can I find out which version of BIND I am using?
# nslookup
> server your.default.dns
Default Server: your.default.dns
Address: 1.2.3.4
> server dns_in_question
> set q=txt
> set class=chaos
> version.bind
Server: dns_in_question
Address: dns.in.question.ip
VERSION.BIND text = HIS VERSION (if this is supported and allowed)
>exit
Preventing users from seeing your BIND version
The above procedure allows any outsider to see which version of BIND you are using, and helps them exploit known vulnerabilities. The following fix will prevent BIND from answering the VERSION.BIND query and will log those attempts.
Add the following line in named.conf: zone "bind" chaos { allow-query {localhost; }; type master; file "pri/bind"; };
Add the following file in pri/bind under your named configuration files directory (the default installation of bind places the named configuration files in /var/named. If this is the case, the file name is /var/named/pri/bind): $ORIGIN bind.
@ 1D CHAOS SOA localhost. root.localhost. (
1 ; serial
3H ; refresh
1H ; retry
1W ; expiry
1D ) ; minimum
CHAOS NS localhost.
Fix Information
BIND 8.2.2-P3 is no longer vulnerable to the above attacks. This version can be downloaded from the following locations:
