_____________________________________________________ The U.S. Department of Energy Computer Incident Advisory Capability ___ __ __ _ ___ / | / \ / \___ __|__ /___\ \___ _____________________________________________________ ADVISORY NOTICE UNIX sendmail Vulnerabilities November 4, 1993 2300 PST Number E-03 __________________________________________________________________________ PROBLEM: Vulnerabilities have been discovered in the UNIX sendmail utility. PLATFORM: All implementations of UNIX sendmail. DAMAGE: Local and remote users may execute commands and/or gain access to system files. SOLUTION: Apply workarounds or install new version of sendmail on ALL systems running sendmail. __________________________________________________________________________ Critical Information about UNIX sendmail Vulnerabilities This advisory supersedes the sendmail information contained in CIAC Advisory E-01. CIAC has learned of a set of serious vulnerabilities affecting the UNIX utility sendmail. These vulnerabilities affect a significant number of sendmail implementations, permitting unauthorized access to system commands and files by both local and remote users. In the absence of specific vendor information, CIAC recommends that all implementations of sendmail be considered vulnerable to attack. CIAC is working with the CERT Coordination Center and the vendor community to address this issue. At this time, there are no known patches available for any vendor implementation that fully address all known sendmail vulnerabilities. CIAC will publish information regarding vendor patches as they become available. Details of these vulnerabilities have been openly discussed in several electronic forums, including the Firewalls mailing list and the USENET newsgroup comp.security.unix. In addition, at least one automated tool designed to exploit these vulnerabilities has been widely distributed. Until vendor patches become available, CIAC strongly recommends that sites apply one of the three possible solutions described below to all systems running sendmail, including those systems behind firewalls and mail hubs. Restrict shell This workaround involves modifying the sendmail commands configuration file to restrict the sendmail program mailer facility using the sendmail restricted shell, smrsh, by Eric Allman (the original author of sendmail). The sendmail restricted shell screens all attempts to execute programs from sendmail, allowing only those specifically authorized by the system administrator. Attempts to invoke programs not in the allowed set will fail and log the attempt. Programs in the allowed set should be selected carefully. Mail utilities found in /etc/aliases and ~/.forward files should be considered for inclusion to prevent mail delivery failures (e.g. vacation, procmail, and slocal). Note that it is important that sites not include interpreters (e.g. /bin/sh, /bin/csh, /bin/perl, /bin/uudecode, and /bin/sed) in the set of allowed programs, as they may allow system compromise. The sendmail restricted shell may be obtained via anonymous FTP from ftp.uu.net in the directory /pub/security/smrsh. Consult the program documentation for installation instructions. Checksum Information Filename BSD sum System V sum -------- ------- ------------ README 30114 5 56478 10 smrsh.8 25757 2 42281 4 smrsh.c 46786 5 65517 9 Disable shell This approach also involves modifying the sendmail commands configuration. However, this approach completely disables the sendmail program mailer facility. Attempts to invoke programs through sendmail will fail. While this is a drastic solution, it may be quickly implemented to protect a site while a more long term approach is installed. To implement this approach, edit the sendmail.cf file, replacing the program mailer specification: Mprog, P=/bin/sh, F=slFDM, S=10, R=20, A=sh -c $u with: Mprog, P=/bin/false, F=, S=10, R=20, A= The configuration file should then be frozen, if necessary, and the sendmail process restarted. See the end of this advisory for more details. Install The most recent version of Eric Allman's public sendmail 8.6.4 domain sendmail has been updated to eliminate all known vulnerabilities. Sites may choose to replace their current implementation of sendmail with version 8.6.4 or later to secure their systems. Note that depending on the currently installed sendmail software, switching to sendmail 8.6.4 may potentially require significant effort for the system administrator to become familiar with the new program. Considerable modification of the sendmail configuration may also be required. The latest version of sendmail may be obtained via anonymous FTP from ftp.cs.berkeley.edu in the directory /ucb/sendmail. Checksum Information Filename BSD sum System V sum ------------------------- --------- ------------ sendmail.8.6.4.base.tar.Z 07718 428 64609 856 sendmail.8.6.4.cf.tar.Z 28004 179 42112 357 sendmail.8.6.4.misc.tar.Z 57299 102 8101 203 sendmail.8.6.4.xdoc.tar.Z 33954 251 50037 502 CIAC strongly recommends that sites monitor their systems for signs of sendmail attacks. System administrators should regularly examine the following: - All bounced mail, looking for unusual messages. - Mail log files (e.g. /var/log/syslog), looking for unusual occurrences of "|" characters. To provide this information, sendmail must be configured to bounce mail to the local postmaster and generate adequate logs. Receipt of bounced mail is enabled by placing the following line in sendmail.cf: OPpostmaster A logging level of 9 or higher should also be specified in the configuration file with a line similar to the following: OL9 Whenever any changes are made to the sendmail configuration file, it is necessary to kill all existing sendmail processes, refreeze the configuration file (on some systems), and restart the sendmail daemon. For example, under SunOS 4.1.2: # /usr/bin/ps -aux | /usr/bin/grep sendmail root 130 0.0 0.0 168 0 ? IW Oct 2 0:10 /usr/lib/sendmail -bd -q # /bin/kill -9 130 (Kill the current sendmail process) # /usr/lib/sendmail -bz (Refreeze the sendmail configuration file) # /usr/lib/sendmail -bd -q30m (Restart the sendmail daemon) Note that some sites do not use frozen configuration files. If the file sendmail.fc does not exist in the same directory as sendmail.cf, frozen configurations are not being used. __________________________________________________________________________ CIAC wishes to thank the CERT Coordination Center and members of the FIRST community for their contributions to this advisory. In addition, CIAC would like to acknowledge the technical contributions of Eric Allman, Matt Blaze, Andy Sherman, Gene Spafford, and Tim Seaver. __________________________________________________________________________ For additional information or assistance, please contact CIAC at (510) 422-8193 or send E-mail to ciac@llnl.gov. FAX messages to (510) 423-8002. Previous CIAC Bulletins and other information are available via anonymous FTP from irbis.llnl.gov (IP address 128.115.19.60). PLEASE NOTE: Many users outside of the DOE and ESnet computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Your agency's team will coordinate with CIAC. The Forum of Incident Response and Security Teams (FIRST) is a world-wide organization. A list of FIRST member organizations and their constituencies can be obtained by sending email to docserver@first.org with an empty subject line and a message body containing the line: send first-contacts. This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government nor the University of California, and shall not be used for advertising or product endorsement purposes.