Original issue date: January 28, 1997<BR>
Last revised: April, 8 2003<BR>
Updated copyright statement
<P>A complete revision history is at the end of this file.
<P>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.
<P>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).</P>
<P>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.
</P>
<P>We will update this advisory as we receive additional
information. Please check advisory files regularly for updates that
relate to your site. </P>
<P><HR>
<H2>I. Description</H2>
<P>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: </P>
<P>"... 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." </P>
<P>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. </P>
<P>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.</P>
<P>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.
<P>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. </P>
<P>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. </P>
<H4>Determining if you are vulnerable</H4>
<P>Systems are vulnerable to this attack if both of the following
conditions are true:
<OL>
<strong><LI>The version of sendmail is 8.8.3 or 8.8.4.</li></strong>
<P>To determine the version of sendmail, use the following command: </P>
<P>% /usr/lib/sendmail -d0 -bt < /dev/null | grep -i Version</P>
<P>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. </P>
<strong><LI>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").</li></STRONG>
<P>Use of the `9' flag can usually be determined using the following command
(depending on your sendmail configuration): </P>
<P>% grep '^M.*F=[^,]*9' /etc/sendmail.cf </P>
<P>If any lines are output from this command, then the sendmail configuration
may be vulnerable.</P>
<P>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. <BR>
</P>
</OL>
<H2>II. Impact</H2>
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.
<H2>III. Solution</H2>
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.
<H3>A. Install a vendor patch.</H3>
<P>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.
<P>Berkeley Software Design, Inc. (BSDI)<BR>
Caldera OpenLinux<BR>
Cray Research - A Silicon Graphics Company<BR>
Data General Corporation<BR>
Digital Equipment Corporation<BR>
Hewlett-Packard Corporation<BR>
IBM Corporation<BR>
NEC Corporation<BR>
NeXT Software, Inc.<BR>
Silicon Graphics, Inc.<BR>
Sun Microsystems, Inc. <BR>
<H3>B. Upgrade to sendmail version 8.8.5.</H3>
<P>Eric Allman has released a new version of sendmail which fixes this
vulnerability. This can be obtained from the following locations:
</P>
<P><A HREF="ftp://ftp.sendmail.org/pub/sendmail/">ftp://ftp.sendmail.org/pub/sendmail/</A><BR>
<A HREF="ftp://ftp.cs.berkeley.edu/ucb/src/sendmail/">ftp://ftp.cs.berkeley.edu/ucb/src/sendmail/</A><BR>
<A HREF="ftp://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu/ucb/sendmail/">ftp://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu/ucb/sendmail/</A><BR>
<A HREF="ftp://ftp.cert.dfn.de/pub/tools/net/sendmail/">ftp://ftp.cert.dfn.de/pub/tools/net/sendmail/</A><BR>
<A HREF="ftp://ftp.cert.org/pub/tools/sendmail/">ftp://ftp.cert.org/pub/tools/sendmail/</A>
</P>
<P>The MD5 checksum for this distribution is: </P>
<P>MD5 (sendmail.8.8.5.patch) = 775c47d16d40ebd2b917dfcc65d92e90 </P>
<P>MD5(sendmail.8.8.5.tar.gz) = 7c32c42a91325dd00b8518e90c26cffa </P>
<P>MD5 (sendmail.8.8.5.tar.sig) = b62ba16c7e863853b3efeb955eec4214 </P>
<P>MD5 (sendmail.8.8.5.tar.Z) = 7b847383899c0eb65987213a5caf89c8 </P>
<P>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</P>
<PRE>
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
</PRE>
<P>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.
<H3>C. Workaround for existing sendmail version 8.8.3 and 8.8.4 installations</H3>
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.
<P>The /etc/sendmail.cf file should be modified to remove the use of the
`9' flag for all Mailer specifications (lines starting with `M'). </P>
<P>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: </P>
<TABLE CELLSPACING=0 CELLPADDING=0 >
<TR>
<TD Width=25%><pre><small>Mlocal,</TD>
<TD Width= 75%><pre><small>P=/usr/lib/ml.local, F=lsDFMAw5:/|@qSnE, S=10/30, R=20/40,
T=DNS/RFC822/X-Unix,
A=mail -d $u</TD>
</TR>
<TR>
<TD Width=25%><pre><small>Mprog,</TD>
<TD Width=75%><pre><small>P=/usr/local/bin/smrsh, F=lsDFMoqeu, S=10/30, R=20/40,
D=$z:/,
T= X-UNix,</TD>
</TR>
<TR>
<TD><pre><small>!</TD>
<TD><pre><small>A=smrsh -c $u</TD>
</TR>
</TABLE>
<P>This can be achieved for the "Mlocal" and "Mprog" Mailers
by modifying the ".mc" file to include the following lines:</P>
<PRE><font face="courrier">
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'))
</font></PRE>
<P>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. </P>
<P>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. </P>
<P>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. </P>
<P>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): </P>
<P># kill -1 `head -1 /var/run/sendmail.pid` </P>
<P>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. </P>
<H3>D. Take additional precautions</H3>
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.
<UL>
<LI>Use the sendmail restricted shell program (smrsh) </LI>
<P>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. </P>
<P>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. </P>
<P>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. </P>
<P>smrsh is also distributed with some operating systems. </P>
<P>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: </P>
<P>FEATURE(smrsh, /usr/local/bin/smrsh) </P>
</UL>
<UL>
<LI>Use mail.local </LI>
<P>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. <BR> 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: </P>
<P><A HREF="http://www.cert.org/advisories/CA-95.02.binmail.vulnerabilities.html">http://www.cert.org/advisories/CA-95.02.binmail.vulnerabilities</A>.
</P>
<P>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: </P>
<P>define(`LOCAL_MAILER_PATH', /usr/lib/mail.local) </P></UL>
<UL>
<LI>WARNING: Check for setuid executable copies of old versions of mail
programs </LI>
<P>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. </P>
<P>Similarly, if you replace /bin/mail with mail.local, remember to
remove old copies of /bin/mail or make them non-executable. </P>
</UL>
<HR>
<H2>Appendix A - Vendor Information</H2>
<P>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.
<H3>Berkeley Software Design, Inc. (BSDI)</H3>
<P>Fully patched BSD/OS 2.1 systems are vulnerable to this problem. An
official patch is available from the patches server at
<A HREF="mailto:patches@BSDI.COM">patches@BSDI.COM</A> or via anonymous
ftp from:</P>
<P><A HREF="ftp://ftp.bsdi.com/bsdi/patches/patches-2.1/U210-036">ftp://ftp.bsdi.com/bsdi/patches/patches-2.1/U210-036</A>
</P>
<H3>Caldera OpenLinux</H3>
An upgrade for Caldera OpenLinux Base 1.0 can be found at:
<P><A HREF="ftp://ftp.caldera.com/pub/col-1.0/updates/Helsinki/003/RPMS/sendmail-8.8.5-1.i386.rpm">ftp://ftp.caldera.com/pub/col-1.0/updates/Helsinki/003/RPMS/sendmail-8.8.5-1.i386.rpm</A>
</P>
<P>See also the README at: </P>
<P><A HREF="ftp://ftp.caldera.com/pub/col-1.0/updates/Helsinki/003/README">ftp://ftp.caldera.com/pub/col-1.0/updates/Helsinki/003/README</A>
</P>
<H3>Cray Research - A Silicon Graphics Company</H3>
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.
<H3>Data General Corporation</H3>
The sendmail that ships with DG/UX is not subject to this vulnerability.
<H3>Digital Equipment Corporation</H3>
This reported problem is not present for Digital's ULTRIX or Digital UNIX
Operating Systems Software. <BR>
SOURCE:<BR>
Digital Equipment Corporation<BR>
Software Security Response Team<BR>
Copyright (c) Digital Equipment Corporation 1997. All rights reserved.
27/1/97 - DIGITAL EQUIPMENT CORPORATION
<H3>Hewlett-Packard Corporation</H3>
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. </P>
<H3>IBM Corporation</H3>
The version of sendmail shipped with AIX is not vulnerable to the 7 to
8 bit MIME conversion vulnerability detailed in this advisory. <BR>
IBM and AIX are registered trademarks of International Business Machines
Corporation.
<H3>NEC Corporation</H3>
Systems below are not shipped with a sendmail based on<BR>
a version 8.8.3 or later, so this problem is not present<BR>
for them.
<TABLE CELLSPACING=0 CELLPADDING=0 >
<TR>
<TD><small>UX/4800<BR>
EWS-UX/V(Rel4.2MP)<BR>
EWS-UX/V(Rel4.2)<BR>
UP-UX/V(Rel4.2MP)<BR>
EWS-UX/V(Rel4.0)<BR>
UP-UX/V <BR>
</TD>
<TD><small>Not vulnerable for all versions.<BR>
Not vulnerable for all versions.<BR>
Not vulnerable for all versions.<BR>
Not vulnerable for all versions.<BR>
Not vulnerable for all versions.<BR>
Not vulnerable for all versions.<BR>
</TD>
</TR>
</TABLE>
<H3>NeXT Software, Inc.</H3>
NeXT is not vulnerable to the MIME-buffer overflow attack.
<H3>Silicon Graphics, Inc.</H3>
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.
<H3>Sun Microsystems, Inc.</H3>
Sun is confident that no Sun sendmail is vulnerable to the MIME-buffer
overflow attack.
<P><HR>
<P>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.
</P>
<!--#include virtual="/include/footer_nocopyright.html" -->
<P>Copyright 1997 Carnegie Mellon University.</P>
<HR>
Revision History
<PRE>
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
</PRE>
|