Last revised: April, 8 2003
Updated copyright statement
A complete revision history is at the end of this file.
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 privileges.
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 inSection 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:
- The version of sendmail is 8.8.3 or 8.8.4.
- 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").
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.
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:
ftp://ftp.sendmail.org/pub/sendmail/
ftp://ftp.cs.berkeley.edu/ucb/src/sendmail/
ftp://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu/ucb/sendmail/
ftp://ftp.cert.dfn.de/pub/tools/net/sendmail/
ftp://ftp.cert.org/pub/tools/sendmail/
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 eric@CS.Berkeley.EDU Key fingerprint = C0 28 E6 7B 13 5B 29 02 6F 7E 43 3A 48 4F 45 29 Eric P. Allman eric@Reference.COM Eric P. Allman eric@Usenix.ORG Eric P. Allman eric@Sendmail.ORG Eric P. Allman eric@CS.Berkeley.EDU
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/ml.local, F=lsDFMAw5:/|@qSnE, S=10/30, R=20/40, T=DNS/RFC822/X-Unix, A=mail -d $u |
Mprog, |
P=/usr/local/bin/smrsh, F=lsDFMoqeu, S=10/30, R=20/40, D=$z:/, T= X-UNix, |
! |
A=smrsh -c $u |
This can be achieved for the "Mlocal" and "Mprog" Mailers by modifying the ".mc" file to include the following lines:
OSTYPE(solaris2) FEATURE(smrsh, /usr/local/bin/smrsh) + define(`LOCAL_SHELL_ARGS', `smrsh -c $u') define(`LOCAL_MAILER_PATH', /usr/lib/mail.local) define(`LOCAL_MAILER_FLAGS', ifdef(`LOCAL_MAILER_FLAGS', `translit(LOCAL_MAILER_FLAGS, `9')', `rmn')) define(`LOCAL_SHELL_FLAGS', ifdef(`LOCAL_SHELL_FLAGS', `translit(LOCAL_SHELL_FLAGS, `9')', `eu'))
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 either the LOCAL_MAILER_FLAGS or LOCAL_SHELL_FLAGS.
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:
http://www.cert.org/advisories/CA-95.02.binmail.vulnerabilities.
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 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)
Fully patched BSD/OS 2.1 systems are vulnerable to this problem. An official patch is available from the patches server at patches@BSDI.COM or via anonymous ftp from:
ftp://ftp.bsdi.com/bsdi/patches/patches-2.1/U210-036
Caldera OpenLinux
An upgrade for Caldera OpenLinux Base 1.0 can be found at:ftp://ftp.caldera.com/pub/col-1.0/updates/Helsinki/003/RPMS/sendmail-8.8.5-1.i386.rpm
See also the README at:
ftp://ftp.caldera.com/pub/col-1.0/updates/Helsinki/003/README
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.SOURCE:
Digital Equipment Corporation
Software Security Response Team
Copyright (c) Digital Equipment Corporation 1997. All rights reserved. 27/1/97 - DIGITAL EQUIPMENT CORPORATION
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 Corporation.
NEC Corporation
Systems below are not shipped with a sendmail based ona version 8.8.3 or later, so this problem is not present
for them.
UX/4800 EWS-UX/V(Rel4.2MP) EWS-UX/V(Rel4.2) UP-UX/V(Rel4.2MP) EWS-UX/V(Rel4.0) UP-UX/V |
Not vulnerable for all versions. Not vulnerable for all versions. Not vulnerable for all versions. Not vulnerable for all versions. Not vulnerable for all versions. 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.
Copyright 1997 Carnegie Mellon University.
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) Apr. 08, 2003 Minor formatting changes, no change to contents