|
Home : Advisories : MIME Conversion Buffer Overflow in Sendmail Versions 8.8.3 and 8.8.4
Title: |
MIME Conversion Buffer Overflow in Sendmail Versions 8.8.3 and 8.8.4 |
Released by: |
CERT |
Date: |
28th January 1997 |
Printable version: |
Click here |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
CERT(sm) Advisory CA-97.05
Original issue date: January 28, 1997
Last Revised: September 26, 1997
Updated copyright statement
A complete revision history is at the end of this file.
Topic: MIME Conversion Buffer Overflow in Sendmail Versions 8.8.3 and 8.8.4
- -----------------------------------------------------------------------------
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 in Section
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:
1. The version of sendmail is 8.8.3 or 8.8.4. 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.
2. 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").
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:
http://ftp.sendmail.org/pub/sendmail/
http://ftp.cs.berkeley.edu/ucb/src/sendmail/
http://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu/ucb/sendmail/
http://ftp.cert.dfn.de/pub/tools/net/sendmail/
http://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
Key fingerprint = C0 28 E6 7B 13 5B 29 02 6F 7E 43 3A 48 4F 45 29
Eric P. Allman
Eric P. Allman
Eric P. Allman
Eric P. Allman
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/mail.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://info.cert.org/pub/cert_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
or via anonymous ftp from:
http://ftp.bsdi.com/bsdi/patches/patches-2.1/U210-036
Caldera OpenLinux
=================
An upgrade for Caldera OpenLinux Base 1.0 can be found at:
http://ftp.caldera.com/pub/col-1.0/updates/Helsinki/003/RPMS/sendmail-8.8.5-1.i386.rpm
See also the README at:
http://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 on
a version 8.8.3 or later, so this problem is not present
for them.
UX/4800 Not vulnerable for all versions.
EWS-UX/V(Rel4.2MP) Not vulnerable for all versions.
EWS-UX/V(Rel4.2) Not vulnerable for all versions.
UP-UX/V(Rel4.2MP) Not vulnerable for all versions.
EWS-UX/V(Rel4.0) Not vulnerable for all versions.
UP-UX/V 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.
- -----------------------------------------------------------------------------
If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in the Forum of Incident Response
and Security Teams (see http://info.cert.org/pub/FIRST/first-contacts).
CERT/CC Contact Information
- ----------------------------
Email cert@cert.org
Phone +1 412-268-7090 (24-hour hotline)
CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4)
and are on call for emergencies during other hours.
Fax +1 412-268-6989
Postal address
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213-3890
USA
Using encryption
We strongly urge you to encrypt sensitive information sent by email. We can
support a shared DES key or PGP. Contact the CERT/CC for more information.
Location of CERT PGP key
http://info.cert.org/pub/CERT_PGP.key
Getting security information
CERT publications and other security information are available from
http://www.cert.org/
http://info.cert.org/pub/
CERT advisories and bulletins are also posted on the USENET newsgroup
comp.security.announce
To be added to our mailing list for advisories and bulletins, send your
email address to
cert-advisory-request@cert.org
- ------------------------------------------------------------------------------
Copyright 1997 Carnegie Mellon University. Conditions for use, disclaimers,
and sponsorship information can be found in
http://www.cert.org/legal_stuff.html and http://ftp.cert.org/pub/legal_stuff .
If you do not have FTP or web access, send mail to cert@cert.org with
"copyright" in the subject line.
CERT is registered in the U.S. Patent and Trademark Office.
- ---------------------------------------------------------------------------
This file: http://info.cert.org/pub/cert_advisories/CA-97.05.sendmail
http://www.cert.org
click on "CERT Advisories"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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)
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQA/AwUBOBS/FVr9kb5qlZHQEQKm9ACfVwCPm655f1xNG4w1L/Lbx/ftW6gAoIHr
HlPw49kaUPJ0WwBeCqrn6oOz
=Nrjl
-----END PGP SIGNATURE-----
|