-----BEGIN PGP SIGNED MESSAGE----- __________________________________________________________ The U.S. Department of Energy Computer Incident Advisory Capability ___ __ __ _ ___ / | /_\ / \___ __|__ / \ \___ __________________________________________________________ INFORMATION BULLETIN Domain Name Service Vulnerabilites February 28, 1996 08:00 GMT Number G-14 ______________________________________________________________________________ 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. _______________________________________________________________________________ CIAC, the Computer Incident Advisory Capability, is the computer security incident response team for the U.S. Department of Energy (DOE) and the National Institute of Health (NIH). CIAC is located at the Lawrence Livermore National Laboratory in Livermore, California. CIAC is also a founding member of FIRST, the Forum of Incident Response and Security Teams, a global organization established to foster cooperation and coordination among computer security teams worldwide. CIAC services are available to DOE, DOE contractors, and the NIH. CIAC can be contacted at: Voice: +1 510-422-8193 FAX: +1 510-423-8002 STU-III: +1 510-423-2604 E-mail: ciac@llnl.gov For emergencies and off-hour assistance, DOE, DOE contractor sites, and the NIH may contact CIAC 24-hours a day. During off hours (5PM - 8AM PST), call the CIAC voice number 510-422-8193 and leave a message, or call 800-759-7243 (800-SKY-PAGE) to send a Sky Page. CIAC has two Sky Page PIN numbers, the primary PIN number, 8550070, is for the CIAC duty person, and the secondary PIN number, 8550074 is for the CIAC Project Leader. Previous CIAC notices, anti-virus software, and other information are available from the CIAC Computer Security Archive. World Wide Web: http://ciac.llnl.gov/ Anonymous FTP: ciac.llnl.gov (128.115.19.53) Modem access: +1 (510) 423-4753 (28.8K baud) +1 (510) 423-3331 (28.8K baud) CIAC has several self-subscribing mailing lists for electronic publications: 1. CIAC-BULLETIN for Advisories, highest priority - time critical information and Bulletins, important computer security information; 2. CIAC-NOTES for Notes, a collection of computer security articles; 3. SPI-ANNOUNCE for official news about Security Profile Inspector (SPI) software updates, new features, distribution and availability; 4. SPI-NOTES, for discussion of problems and solutions regarding the use of SPI products. Our mailing lists are managed by a public domain software package called ListProcessor, which ignores E-mail header subject lines. To subscribe (add yourself) to one of our mailing lists, send the following request as the E-mail message body, substituting CIAC-BULLETIN, CIAC-NOTES, SPI-ANNOUNCE or SPI-NOTES for list-name and valid information for LastName FirstName and PhoneNumber when sending E-mail to ciac-listproc@llnl.gov: subscribe list-name LastName, FirstName PhoneNumber e.g., subscribe ciac-notes OHara, Scarlett W. 404-555-1212 x36 You will receive an acknowledgment containing address, initial PIN, and information on how to change either of them, cancel your subscription, or get help. PLEASE NOTE: Many users outside of the DOE, ESnet, and NIH computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Your agency's team will coordinate with CIAC. The Forum of Incident Response and Security Teams (FIRST) is a world-wide organization. A list of FIRST member organizations and their constituencies can be obtained by sending email to docserver@first.org with an empty subject line and a message body containing the line: send first-contacts. This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or the University of California, and shall not be used for advertising or product endorsement purposes. LAST 10 CIAC BULLETINS ISSUED (Previous bulletins available from CIAC) (G-4) X Authentication Vulnerability (G-5) HP-UX FTP Vulnerability Bulletin (G-6) Windows 95 Vulnerability (G-7) SGI Object Server Vulnerability (G-8) splitvt(1) Vulnerability (G-9b) Unix sendmail Vulnerability (G-10a) Winword Macro Viruses (G-11) HP Syslog Vulnerability (G-12) SGI ATT Packaging Utility Security Vulnerability (G-13) Kerberos 4 Key Server Vulnerability RECENT CIAC NOTES ISSUED (Previous Notes available from CIAC) Notes 07 - 3/29/95 A comprehensive review of SATAN Notes 08 - 4/4/95 A Courtney update Notes 09 - 4/24/95 More on the "Good Times" virus urban legend Notes 10 - 6/16/95 PKZ300B Trojan, Logdaemon/FreeBSD, vulnerability in S/Key, EBOLA Virus Hoax, and Caibua Virus Notes 11 - 7/31/95 Virus Update, Hats Off to Administrators, America On-Line Virus Scare, SPI 3.2.2 Released, The Die_Hard Virus Notes 12 - 9/12/95 Securely configuring Public Telnet Services, X Windows, beta release of Merlin, Microsoft Word Macro Viruses, Allegations of Inappropriate Data Collection in Win95 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface iQCVAwUBMTZA3bnzJzdsy3QZAQFPMgP9HyD6q59jxrYPvKnhiBbcKeiUaikmp8Yy vbEtZq63U65WYIBPS/te/MdycpPGuFRlTEiZLsfjgVW45oWnFBFcwdHFIaRE/Xbq GwGT00CUHrNDtJqUHFreTDqeW8WAjparIAq62CFjAuBVeXEYCCP49JvhuWGgnN9v 7eNMK+d3KnE= =B3yW -----END PGP SIGNATURE-----