Copyright 2022 - CSIM - Asian Institute of Technology

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]


CERT(sm) Advisory CA-97.05
Original issue date: January 28, 1997
Last revised: --
Topic: MIME Conversion Buffer Overflow in Sendmail Versions 8.8.3 and 8.8.4
- -----------------------------------------------------------------------------

The CERT Coordination Center has received reports of a vulnerability in
sendmail versions 8.8.3 and 8.8.4. By sending a carefully crafted email
message to a system running a vulnerable version of sendmail, intruders
may be able to force sendmail to execute arbitrary commands with root

The CERT/CC team recommends that you install a vendor patch (Section III.A) or
upgrade to sendmail 8.8.5 (Section III.B). We have provided a workaround that
you can use on vulnerable versions of 8.8.3 and 8.8.4 until you are able to
implement one of these solutions (Section III.C). Regardless of the solution
you apply, we urge you to take the additional precautions described in Section
III.D. Note that this advisory contains additional material to that previously
published by other response teams.

We will update this advisory as we receive additional information. Please
check advisory files regularly for updates that relate to your site.

- -----------------------------------------------------------------------------

I.   Description

     Sendmail version 8 contains support for MIME (Multipurpose Internet
     Mail Extensions) as defined initially by RFC 1341 and modified by RFC
     1521. The central idea behind MIME is the following, taken from the
     introduction to RFC 1341:

       "... designed to provide facilities to include multiple objects
       in a single message, to represent body text in character sets other
       than US-ASCII, to represent formatted multi-font text messages, to
       represent non-textual material such as images and audio fragments,
       and generally to facilitate later extensions defining new types of
       Internet mail for use by cooperating mail agents."

     The support in sendmail version 8 includes data translations in which a
     message's body is either stripped to 7-bit ASCII, achieved by forcing the
     8th bit to be off, or 8-bit MIME, achieved by leaving the 8th bit as is.

     Sendmail can be configured for either of these translations on a
     mailer-by-mailer basis depending on the flags defined for that
     mailer. The flags in question here are `7', `8', and `9' (the default).
     Refer to the "Sendmail Installation and Operations Guide," Section 5.4,
     for a more complete discussion. A PostScript version of this guide is
     included in the sendmail distribution in the /doc/op directory.

     With the release of sendmail version 8.8.3, a serious security
     vulnerability was introduced that allows remote users to execute
     arbitrary commands on the local system with root privileges. By sending
     a carefully crafted email message to a system running a vulnerable
     version of sendmail, intruders may be able to force sendmail to execute
     arbitrary commands with root privileges. Those commands are run on the
     same system where the vulnerable sendmail is running.

     In most cases, the MIME conversion of email is done on final delivery;
     that is, to the local mailbox or a program. Therefore, this vulnerability
     may be exploited on systems despite firewalls and other network boundary
     protective measures.

     Versions before 8.8.3 do not contain this vulnerability, but they 
     do contain other vulnerabilities. We strongly recommended that you 
     follow the steps given in Section III below to eliminate those
     vulnerabilities from your systems.

     Determining if you are vulnerable
     Systems are vulnerable to this attack if both of the following
     conditions are true:

     1. The version of sendmail is 8.8.3 or 8.8.4. To determine the
        version of sendmail, use the following command:

         % /usr/lib/sendmail -d0 -bt < /dev/null | grep -i Version

        If the string returned is "Version 8.8.3" or "Version 8.8.4", then
        this version of sendmail contains the vulnerability. Typically,
        sendmail is located in the /usr/lib directory, but it may be elsewhere
        on your system.

     2. When you examine the sendmail configuration file (usually,
        /etc/, the `9' flag is set in the "F=" (Flags) section for
        any Mailer specifications (Sections starting with `M' in the first
        column, such as "Mprog" or "Mlocal").
        Use of the `9' flag can usually be determined using the
        following command (depending on your sendmail configuration):

         % grep '^M.*F=[^,]*9' /etc/

        If any lines are output from this command, then the sendmail
        configuration may be vulnerable.

        The `9' flag is set by default for the local and program mailers when
        the file is generated using the m4 files distributed with
        sendmail version 8.8.x. Versions of sendmail before 8.8.0 did not set
        this flag by default when generating The `9' flag is also
        set by default in the precompiled example configuration files found in
        the cf/cf/obj/ subdirectory of the sendmail version 8.8.x distribution.

II. Impact

     Remote users can gain root privileges on a machine running sendmail
     versions 8.8.3 or 8.8.4 that does 7-to-8 bit conversion. They do not
     need access to an account on the system to exploit the vulnerability.

III. Solution

     Install a patch from your vendor if one is available (Section A) or
     upgrade to the current version of sendmail (Section B). Until you can
     take one of those actions, we recommend applying the workaround described
     in Section C. In all cases, you should take the precautions described
     in Section D.

     A. Install a vendor patch.

        Below is a list of vendors who have provided information about
        sendmail. Details are in Appendix A of this advisory; we will update
        the appendix as we receive more information. If your vendor's name
        is not on this list, the CERT/CC did not hear from that vendor.
        Please contact the vendor directly.

           Berkeley Software Design, Inc. (BSDI)
           Caldera OpenLinux
           Cray Research - A Silicon Graphics Company
           Data General Corporation
           Digital Equipment Corporation
           Hewlett-Packard Corporation
           IBM Corporation
           NEC Corporation
           NeXT Software, Inc.
           Silicon Graphics, Inc.
           Sun Microsystems, Inc.

     B. Upgrade to sendmail version 8.8.5.

        Eric Allman has released a new version of sendmail which fixes this
        vulnerability. This can be obtained from the following locations:

        The MD5 checksum for this distribution is:

        MD5 (sendmail.8.8.5.patch) = 775c47d16d40ebd2b917dfcc65d92e90
        MD5 (sendmail.8.8.5.tar.gz) = 7c32c42a91325dd00b8518e90c26cffa
        MD5 (sendmail.8.8.5.tar.sig) = b62ba16c7e863853b3efeb955eec4214
        MD5 (sendmail.8.8.5.tar.Z) = 7b847383899c0eb65987213a5caf89c8

        Also in that directory are .Z and .sig files. The .Z file contains
        the same bits as the .gz file, but it is compressed using UNIX compress
        instead of gzip. The .sig is Eric Allman's PGP signature for the
        uncompressed tar file. The key fingerprint is

    Type bits/keyID    Date       User ID
    pub  1024/BF7BA421 1995/02/23 Eric P. Allman <This email address is being protected from spambots. You need JavaScript enabled to view it.>
            Key fingerprint =  C0 28 E6 7B 13 5B 29 02  6F 7E 43 3A 48 4F 45 29
                                Eric P. Allman <This email address is being protected from spambots. You need JavaScript enabled to view it.>
                                Eric P. Allman <This email address is being protected from spambots. You need JavaScript enabled to view it.>
                                Eric P. Allman <This email address is being protected from spambots. You need JavaScript enabled to view it.>
                                Eric P. Allman <This email address is being protected from spambots. You need JavaScript enabled to view it.>

        When you change to a new version of sendmail, we strongly recommend
        also changing to the configuration files that are provided with that
        version. (In fact, it is highly likely that older configuration files
        will not work correctly with sendmail version 8.) It is now possible
        to build a sendmail configuration file ( using the
        configuration files provided with the sendmail release. Consult the
        cf/README file for a more complete explanation. Creating your
        configuration files using this method makes it easier to incorporate
        future changes to sendmail into your configuration files.

     C. Workaround for existing sendmail version 8.8.3 and 8.8.4 installations

        Eric Allman, the author of sendmail, has provided the following
        workaround, which you can use until you can take the steps recommended
        in Sec. A or B. 

        The /etc/ file should be modified to remove the use of the
        `9' flag for all Mailer specifications (lines starting with `M').

        As an example, the file should look similar to the
        following which is for a Solaris 2.5.1 system running sendmail
        version 8.8.4:

