=============================================================================
SA-93.10      SERT Advisory
         5-Nov-1993
          Sendmail Vulnerability
-----------------------------------------------------------------------------

The Security Emergency Response Team has received information that a number
of versions of sendmail(8) will leave systems vulnerable to compromise.

This Advisory supercedes the sendmail portion of the CERT Advisory
CA-93:15, issued 21-Oct-1993.

This vulnerability affects different implementations and varying versions
of sendmail(8) in different ways.  There is no fixed pattern to which 
versions are considered vulnerable and which are not.  In the absence of 
any specific vendor information, all implementations of sendmail(8) (except 
Eric Allman's sendmail 8.6.4) should be considered susceptible to this
vulnerability.  At this time, there are no known patches available for any
vendor implementation that fully address the vulnerability.


1.  Description.

    A vulnerability exists in many different implementations and versions
    of sendmail(8) which allow arbitrary programs to be run as
    any user (except root).

    A valid username and password on the local machine is not required to
    successfully exploit this vulnerability.

    This vulnerability affects any and all systems that receive mail as
    a final destination sendmail(8) host (except those running Eric
    Allman's sendmail 8.6.4).

    In all cases, the approach to the vulnerability is the same.

    The only version of sendmail(8) known not to contain any current
    vulnerabilities is Eric Allman's sendmail 8.6.4.

    NOTE:  All examples used in this Advisory have been tested under
     SunOS 4.1.3.  Commands and file placement may vary under
     different systems, or local configurations.


2.  Impact.

    sendmail(8) can be exploited to gain access to any account, except
    root.


3.  Approaches.

    In all cases, SERT recommends that you take immediate action to secure
    *ALL* systems running sendmail(8) from attack.  A number of options 
    are available to you, and it is your choice as to which option best 
    suits your needs.

3.1 Install sendmail 8.6.4.

    This approach is the only one that we believe does not contain any
    current vulnerabilities.
    This version of sendmail(8) is available via anonymous FTP from:
  ftp.sert.edu.au:/pub/sendmail/sendmail 8.6.4.*
    The checksums (using SunOS /bin/sum) are:
  07718   428 sendmail.8.6.4.base.tar.Z
  28004   179 sendmail.8.6.4.cf.tar.Z
  57299   102 sendmail.8.6.4.misc.tar.Z
  33954   251 sendmail.8.6.4.xdoc.tar.Z
    Advantage:  It is believed not to contain any current vulnerabilities.
    Disadvantage:  If you don't already run Eric Allman's sendmail.8.6.*,
  then it may take you some time to build, install, and configure
  the system to your needs.  The sendmail(8) configuration file from
  other types of sendmail(8) may not be compatible with sendmail 8.6.4.

3.2 Disable the program mailer.

    This approach is a workaround to the vulnerability.
    Edit the sendmail(8) configuration file, and change the line:
  Mprog,  P=/bin/sh,   F=lsDFMeuP,  S=10, R=20, A=sh -c $u
    to:
  Mprog,  P=/bin/false,   F=lsDFMeuP,  S=10, R=20, A=sh -c $u
    (See note 4.1).
    Advantage:  This will prevent the vulnerability being exploited on your
  system without major changes to the software configuration.
    Disadvantage:  Mailing to programs will no longer work.  This will
  affect for example, the use of vacation(1).  System administrators
  should check their aliases and all .forward files for any
  configuration that mails to a program.  These configurations will
  generate an error reply on every message mailed.  If the .forward
  file contains something similar to:
    \user, "| /usr/ucb/vacation user"
  then mail will still be delivered to "user", but an error reply
  (not the vacation message) will be returned to the sender.

3.3 Install Eric Allman's sendmail restricted shell (smrsh 1.2).

    This approach is a generic sendmail(8) vulnerability workaround
    that modifies the sendmail(8) configuration to restrict the sendmail(8)
    program mailer facility.  This solution is recommended only
    where vendor patches for this sendmail(8) vulnerability are
    not available.

    Familiarity with sendmail(8), its installation, and configuration
    are recommended before implementing these modifications.

    Copies of this program can be obtained from:
  ftp.sert.edu.au:/pub/smrsh/*
    The checksum (using SunOS /bin/sum) is:
  07289     6 README
  25757     2 smrsh.8
  46786     5 smrsh.c

    Edit the sendmail(8) configuration file, and change the line:
  Mprog,  P=/bin/sh,   F=lsDFMeuP,  S=10, R=20, A=sh -c $u
    to:
  Mprog,  P=/usr/etc/smrsh,   F=lsDFMeuP,  S=10, R=20, A=sh -c $u
    (See note 4.1).
    Install the smrsh.c program in /usr/etc/smrsh according to the
    instructions in the file header.

    For System V systems, "/usr/etc" may not exist.  This may be replaced
    by a local configuration, provided that users cannot write to that
    directory or modify the files within it.
    For example:
  drwxr-sr-x  5 root         3584 Nov  4 10:29 /local/smrsh
  Mprog,  P=/local/smrsh,   F=lsDFMeuP,  S=10, R=20, A=sh -c $u

    This program can be built for example by using the following command:
  host# /usr/ucb/cc -o ./smrsh ./smrsh.c
    On systems that support dynamic libraries, the program should be built
    using static library binding.
    For example, on SunOS:
  host# /usr/ucb/cc -Bstatic -o ./smrsh ./smrsh.c

    Move the binary to /usr/etc:
  host# /bin/cp ./smrsh /usr/etc/smrsh
  host# /usr/etc/chown root.daemon /usr/etc/smrsh
  host# /bin/chmod 511 /usr/etc/smrsh
    Create the smrsh administration directory (as defined by CMDDIR in
    smrsh.c):
  host# /bin/mkdir /usr/etc/sm.bin
  host# /bin/chmod 511 /usr/etc/sm.bin
    To allow a program to run, you need to create a symbolic link to it
    from within the sm.bin directory (for example):
  host# /bin/ln -s /usr/ucb/vacation /usr/adm/sm.bin/vacation

    NOTE:  It is very important that sites do *NOT* include interpreter
  programs such as /bin/sh, /bin/csh, /bin/perl, /bin/uudecode,
  /bin/sed, and so on in the list of allowed programs.

    Advantage:  This will prevent this class of vulnerability being 
  exploited on your system without requiring a new version of
  sendmail(8) to be installed.  Mailing to unauthorised programs
  will no longer work.
    Disadvantage:  If a program is not authorised by smrsh, any attempt
  to use it via mail will cause an error reply to be generated.
  System administrators should check their aliases and all 
  .forward files for any configuration that mails to a program. 
  These configurations will generate an error reply on every 
  message mailed if that program is not authorised for use by smrsh.
  If the .forward file contains something similar to:
    \user, "| /usr/ucb/vacation user"
  then mail will still be delivered to "user", but an error reply
  (not the vacation message) will be returned to the sender if
  vacation is not authorised for use by smrsh.

3.4 Ensure bounced mail is sent to postmaster or some other alias.

    Exploitation of this vulnerability generates a number of mail error
    reply messages.  sendmail(8) should be configured to send a copy of
    these messages to postmaster, by including the following line in
    the options part of the sendmail(8) configuration file:
  # Cc my postmaster on error replies I generate
  OPpostmaster
    (See note 4.1)

3.5 Increase logging in sendmail(8).

    To further detect attempted exploitation of the sendmail(8) vulnerability,
    you may wish to increase sendmail(8) logging to a minimum log level of 9.
    This is done by including the following line in the options part of the
    general configuration information section of the sendmail configuration
    file:
  # log level
  OL9
    (See note 4.1)

3.6 Increase logging in syslog.

    To further detect attempted exploitation of the sendmail(8) vulnerability,
    you may wish to increase the level of logging provided by syslog by
    enabling a minimum level of "info" for mail messages to be logged to
    the console and/or the syslog file.  This may be done for example by
    including the following lines in the syslog.conf file:
  mail.info      /dev/console
  mail.info      /var/adm/messages
    (See note 4.2)
    Sample error messages to look for include mail to or from a single
    pipe ("|"), or mail to or from an obviously invalid user (for example,
    bounce or blah).


4.  Post configuration requirements.

    The following post configuration actions may be required as a result of
    actions taken in section 3.

4.1 Rebuild the sendmail(8) frozen configuration file, restart sendmail(8).

    If any changes have been made to the sendmail(8) configuration, it may 
    be necessary to rebuild the frozen configuration file and restart
    sendmail(8).  The following command can be used to rebuild the frozen
    configuration file if it is required:
  host# /usr/lib/sendmail -bz

    sendmail(8) should then be restarted.  You should kill *all* existing
    sendmail(8) processes, by sending them a TERM signal using kill.
  host# /usr/bin/ps -auxw | /bin/grep sendmail | /bin/grep -v grep
  host# /bin/kill <pid>  #pid of every running sendmail process

    Restart sendmail(8) (for example):
  host# /usr/lib/sendmail -bd -q1h

4.2 Instruct syslog to reread syslog.conf.

    If any changes are made to the syslog.conf file, then syslog will need
    to be instructed to reread the configuration file.  This can be done by
    typing:
  host# /bin/kill -HUP `/bin/cat /etc/syslog.pid`


----------------------------------------------------------------------------
The SERT team wishes to thank the CERT Coordination Centre for their huge
coordination effort and for their advice and cooperation in this matter.
Our thanks to Chris Teakle from The University of Queensland for his long
and dedicated hours when testing this vulnerability.
----------------------------------------------------------------------------

If you believe that your system has been compromised, contact SERT or your
representative in FIRST (Forum of Incident Response and Security Teams).

Internet Email:  sert@sert.edu.au
Facsimile:  (07) 365 4477
SERT Hotline:  (07) 365 4417
    SERT personnel answer during business hours (AEST - GMT+10:00).
    (On call after hours for emergencies).

Security Emergency Response Team
c/- Prentice Centre
The University of Queensland
Qld.  4072.
Australia.