[ 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 : Sendmail Vulnerabilities

Title: Sendmail Vulnerabilities
Released by: CERT
Date: 18th September 1996
Printable version: Click here

Hash: SHA1


CERT(*) Advisory CA-96.20

Original issue date: September 18, 1996

Last Revised: December 9, 1998

              Updated vendor information for Silicon Graphics, Inc.

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

Topic: Sendmail Vulnerabilities

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

           ** See also CA-96.24.sendmail.daemon.mode for information

              about additional vulnerabilities in sendmail. **

The CERT Coordination Center has received reports of two security problems in

sendmail that affect all versions up to and including 8.7.5. By exploiting

the first of these vulnerabilities, users who have local accounts can gain

access to the default user, which is often daemon. By exploiting the second

vulnerability, any local user can gain root access.

The CERT/CC team recommends installing vendor patches or upgrading to the

current version of sendmail (8.7.6). Until you can do so, we urge you to

apply the workaround provided in Sec. III.C. In all cases, be sure to take

the extra precautions listed in Sec. III.D.

For beta testers of sendmail 8.8: The vulnerabilities described in this

advisory have been fixed in the beta version.

We will update this advisory as we receive additional information. Please

check advisory files regularly for updates that relate to your site. In

addition, you can check http://info.cert.org/pub/latest_sw_versions/sendmail

to identify the most current version of sendmail.

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

I.   Description

     There are two vulnerabilities in all versions of sendmail up to and

     including sendmail 8.7.5. The first vulnerability is a resource starvation

     problem and the second is a buffer overflow problem.

     Resource Starvation


     When email is forwarded to a program using a .forward file or an :include:

     statement within a .forward or alias file, that program is executed as the

     owner of the .forward file or the file referenced by the :include:

     statement. Similarly, if email is forwarded to a file, that file is

     opened as the owner of the .forward file or the file referenced by the

     :include: statement. The file owner is called the "controlling user."

     If the message cannot be delivered immediately, the name of the

     controlling user is written into the queue file along with the other

     delivery information so that the appropriate permissions can be acquired

     when the mail queue is processed.

     Only the name of the controlling user is written in the queue file. This

     name is derived by calling the system routine getpwuid(3) on the user id

     of the file owner. If getpwuid fails, the sendmail default user (defined

     by the DefaultUser option in 8.7 and by the "u" and "g" options in older

     releases) is assumed.

     In some cases, the system can be forced into resource starvation, thus

     forcing getpwuid(3) to fail even though an entry exists in /etc/passwd

     corresponding to that uid. Since getpwuid has no way of portably

     returning an error meaning "resource failure" as distinct from "user id

     not found," sendmail has no way of distinguishing between these cases; it

     assumes that the uid is unknown and falls back to the default user.

     By starving sendmail of specific resources, sendmail will create files

     owned by the default user. Once created, these files can be used to

     access other files owned by the default user. In addition, these files

     owned by the default user can be used to leverage access to other

     privileged users on the system.

     Buffer Overflows


     There are several buffer overflows present in sendmail version 8.7.5 and

     earlier. Some of the buffer overflows could result in local users gaining

     unauthorized root access.

     Significant work has been done on sendmail version 8.8 (now in beta

     test) to eliminate the problem, and the code changes originally planned

     for 8.8 have been backported to 8.7.6 to address these vulnerabilities.

II.  Impact

     Resource Starvation


     Anyone with access to an account on the system can run programs or write

     files as the default user. The danger of compromising the default user

     depends primarily on the other files in your system owned by that user.

     For example, on many systems the line printer spool directory (e.g.,

     /var/spool/lpd) is owned by daemon; because the line printer subsystem

     runs setuid root, it may be possible to gain additional privileges.

     However, some other systems have no files owned by user daemon on the

     default system, and the only files owned by group daemon are not

     writable by that group; hence, the danger is minimal.

     Buffer Overflows


     Anyone with access to an account on the system can gain root access.

III. Solution

     Install a patch from your vendor if one is available (Sec. A) or upgrade

     to the current version of sendmail (Sec. B). Until you can take one of

     those actions, we recommend applying the workaround described in Sec. C.

     This workaround addresses the resource starvation problem but not buffer


     In all cases, you should take the precautions listed in Sec. D.

     Note to beta testers of sendmail 8.8: The vulnerabilities described in

     this advisory have been fixed in the beta version of 8.8.

     A. Install a vendor patch.

        Below is a list of the 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, please contact the vendor directly.

            Digital Equipment Corporation


            Hewlett-Packard Company

            IBM Corporation


            Open Software Foundation

            The Santa Cruz Operation

            Silicon Graphics Inc.

            Sun Microsystems, Inc.

     B. Upgrade to the current version of sendmail.

        Install sendmail 8.7.6. This version is a "drop in" replacement for

        8.7.x. There is no patch for 8.6.x. If you are using version 8.6 or

        earlier, you need to upgrade to the current version and rebuild your

        sendmail.cf files. Upgrading to version 8.7.6 addresses both

        vulnerabilities described in this advisory.

        Sendmail 8.7.6 is available from





        MD5 (sendmail.8.7.6.tar.gz) = 4a1f2179c53c9106bc8d7738f4d55667

        Also in that directory are .Z and .sig files. The .Z file contains the

        same bits as the .gz file, but 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 

        We strongly recommend that when you change to a new version of sendmail

        you also change to the configuration files that are provided with that


        Significant work has been done to make this task easier. 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.

        For sites that use the ampersand character ('&') in the gecos

        field of /etc/passwd, they should be aware that this may cause the

        full name returned to be corrupted or empty. (See man (4) passwd

        for further details on the purpose of the ampersand character in the

        gecos field.) Therefore when configuring sendmail, sites may also

        wish to ensure that information in the gecos field is explicitly

        complete, rather than rely on name expansion using the ampersand


        Finally, for Sun users, a paper is available to help you convert your

        sendmail configuration files from the Sun version of sendmail to one

        that works with sendmail version 8.7.x. The paper is entitled

        "Converting Standard Sun Config Files to Sendmail Version 8" and was

        written by Rick McCarty of Texas Instruments Inc. It is included in

        the distribution and is located in contrib/converting.sun.configs.

     C. Apply a workaround.

        Resource Starvation


        Eric Allman, the author of sendmail, has provided the following

        workaround to the resource starvation vulnerability.

        Using smrsh as "prog" mailer limits the programs that can be run as

        the default user. Smrsh does not limit the files that can be written,

        but less damage can be done by writing files directly.

        The damage can be almost entirely constrained by ensuring that the

        default user is an innocuous one. Sendmail defaults to 1:1 (daemon)

        only because that is reasonably portable. A special "mailnull"

        account that is used only for this purpose would be better. This user

        should own no files and should have neither a real home directory nor

        a real shell. A sample password entry might be:

           mailnull:*:32765:32765:Sendmail Default User:/no/such/dir:/dev/null

        A corresponding entry should be made in /etc/group:


        These assume that there are no other users or groups with id = 32765

        on your system; if there are, pick some other unique value.

        NOTE: When allocating a numeric uid to the "mailnull" user you should

             be careful to ensure that this value is less than the value of

             the UID_MAX kernel variable, if your system implements this

             variable. To check whether your system implements this

             variable (and the value that it uses), check for a reference

             to it in the "limits.h" header file, which should be located

             in the directory /usr/include, or one of its subdirectories.

             For further information on the use and content on the "limits.h"

             header file, see the man (4) limits.

        After creating this user, change the line in /etc/sendmail.cf reading

           O DefaultUser=1:1

         to read

           O DefaultUser=mailnull

        If you are running 8.6.*, you will have to change the lines reading



        to read



       Finally, if you are using the m4(1)-based sendmail configuration scheme

       provided with sendmail 8.7.*, you should add the following line to the

       m4 input file, usually named sendmail.mc:

           define(`confDEF_USER_ID', 32765:32765)

       The actual values should, of course, match those in the passwd file.

       Buffer Overflows


       There is no workaround for the buffer overflow problem. To address this

       problem, you must apply your vendor's patches or upgrade to the current

       version of sendmail (version 8.7.6).

D. Take additional precautions.

   Regardless of which solution you apply, you should take these extra

   precautions to protect your systems.

   * 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


     A number of 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 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.

   * 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. It is also

     included with some other operating systems distributions, such as


     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.

     Note that as of Solaris 2.5 and beyond, mail.local is included with the

     standard distribution. 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 executable copies of old versions of mail programs

     If you leave 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 non-executable.

     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 has released a patch for BSD/OS V2.1 to update

   sendmail to the 8.7.6 version. The patch is available

   from the patches@BSDI.COM mailback server or via ftp at:


Digital Equipment Corporation


[About the resource starvation problem]


      Software Security Response Team

      Copyright (c) Digital Equipment Corporation 1996. All rights reserved.


   At the time of writing this document, patches (binary kits) for Digital's

   UNIX related operating systems are being developed. Digital will provide

   notice of availability for remedial kits through AES services (DIA, DSNlink

   FLASH), placed in the public FTP patch service domain and also be

   available from your normal Digital Support channel.


                                                |     |

                                                |     |--version

                                                |--osf or ultrix

    9/96                                   - DIGITAL EQUIPMENT CORPORATION



   All currently released FreeBSD distributions have this vulnerability, as

   we distribute sendmail 8.7.x as part of our operating system.  However,

   our -current and -stable source distributions were updated on 18 Sep 1996

   to sendmail 8.7.6.  Users tracking -current or -stable are advised to

   upgrade and recompile sendmail at their earliest convinience.

   An official FreeBSD security advisory, including patches to close this

   vulnerability in FreeBSD 2.1.5 will be available shortly.  The security

   advisory will appear at


   when available.

Hewlett-Packard Company




  Description: Sendmail patches for HP-UX releases 9.X thru 10.20

  Security Bulletins are available from the HP Electronic

  Support Center via electronic mail.

  User your browser to get to the HP Electronic Support

  Center page at:


           (for US, Canada, Asia-Pacific, & Latin-America)


           (for Europe)

IBM Corporation


  The following APARs are being developed and will be available shortly.

  See the appropriate release below to determine your action.

  AIX 3.2


    Apply the following fixes to your system:

       APAR - IX61303 IX61307

  AIX 4.1


    Apply the following fixes to your system:

        APAR - IX61162 IX61306

    To determine if you have this APAR on your system, run the following


       instfix -ik IX61162 IX61306

  AIX 4.2


    Apply the following fixes to your system:

        APAR - IX61304 IX61305

    To determine if you have this APAR on your system, run the following


       instfix -ik IX61304 IX61305

  To Order


    APARs may be ordered using Electronic Fix Distribution (via FixDist)

    or from the IBM Support Center.  For more information on FixDist,


    or send e-mail to aixserv@austin.ibm.com with a subject of "FixDist".

  IBM and AIX are registered trademarks of International Business Machines




[For the resource starvation problem:]

   Debian Linux: not vulnerable (uses smail)

   Red Hat and derivatives:


Open Software Foundation


   OSF's OSF/1 R1.3.2 is not vulnerable to these types of attacks described in

   the resource starvation sections of the advisory.

   OSF's OSF/1 R1.3.2 is vulnerable to the buffer overflow problems.

   We will address the problem in our next maintenance release.

The Santa Cruz Operation


   Any SCO operating system running a version of sendmail provided by SCO

   is vulnerable to this problem. SCO is providing Support Level

   Supplement (SLS) oss443a for the following releases to address this issue:

   SCO Internet FastStart release 1.0.0

   SCO OpenServer releases 5.0.0 and 5.0.2

   This SLS provides a pre-release version of sendmail release 8.7.6

   for these platforms. SCO hopes to have a final version of sendmail 8.7.6

   available to address both issues mentioned in this advisory in the near


   Note that only SCO Internet FastStart uses sendmail as the default mail

   system. All other SCO operating systems use other mail systems such as the

   Multi-Channel Memorandum Distribution Facility (MMDF) or the "mailsurr"

   mail system as the default, and as such are not vulnerable to this

   problem unless otherwise configured to use sendmail.

   SCO intends to provide a similar patch for SCO UnixWare release 2.1.0

   in the near future.

   When configured to use a version of sendmail provided by SCO, releases

   prior to the ones mentioned here are also vulnerable, but no

   plans have yet been made concerning patches for these earlier releases.

   You can download SLS oss443a as shown below.

   Anonymous ftp   (World Wide Web URL)


        http://ftp.sco.COM/SSE/oss443a           (SLS image)

        http://ftp.sco.COM/SSE/oss443a.ltr.sse   (cover letter/install notes)



   SLS oss443a is also available in the SCO Forum on Compuserve.

   SCO Online Support (SOS) BBS


   SLS oss443a can also be downloaded interactively via X, Y, or Z MODEM or

   Kermit, using the SCO Online Support System (SOS). Follow the menu

   selections under "Toolchest" from the main SOS menu.

   The phone numbers available for interactive transfer from SOS are:

   1-408-426-9495                  (USA)

   +44 (0)1923 210 888             (United Kingdom)



   sum -r


   13804   630 oss443a

   35304    14 oss443a.ltr.sse



   MD5 (oss443a) = 549260a71ca76f4e98dd38bccb72748c

   MD5 (oss443a.ltr.sse) = 7475d83f0db64a1af69eb66cd392a9d3

   Be sure to keep track of the README file at http://ftp.sco.COM/SSE/README

   for updates to this supplement.

   If you have further questions, contact your support provider. If you

   need to contact SCO, please send electronic mail to support@sco.COM, or

   contact SCO as follows.

        USA/Canada: 6am-5pm Pacific Daylight Time (PDT)


        1-800-347-4381  (voice)

        1-408-427-5443  (fax)

        Pacific Rim, Asia, and Latin American customers: 6am-5pm Pacific

        ------------------------------------------------ Daylight Time


        1-408-425-4726  (voice)

        1-408-427-5443  (fax)

        Europe, Middle East, Africa: 9am-5:30pm Greenwich Mean Time (GMT)


        +44 (0)1923 816344 (voice)

        +44 (0)1923 817781 (fax)

Silicon Graphics, Inc.


Please refer to Silicon Graphics Inc. Security Advisory, "IRIX

mail(1)/rmail(1M)/sendmail(1M) Security Vulnerabilities," Number:

19980604-02-PX, distributed September 29, 1998 for additional information

relating to this vulnerability.

The primary SGI anonymous FTP site for security information and patches is

sgigate.sgi.com (  Security information and patches are located

under the directories ~ftp/security and ~ftp/patches, respectively. The

Silicon Graphics Security Headquarters Web page is accessible at the URL


Sun Microsystems, Inc.


Sun Microsystems has provided the following list of patches in response

to this advisory:

        103594-10 5.5.1

        103595-10 5.5.1_86

        102980-13 5.5

        102981-13 5.5_x86

        102066-18 5.4

        102064-17 5.4_x86

        101739-17 5.3

        102423-07 4.1.4

        101665-10 4.1.3_U1

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

The CERT Coordination Center staff thanks Eric Allman, the author of sendmail,

for his extensive assistance with this advisory, Wolfgang Ley of DFN-CERT and

members of the AUSCERT for their contributions, and D. J. Bernstein of the

University of Illinois at Chicago for reporting the resource starvation


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

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.

   You can get the CERT PGP key from http://info.cert.org/pub/CERT_PGP.key

   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 1996, 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:



               click on "CERT Advisories"


Revision history

Dec.  9, 1998  Updated vendor information for Silicon Graphics, Inc.

Aug. 24, 1998  Updated vendor information for Silicon Graphics, Inc.

Oct. 20, 1997  Updated vendor information for Sun.

Sep. 24, 1997  Updated copyright statement

May 8, 1997    Appendix A - updated vendor information for Hewlett-Packard.

Nov. 21, 1996  Introduction - Added a pointer to CA-96.24 for information

                 on more sendmail vulnerabilities.

Nov. 19, 1996  Appendix A - Updated Hewlett-Packard information to address

                  both problems.

Sep. 21, 1996  Sec. III.B - added instructions on configuring sendmail at

                 sites that use '&' in the gecos filed of /etc/passwd.

               Sec. III.C - added a note on uid for "mailnull" user.

Sep. 19, 1996  Sec. III.B - added URL in Australia for sendmail

               Acknowledgements - included reference that had been omitted


               Appendix, FreeBSD - added an entry.

Sep. 18, 1996  Appendix, BSDI - added an entry containing patch information.


Version: PGP for Personal Privacy 5.0

Charset: noconv





(C) 1999-2000 All rights reserved.