-----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-----