From support@caldera.com Thu Apr 9 13:25:33 1998 From: Caldera Support To: Caldera Announce Date: 9 Apr 1998 17:34:58 -0000 Reply-To: info@caldera.com Subject: Caldera Security Advisory SA-1998.08: Vulnerability in bind -----BEGIN PGP SIGNED MESSAGE----- Subject: Caldera Security Advisory SA-1998.08: Vulnerability in bind Advisory issue date: 09-Apr-1998 Topic: Vulnerability in bind I. Problem Description This advisory describes two distinct problems in BIND. Topic 1 allows a remote intruder to gain root access on your name server. (This relates to the CERT topic #1). Topic 2 deals with denial of service. (This relates to the CERT topic #3). Detailed descriptions of each problem are contained in the relevant section. A third problem exists with bind that the authors are currently working. No details have been released, but it is anticipated that a 8.1.2 version will be forth coming shortly. (This relates to the CERT topic #2). II. Impact ************************************************************************** Topic 1: Inverse Query Buffer Overrun in BIND 4.9 and BIND 8 Releases ************************************************************************** Description: BIND 4.9 releases prior to BIND 4.9.7, and BIND 8 releases prior to 8.1.1-5 do not properly bounds check a memory copy when responding to an inverse query request. An improperly or maliciously formatted inverse query on a TCP stream can crash the server or allow an attacker to gain root privileges. Vulnerable Systems: The inverse query feature is disabled by default, so only those systems that have explicitly been configured to allow it are vulnerable. On BIND 8 systems, look at the "options" block in the configuration file (typically /etc/named.conf). If there is a "fake-iquery yes;" line, then the server is vulnerable. On BIND 4.9 systems, look at "options" lines in the configuration file (typically /etc/named.boot). If there is a line containing "fake-iquery", then the server is vulnerable. Also, unlike BIND 8, inverse query support can also be enabled when the server is compiled. Examine conf/options.h in the source, and if the line #defining INVQ isn't commented out, then the server is vulnerable. ************************************************************************** Topic 2: Denial of Service Vulnerability in BIND 8 Releases ************************************************************************** Description: Assume that the following self-referential resource record is in the cache on a nameserver: foo.example. IN A CNAME foo.example. The actual domain name used doesn't 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(). The problem is not likely to occur in normal usage, but an attacker can easily exploit the vulnerability and cause a denial of service. Vulnerable Systems: If the BIND 8 server is not recursive and does not fetch glue, then the problem can 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 vulnerable. 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. III. Solution Workaround for Topic 1: Disable inverse queries by editing named.conf so that either there is no "fake-iquery" entry in the "options" block, or so that the entry is "fake-iquery no;" Workaround for Topic 2: A workaround is to set the global zone transfer ACL to deny access to all hosts by adding the following line to the "options" block allow-transfer { none; }; Next, explicitly authorize zone transfers for each authoritative zone. For example, if the server was authoritative for "example", adding allow-transfer { any; }; to the "zone" statement for "example" would allow anyone to transfer "example". None of the domains the server is authoritative for should have self-referential CNAMEs. Correction for both Topics: The proper solution is to Upgrade to the bind-8.1.1-5 packages. They can be found on Caldera's FTP site at: ftp://ftp.caldera.com/pub/OpenLinux/updates/1.2/006/RPMS The corresponding source code can be found at: ftp://ftp.caldera.com/pub/OpenLinux/updates/1.2/006/SRPMS The MD5 checksums (from the "md5sum" command) for these packages are: b63ace6eab6eee5cf0608c8a245b5e27 bind-8.1.1-5.i386.rpm 4123b0167f5d5769a87cd2d9542a74b4 bind-doc-8.1.1-5.i386.rpm e1d506cbcc87d7c1de915d94d03281b1 bind-utils-8.1.1-5.i386.rpm eec24c0f816244c4729281867fcebbab bind-8.1.1-5.src.rpm Upgrade with the following commands: rpm -q bind && rpm -U bind-8.1.1-5.i386.rpm rpm -q bind-utils && rpm -U bind-utils-8.1.1-5.i386.rpm rpm -q bind-doc && rpm -U bind-doc-8.1.1-5.i386.rpm IV. References This and other Caldera security resources are located at: http://www.caldera.com/tech-ref/security/ Additional documentation on this problem can be found in CERT Advisory CA-98.05 originally issued on April 08, 1998. (See ftp://ftp.cert.org/pub/cert_advisories/CA-98.05.bind_problems) This security fix closes Caldera's internal Problem Report 1868 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNSzXBen+9R4958LpAQHDFwP/QWd/McI/j5ftlGu+2urzw/QfTzJLjVqi mGuMhbqk6k/TCL0y1NGdBVoG2NYLbFpUBiGsK0JQkdXacx5Ghn+3UrhkyguhsgLV EnaEVaJ06IkCBCdRHAm0aiTw8YMEzIiUwRQOVx8bmgJM7J4q7p7szO1VA/LnDe85 vClCh9j/kyU= =ityb -----END PGP SIGNATURE----- - Notes: To learn how to use this list server, email a "help" command to majordomo@rim.caldera.com.