Domain Name Service Vulnerabilites
Privacy and Legal Notice
INFORMATION BULLETIN
G-14: Domain Name Service Vulnerabilites
February 28, 1996 08:00 GMT
PROBLEM: Reports have been received of Domain Name Service (DNS) servers
being exploited, using BIND and sendmail weaknesses.
PLATFORM: Systems running DNS servers; programs which access those
servers (like sendmail).
DAMAGE: Vulnerabilities exist in Domain Name Service (DNS) servers,
allowing data to be corrupted.
SOLUTION: Patches are available for several platforms. See below.
VULNERABILITY Intruders have been able to exploit this vulnerability on DNS
ASSESSMENT: servers. This vulnerability may potentially extend to other
network services.
CERT has released two advisories related to Domain Name Service
vulnerabilities. One relates to vulnerabilities in the Berkeley
Internet Name Domain (BIND) program, allowing an intruder to corrupt
data provided by a Domain Name Service (DNS) server. The other relates
to a sendmail, which can be taken adantage of if a DNS server has been
compromised (by the BIND vulnerbality or other means). Silicon
Graphics Incorporated subsequently released an update to the sendmail
vulnerability, which has been integrated into the CERT advisory below.
[ Start CERT Advisory ]
=============================================================================
CERT(sm) Advisory CA-96.02
February 15, 1996
Topic: BIND Version 4.9.3
-----------------------------------------------------------------------------
Vulnerabilities in the Berkeley Internet Name Domain (BIND) program make it
possible for intruders to render Domain Name System (DNS) information
unreliable. At the beginning of this year, a version of BIND (4.9.3) became
available that fixes several security problems that are being exploited by
the intruder community.
The CERT staff urges you to install the appropriate patch from your vendor. If
a patch is not currently available, an alternative is to install BIND 4.9.3
yourself. (Note: Although BIND will be further improved in the future, we urge
you to upgrade now because of the seriousness of the problems addressed by
version 4.9.3.) If neither of the above alternatives is possible, we strongly
recommend blocking or turning off DNS name-based authentication services such
as rlogin.
As we receive additional information relating to this advisory, we will add it
to
ftp://info.cert.org/pub/cert_advisories/CA-96.02.README
We encourage you to check our README files regularly for updates on advisories
that relate to your site.
-----------------------------------------------------------------------------
I. Description
Version 4.9.3 of the Berkeley Internet Name Domain (BIND) program
fixes several security problems that are well known and being
exploited by the intruder community to render Domain Name System (DNS)
information unreliable.
BIND is an implementation of the Domain Name System. (For details,
see RFC 1035, a publication of the Internet Engineering Task Force.)
The full distribution of BIND includes a number of programs and resolver
library routines. The main program is "named", the daemon that provides
DNS information from local configuration files and a local cache. The
named daemon is often called /etc/named or /etc/in.named. Programs such
as Telnet communicate with named via the resolver library routines
provided in the BIND distribution.
Services in widespread use that depend on DNS information for
authentication include rlogin, rsh (rcp), xhost, and NFS. Sites may
have installed locally other services that trust DNS information.
In addition, many other services, such as Telnet, FTP, and email,
trust DNS information. If these services are used only to make outbound
connections or informational logs about the source of connections, the
security impact is less severe than for services such as rlogin. Although
you might be willing to accept the risks associated with using these
services for now, you need to consider the impact that spoofed DNS
information may have.
Although the new BIND distributions do address important security
problems, not all known problems are fixed. In particular, several
problems can be fixed only with the use of cryptographic authentication
techniques. Implementing and deploying this solution is non-trivial;
work on this task is currently underway within the Internet community.
II. Impact
It is possible for intruders to spoof BIND into providing incorrect
name data. Some systems and programs depend on this information for
authentication, so it is possible to spoof those systems and gain
unauthorized access.
III. Solutions
The preferred solution, described in Section A, is to install your
vendor's patch if one is available. An alternative (Section B) is to
install the latest version of BIND. In both cases, we encourage you to
take the additional precautions described in Section C.
A. Obtain the appropriate patch from your vendor and install it according to
instructions included with the program.
Redistributing BIND and all programs affected by these problems is not
a simple matter, so some vendors are working on new named daemon as an
immediate patch. Although installing a new named daemon addresses some
problems, significant problems remain that can be addressed only by
fully installing fixes to the library resolver routines.
If your vendor's patch does not include both named and new resolver
routines, we recommend that you install the current version of BIND
(Solution B) if possible. We also encourage you to take the precautions
described in Section C.
Below is a list of the vendors and the status they have provided
concerning BIND. More complete information is provided in Appendix A
of this advisory and reproduced in CA-96.02.README. We will update
the README file as we receive more information from vendors.
If your vendor's name is not on the list, contact the vendor directly for
status information and further instructions.
Vendor New named available Full distribution available
------ ------------------- ---------------------------
Digital Equipment Work is under way.
Hewlett-Packard Under investigation. Currently porting and testing
(BIND 4.9.3) for the Q1, Calendar 97
general release. Patch in process
for 10.X releases.
NEC Corporation Work is under way.
Santa Cruz Operation Under consideration.
B. Install the latest version of BIND (version 4.9.3), available from Paul
Vixie, the current maintainer of BIND:
ftp://ftp.vix.com/pub/bind/release/4.9.3/bind-4.9.3-REL.tar.gz
MD5 (bind-4.9.3-REL.tar.gz) = da1908b001f8e6dc93fe02589b989ef1
Also get Patch #1 for 4.9.3:
ftp://ftp.vix.com/pub/bind/release/4.9.3/Patch1
MD5 (Patch1) = 5d57ad13381e242cb08b5da0e1e9c5b9
C. Take additional precautions.
To protect against vulnerabilities that have not yet been addressed, and
as good security practice in general, filter at a router all name-based
authentication services so that you do not rely on DNS information for
authentication. This includes the services rlogin, rsh (rcp), xhost, NFS,
and any other locally installed services that provide trust based on
domain name information.
---------------------------------------------------------------------------
The CERT Coordination Center wishes to thank Paul Vixie for his efforts in
responding to this problem and his aid in developing this advisory.
---------------------------------------------------------------------------
[End CERT Advisory]
[ Start CERT Advisory (with changes) ]
=============================================================================
CERT(sm) Advisory CA-96.04
February 22, 1996
Topic: Corrupt Information from Network Servers
-----------------------------------------------------------------------------
The CERT Coordination Center has received reports of intruders exploiting
systems by corrupting data provided by a Domain Name Service (DNS) server.
Although these reports have focused only on DNS, this vulnerability could
apply to any network service from which data is received and subsequently
used.
Section III.A contains a pointer to two subroutines that address the DNS
problem. These subroutines, written in the C programming language, can be used
to validate host names and IP addresses according to RFCs 952 and 1123, as
well as names containing characters drawn from common practice, namely "_" and
"/".
In the specific case of sendmail, the problem has already been addressed by
patches (see Section III.B).
As we receive additional information relating to this advisory, we will place
it in
ftp://info.cert.org/pub/cert_advisories/CA-96.04.README
We encourage you to check our README files regularly for updates on
advisories that relate to your site.
-----------------------------------------------------------------------------
I. Description
Information provided by an information server may be of a form that
could cause programs to operate in unexpected ways. The subroutines and
programs transferring data from that information server could check the
data for correctness of form; however, programs that *use* that data are
ultimately responsible for ensuring adherence to the documents that
define the correct form.
For example, consider a program that uses the host name returned by
gethostbyname() as part of the string given to the popen() or system()
subroutines. Because gethostbyname() may use an information server
beyond your control, the data returned could be of a form that causes
the popen() or system() subroutines to execute other commands besides
the command specified by that program.
This advisory speaks to a specific instance of a problem caused by the
information returned by DNS, but information from any server should be
checked for validity. Examples of other information servers are YP, NIS,
NIS+, and netinfo.
II. Impact
Programs that do not check data provided by information servers may
operate in unpredictable ways and give unexpected results. In
particular, exploitation of this vulnerability may allow remote access
by unauthorized users. Exploitation can also lead to root access by both
local and remote users.
III. Solution
For programs that you write or have written, consider integrating the
general solution in Section A below.
In the specific case of the sendmail mail delivery program, Eric Allman,
the original author of sendmail, has produced patches that address the
problem. Section B provides details about these, along with vendor
information and additional steps you should take to protect sendmail.
A. General solution for Internet host names
Use the host name and IP address validation subroutines available
at the locations listed below. Include them in all programs that
use the result of the host name lookups in any way.
ftp://info.cert.org/pub/tools/ValidateHostname/IsValid.c
ftp://ftp.cert.dfn.de/pub/tools/net/ValidateHostname/IsValid.c
Checksum:
MD5 (IsValid.c) = 9456f2f5dcb226eaa19a72256c8d1922
The IsValid.c file contains code for the IsValidHostname and
IsValidIPAddress subroutines. This code can be used to check host
names and IP addresses for validity according to RFCs 952 and 1123,
well as names containing characters drawn from common practice,
namely "_" and "/".
B. Specific solutions in the case of sendmail
Install a patch from your vendor when it becomes available (see B.1)
or install Eric Allman's patch (B.2). In both cases, install the
sendmail restricted shell program (B.3).
1. Install a patch from your vendor.
Below is a summary of the vendors who have reported status to us as
of the date of this advisory. More complete information is provided in
the appendix of this advisory and reproduced in the CA-96.04.README
file. We will update the README file as we receive more information.
If your vendor's name is not on this list, please contact the vendor
directly.
Vendor or Source Status
---------------- ------------
Eric Allman Patches available.
Hewlett-Packard Co. Vulnerable, watch readme file for updates.
IBM Corporation Working on fixes for sendmail.
Silicon Graphics Inc. Patches available.
2. Install a patch to sendmail.
If you are presently running sendmail 8.6.12, there is a patch that
makes version 8.6.13.
Similarly, if you are presently running sendmail 8.7.3, there is a
patch that makes version 8.7.4.
The patches are available for anonymous FTP from
ftp://info.cert.org/pub/tools/sendmail/
ftp://ftp.cs.berkeley.edu/ucb/src/sendmail/
ftp://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu/ucb/sendmail/
ftp://ftp.cert.dfn.de/pub/tools/net/sendmail/
Checksums for the 8.6.13 release:
MD5 (sendmail.8.6.13.base.tar.Z) = e8cf3ea19876d9b9def5c0bcb793d241
MD5 (sendmail.8.6.13.cf.tar.Z) = 4492026fa9e750cd33974322cb5a6fb9
MD5 (sendmail.8.6.13.misc.tar.Z) = 7ec5d31656e93e08a3892f0ae542b674
MD5 (sendmail.8.6.13.xdoc.tar.Z) = e4d3caebcdc4912ed2ecce1a77e45712
Checksum for the 8.6.13 patch:
MD5 (sendmail.8.6.13.patch) = 6390b792cb5513ff622da8791d6d2073
Checksum for the 8.7.4 release:
MD5 (sendmail.8.7.4.tar.Z) = 4bf774a12752497527aae11e2bdbab36
Checksum for the 8.7.4 patch:
MD5 (sendmail.8.7.4.patch) = ef828ad91fe56e4eb6b0cacced864cd5
3. Run smrsh as additional protection for sendmail.
With all versions of sendmail, we recommend that you install and use
the sendmail restricted shell program (smrsh). We urge you to do
this whether you use the vendor's supplied sendmail, install sendmail
yourself, or patch an earlier version of sendmail.
Beginning with version 8.7.1, smrsh is included in the sendmail
distribution, in the subdirectory smrsh. See the RELEASE_NOTES file
for a description of how to integrate smrsh into your sendmail
configuration file.
---------------------------------------------------------------------------
The CERT Coordination Center thanks Eric Allman of Pangaea Reference Systems,
Andrew Gross of San Diego Supercomputer Center, Eric Halil of AUSCERT,
Wolfgang Ley of DFN-CERT, and Paul Vixie for their support in the development
of this advisory.
---------------------------------------------------------------------------
.........................................................................
Appendix A: Vendor Information
Current as of February 22, 1996
See CA-96.04.README for updated information.
Below is information we have received from vendors concerning the
vulnerability described in this advisory. If you do not see your vendor's
name, please contact the vendor directly for information.
-----------------------
Eric Allman (original author of sendmail)
Install a patch to sendmail.
If you are presently running sendmail 8.6.12, there is a patch that
makes version 8.6.13.
Similarly, if you are presently running sendmail 8.7.3, there is a
patch that makes version 8.7.4.
The patches are available for anonymous FTP from
ftp://info.cert.org/pub/tools/sendmail/
ftp://ftp.cs.berkeley.edu/ucb/src/sendmail/
ftp://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu/ucb/sendmail/
ftp://ftp.cert.dfn.de/pub/tools/net/sendmail/
Checksums for the 8.6.13 release:
MD5 (sendmail.8.6.13.base.tar.Z) = e8cf3ea19876d9b9def5c0bcb793d241
MD5 (sendmail.8.6.13.cf.tar.Z) = 4492026fa9e750cd33974322cb5a6fb9
MD5 (sendmail.8.6.13.misc.tar.Z) = 7ec5d31656e93e08a3892f0ae542b674
MD5 (sendmail.8.6.13.xdoc.tar.Z) = e4d3caebcdc4912ed2ecce1a77e45712
Checksum for the 8.6.13 patch:
MD5 (sendmail.8.6.13.patch) = 6390b792cb5513ff622da8791d6d2073
Checksum for the 8.7.4 release:
MD5 (sendmail.8.7.4.tar.Z) = 4bf774a12752497527aae11e2bdbab36
Checksum for the 8.7.4 patch:
MD5 (sendmail.8.7.4.patch) = ef828ad91fe56e4eb6b0cacced864cd5
----------------------
Hewlett-Packard Company
Vulnerable, watch readme file for updates.
----------------------
IBM Corporation
IBM is working on fixes for sendmail.
----------------------
Silicon Graphics Inc.
**** IRIX 3.x ****
Silicon Graphics Inc, no longer supports the IRIX 3.x operating system
and therefore has no patches or binaries to provide.
However, two possible actions still remain: 1) upgrade the system to a
supported version of IRIX (see below) and then install the patch or
2) obtain the sendmail source code from anonymous FTP at
ftp.cs.berkeley.edu and compile the program manually. Please, note
that SGI will not assist with or support 3rd party sendmail programs.
**** IRIX 4.x ****
As of the date of this document, SGI does not have a IRIX 4.x binary
replacement that addresses this particular issue. If in the future,
a replacement binary is generated, additional advisory information will
be provided.
However, two other possible actions are: 1) upgrade the system to a
supported version of IRIX (see below) and then install the patch or
2) obtain the sendmail source code from anonymous FTP at
ftp.cs.berkeley.edu and compile the program manually. Please, note
that SGI will not assist with or support 3rd party sendmail programs.
**** IRIX 5.0.x, 5.1.x ****
For the IRIX operating systems versions 5.0.x and 5.1.x, an upgrade
to 5.2 or better is required first. When the upgrade is completed,
then the patches described in the following sections can be applied
depending on the final version of the upgrade.
**** IRIX 5.2, 5.3, 6.0, 6.0.1, 6.1 ****
For the IRIX operating system versions 5.2, 5.3, 6.0, 6.0.1, and 6.1
an inst-able patch has been generated and made available via anonymous
FTP and your service/support provider. The patch is number 1146
and will install on IRIX 5.2, 5.3, 6.0 and 6.0.1.
The SGI anonymous FTP site is sgigate.sgi.com (204.94.209.1) or its
mirror, ftp.sgi.com. Patch 1146 can be found in the following
directories on the FTP server:
~ftp/Security
or
~ftp/Patches/5.2
~ftp/Patches/5.3
~ftp/Patches/6.0
~ftp/Patches/6.0.1
~ftp/Patches/6.1
##### Checksums ####
The actual patch will be a tar file containing the following files:
Filename: patchSG0001146
Algorithm #1 (sum -r): 15709 3 patchSG0001146
Algorithm #2 (sum): 16842 3 patchSG0001146
MD5 checksum: 055B660E1D5C1E38BC3128ADE7FC9A95
Filename: patchSG0001146.eoe1_man
Algorithm #1 (sum -r): 26276 76 patchSG0001146.eoe1_man
Algorithm #2 (sum): 1567 76 patchSG0001146.eoe1_man
MD5 checksum: 883BC696F0A57B47F1CBAFA74BF53E81
Filename: patchSG0001146.eoe1_sw
Algorithm #1 (sum -r): 61872 382 patchSG0001146.eoe1_sw
Algorithm #2 (sum): 42032 382 patchSG0001146.eoe1_sw
MD5 checksum: 412AB1A279A030192EA2A082CBA0D6E7
Filename: patchSG0001146.idb
Algorithm #1 (sum -r): 39588 4 patchSG0001146.idb
Algorithm #2 (sum): 10621 4 patchSG0001146.idb
MD5 checksum: 259DD47E4574DAF9041675D64C39102E
[ End CERT Advisory ]
CIAC wishes to acknowledge the contributions of CERT and SGI for the
information contained in this bulletin.
DOE-CIRC can be contacted at:
Voice: +1 866-941-2472 (7 x 24)
E-mail: doecirc@doecirc.energy.gov
World Wide Web: http://www.doecirc.energy.gov/