Mlocal,    P=/usr/lib/mail.local, F=lsDFMAw5:/|@qSnE, S=10/30, R=20/40,
           A=mail -d $u
Mprog,     P=/usr/local/bin/smrsh, F=lsDFMoqeu, S=10/30, R=20/40,
           A=sh -c $u

        This can be achieved for the "Mlocal" and "Mprog" Mailers by modifying
        the ".mc" file to include the following lines:
                FEATURE(smrsh, /usr/local/bin/smrsh)
                define(`LOCAL_MAILER_PATH', /usr/lib/mail.local)
                                `translit(LOCAL_MAILER_FLAGS, `9')',
                                `translit(LOCAL_SHELL_FLAGS, `9')',

        Next, rebuild the file using m4(1). See also Section III.D
        for additional precautions that you should take. These precautions
        have been taken in the example above.

        The defines of LOCAL_MAILER_FLAGS and LOCAL_SHELL_FLAGS should be
        placed in your m4(1) input file *after* the operating system is
        identified using the OSTYPE directive, and after any other defines of

        It is possible to directly edit the file to resolve this
        vulnerability. However, take caution to ensure that the
        file is not replaced in the future with a new version rebuilt from
        configuration files that include the `9' flag.

        Once the configuration file has been modified, all running versions
        of sendmail should be killed and the sendmail daemon restarted with
        the following (done as root):

                # kill -1 `head -1 /var/run/`

        The pathname may be different on your system. Verify that a new
        daemon was started using "(echo quit; sleep 1) | telnet localhost 25".
        Alternatively, reboot your system.

    D.  Take additional precautions

        Regardless of which solution you apply, you should take these extra
        precautions to protect your systems. These precautions do not address
        the vulnerabilities described herein, but are recommended as good
        practices to follow for the safer operation of sendmail.

        * Use the sendmail restricted shell program (smrsh)

           With *all* versions of sendmail, use the sendmail restricted
           shell program (smrsh). You should do this whether you use
           vendor-supplied sendmail or install sendmail yourself. Using
           smrsh gives you improved administrative control over the programs
           sendmail executes on behalf of users.

           Many sites have reported some confusion about the need to continue
           using the sendmail restricted shell program (smrsh) when they
           install a vendor patch or upgrade to a new version of sendmail. You
           should always use the smrsh program.

           smrsh is included in the sendmail Version 8 distribution in the
           subdirectory smrsh. See the RELEASE_NOTES file for a description
           of how to integrate smrsh into your sendmail configuration file.

           smrsh is also distributed with some operating systems.

           If you are using the m4(1)-based configuration scheme provided
           with sendmail 8.X, add the following to your configuration file,
           where /usr/local/bin is replaced by the name of the directory
           where you have installed smrsh on your system:

             FEATURE(smrsh, /usr/local/bin/smrsh)

        * Use mail.local

          If you run /bin/mail based on BSD 4.3 UNIX, replace /bin/mail with
          mail.local, which is included in the sendmail distribution. As of
          Solaris 2.5 and beyond, mail.local is included with the standard
          distribution. It is also included with some other operating systems
          distributions, such as FreeBSD.

          Although the current version of mail.local is not a perfect
          solution, it is important to use it because it addresses
          vulnerabilities that are being exploited. For more details, see
          CERT advisory CA-95:02:

          To use mail.local, replace all references to /bin/mail with
          /usr/lib/mail.local. If you are using the M4(1)-based configuration
          scheme provided with sendmail 8.X, add the following to your
          configuration file:

             define(`LOCAL_MAILER_PATH', /usr/lib/mail.local)

        * WARNING: Check for setuid executable copies of old versions of
                   mail programs

          If you leave setuid executable copies of older versions of
          sendmail installed in /usr/lib (on some systems it may be
          installed elsewhere), the vulnerabilities in those versions could
          be exploited if an intruder gains access to your system. This
          applies to as well as other sendmail programs. Either
          delete these versions or change the protections on them to be

          Similarly, if you replace /bin/mail with mail.local, remember to
          remove old copies of /bin/mail or make them non-executable.


Appendix A - Vendor Information

Below is a list of the vendors who have provided information for this
advisory. We will update this appendix as we receive additional information.
If you do not see your vendor's name, please contact the vendor directly.

Berkeley Software Design, Inc. (BSDI)
   Fully patched BSD/OS 2.1 systems are vulnerable to this problem. An
   official patch is available from the patches server at <This email address is being protected from spambots. You need JavaScript enabled to view it.>
   or via anonymous ftp from:


Caldera OpenLinux
   An upgrade for Caldera OpenLinux Base 1.0 can be found at:

   See also the README at:

Cray Research - A Silicon Graphics Company
   Cray Research has not yet released a sendmail based on a version 8.8.3 or
   later, so this is not a problem for any released Unicos system. 

Data General Corporation
   The sendmail that ships with DG/UX is not subject to this vulnerability. 

Digital Equipment Corporation
   This reported problem is not present for Digital's ULTRIX or
   Digital UNIX Operating Systems Software.

        Digital Equipment Corporation
        Software Security Response Team
        Copyright (c) Digital Equipment Corporation 1997. All rights reserved.

Hewlett-Packard Corporation
   After an investigation based on the information contained in the CERT
   bulletin, we have come to the conclusion that none of the current versions
   of HP sendmail (HPUX 9.x, HPUX pre-10.2, HPUX 10.2) are vulnerable to the
   security hole mentioned in the bulletin.

IBM Corporation
   The version of sendmail shipped with AIX is not vulnerable to the 7
   to 8 bit MIME conversion vulnerability detailed in this advisory.

   IBM and AIX are registered trademarks of International Business Machines

NEC Corporation
   Now investigating.
   Contacts for further information by
   e-mail:This email address is being protected from spambots. You need JavaScript enabled to view it..

NeXT Software, Inc.
   NeXT is not vulnerable to the MIME-buffer overflow attack.

Silicon Graphics, Inc.
   The versions of sendmail provided in the distributed Silicon Graphics IRIX
   operating system versions 5.2, 5.3, 6.0, 6.0.1, 6.1, 6.2 and 6.3 (and in
   SGI patch 1502, which is the latest released patch for sendmail) are
   8.6.x versions of the sendmail program. The latest official released
   version of sendmail from Silicon Graphics is 8.6.12. As such, Silicon
   Graphics finds no current version of Silicon Graphics sendmail to be
   vulnerable to this 8.8.x based attack.

Sun Microsystems, Inc.
   Sun is confident that no Sun sendmail is vulnerable to the MIME-buffer
   overflow attack.

- -----------------------------------------------------------------------------
The CERT Coordination Center thanks Eric Allman for his help in developing
the patches for sendmail and in the writing of this advisory. Thanks also
to DFN-CERT and AUSCERT for their assistance in producing this document.
- -----------------------------------------------------------------------------

If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in the Forum of Incident Response 
and Security Teams (see 

CERT/CC Contact Information 
- ---------------------------- 
Email    This email address is being protected from spambots. You need JavaScript enabled to view it.

Phone    +1 412-268-7090 (24-hour hotline)
                CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4)
                and are on call for emergencies during other hours.

Fax      +1 412-268-6989

Postal address
         CERT Coordination Center
         Software Engineering Institute
         Carnegie Mellon University
         Pittsburgh PA 15213-3890

Using encryption
   We strongly urge you to encrypt sensitive information sent by email. We can
   support a shared DES key or PGP. Contact the CERT/CC for more information. 
   Location of CERT PGP key

Getting security information
   CERT publications and other security information are available from

   CERT advisories and bulletins are also posted on the USENET newsgroup 

   To be added to our mailing list for advisories and bulletins, send your
   email address to 
        This email address is being protected from spambots. You need JavaScript enabled to view it. 

- ---------------------------------------------------------------------------
Copyright 1997 Carnegie Mellon University
This material may be reproduced and distributed without permission provided
it is used for noncommercial purposes and the copyright statement is

CERT is a service mark of Carnegie Mellon University.
- ---------------------------------------------------------------------------

This file:
               click on "CERT Advisories"

Revision history

Version: 2.6.2


Powered by: MHonArc

Login Form


School of Engineering and technologies     Asian Institute of Technology