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