[ advisories | exploits | discussions | news | conventions | security tools | texts & papers ]
 main menu
- feedback
- advertising
- privacy
- FightAIDS
- newsletter
- news
- read forum
- new topic
- search

- meetings list
- recent additions
- add your info
 top 100 sites
- visit top sites
- sign up now
- members

- add your url
- add domain
- search box
- link to us

- our projects
- free email
 m4d network
- security software
- secureroot
- m4d.com
Home : Advisories : MIME Conversion Buffer Overflow in Sendmail Versions 8.8.3 and 8.8.4

Title: MIME Conversion Buffer Overflow in Sendmail Versions 8.8.3 and 8.8.4
Released by: CERT
Date: 28th January 1997
Printable version: Click here

Hash: SHA1


CERT(sm) Advisory CA-97.05

Original issue date: January 28, 1997

Last Revised: September 26, 1997

              Updated copyright statement

              A complete revision history is at the end of this file.

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/sendmail.cf), 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/sendmail.cf

        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 sendmail.cf 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 sendmail.cf. 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 

            Key fingerprint =  C0 28 E6 7B 13 5B 29 02  6F 7E 43 3A 48 4F 45 29

                                Eric P. Allman 

                                Eric P. Allman 

                                Eric P. Allman 

                                Eric P. Allman 

        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 (sendmail.cf) 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/sendmail.cf file should be modified to remove the use of the

        `9' flag for all Mailer specifications (lines starting with `M').

        As an example, the sendmail.cf 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=smrsh -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_SHELL_ARGS', `smrsh -c $u')

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



                                `translit(LOCAL_MAILER_FLAGS, `9')',




                                `translit(LOCAL_SHELL_FLAGS, `9')',


        Next, rebuild the sendmail.cf 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 sendmail.cf file to resolve this

        vulnerability. However, take caution to ensure that the sendmail.cf

        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/sendmail.pid`

        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 sendmail.mx 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 

   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


Systems below are not shipped with a sendmail based on

a version 8.8.3 or later, so this problem is not present

for them.

   UX/4800              Not vulnerable for all versions.

   EWS-UX/V(Rel4.2MP)   Not vulnerable for all versions.

   EWS-UX/V(Rel4.2)     Not vulnerable for all versions.

   UP-UX/V(Rel4.2MP)    Not vulnerable for all versions.

   EWS-UX/V(Rel4.0)     Not vulnerable for all versions.

   UP-UX/V              Not vulnerable for all versions.

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 http://info.cert.org/pub/FIRST/first-contacts).

CERT/CC Contact Information

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

Email    cert@cert.org

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


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

Copyright 1997 Carnegie Mellon University. Conditions for use, disclaimers,

and sponsorship information can be found in

http://www.cert.org/legal_stuff.html and http://ftp.cert.org/pub/legal_stuff .

If you do not have FTP or web access, send mail to cert@cert.org with

"copyright" in the subject line.

CERT is registered in the U.S. Patent and Trademark Office.

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

This file: http://info.cert.org/pub/cert_advisories/CA-97.05.sendmail


               click on "CERT Advisories"


Revision history

Sep. 26, 1997  Updated copyright statement

Mar. 05, 1997  Appendix A, updated NEC entry.

Feb. 11, 1997  Sec. III. C, example sendmail.cf file - one line changed and one

               added (changes marked at the left margin)


Version: PGP for Personal Privacy 5.0

Charset: noconv





(C) 1999-2000 All rights reserved.