CERT Advisory
1996-Sep-18 07:34 UTC
[linux-security] CERT Advisory CA-96.20 - Sendmail Vulnerabilities
-----BEGIN PGP SIGNED MESSAGE-----
============================================================================CERT(sm)
Advisory CA-96.20
Original issue date: September 18, 1996
Last revised: --
Topic: Sendmail Vulnerabilities
- -----------------------------------------------------------------------------
*** This advisory supersedes CA-95:05 ***
The CERT Coordination Center has received reports of two security problems in
sendmail that affect all versions up to and including 8.7.5. By exploiting
the first of these vulnerabilities, users who have local accounts can gain
access to the default user, which is often daemon. By exploiting the second
vulnerability, any local user can gain root access.
The CERT/CC team recommends installing vendor patches or upgrading to the
current version of sendmail (8.7.6). Until you can do so, we urge you to
apply the workaround provided in Sec. III.C. In all cases, be sure to take
the extra precautions listed in Sec. III.D.
For beta testers of sendmail 8.8: The vulnerabilities described in this
advisory have been fixed in the beta version.
We will update this advisory as we receive additional information. Please
check advisory files regularly for updates that relate to your site. In
addition, you can check ftp://info.cert.org/pub/latest_sw_versions/sendmail
to identify the most current version of sendmail.
- -----------------------------------------------------------------------------
I. Description
There are two vulnerabilities in all versions of sendmail up to and
including sendmail 8.7.5. The first vulnerability is a resource starvation
problem and the second is a buffer overflow problem.
Resource Starvation
-------------------
When email is forwarded to a program using a .forward file or an :include:
statement within a .forward or alias file, that program is executed as the
owner of the .forward file or the file referenced by the :include:
statement. Similarly, if email is forwarded to a file, that file is
opened as the owner of the .forward file or the file referenced by the
:include: statement. The file owner is called the "controlling
user."
If the message cannot be delivered immediately, the name of the
controlling user is written into the queue file along with the other
delivery information so that the appropriate permissions can be acquired
when the mail queue is processed.
Only the name of the controlling user is written in the queue file. This
name is derived by calling the system routine getpwuid(3) on the user id
of the file owner. If getpwuid fails, the sendmail default user (defined
by the DefaultUser option in 8.7 and by the "u" and "g"
options in older
releases) is assumed.
In some cases, the system can be forced into resource starvation, thus
forcing getpwuid(3) to fail even though an entry exists in /etc/passwd
corresponding to that uid. Since getpwuid has no way of portably
returning an error meaning "resource failure" as distinct from
"user id
not found," sendmail has no way of distinguishing between these cases;
it
assumes that the uid is unknown and falls back to the default user.
By starving sendmail of specific resources, sendmail will create files
owned by the default user. Once created, these files can be used to
access other files owned by the default user. In addition, these files
owned by the default user can be used to leverage access to other
privileged users on the system.
Buffer Overflows
----------------
There are several buffer overflows present in sendmail version 8.7.5 and
earlier. Some of the buffer overflows could result in local users gaining
unauthorized root access.
Significant work has been done on sendmail version 8.8 (now in beta
test) to eliminate the problem, and the code changes originally planned
for 8.8 have been backported to 8.7.6 to address these vulnerabilities.
II. Impact
Resource Starvation
-------------------
Anyone with access to an account on the system can run programs or write
files as the default user. The danger of compromising the default user
depends primarily on the other files in your system owned by that user.
For example, on many systems the line printer spool directory (e.g.,
/var/spool/lpd) is owned by daemon; because the line printer subsystem
runs setuid root, it may be possible to gain additional privileges.
However, some other systems have no files owned by user daemon on the
default system, and the only files owned by group daemon are not
writable by that group; hence, the danger is minimal.
Buffer Overflows
----------------
Anyone with access to an account on the system can gain root access.
III. Solution
Install a patch from your vendor if one is available (Sec. A) or upgrade
to the current version of sendmail (Sec. B). Until you can take one of
those actions, we recommend applying the workaround described in Sec. C.
This workaround addresses the resource starvation problem but not buffer
overflows.
In all cases, you should take the precautions listed in Sec. D.
Note to beta testers of sendmail 8.8: The vulnerabilities described in
this advisory have been fixed in the beta version of 8.8.
A. Install a vendor patch.
Below is a list of the 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, please contact the vendor directly.
Digital Equipment Corporation
Hewlett-Packard Company
IBM Corporation
Linux
Open Software Foundation
The Santa Cruz Operation
Silicon Graphics Inc.
Sun Microsystems, Inc.
B. Upgrade to the current version of sendmail.
Install sendmail 8.7.6. This version is a "drop in"
replacement for
8.7.x. There is no patch for 8.6.x. If you are using version 8.6 or
earlier, you need to upgrade to the current version and rebuild your
sendmail.cf files. Upgrading to version 8.7.6 addresses both
vulnerabilities described in this advisory.
Sendmail 8.7.6 is available from
ftp://ftp.sendmail.org/ucb/src/sendmail/sendmail.8.7.6.tar.gz
ftp://info.cert.org/pub/tools/sendmail/sendmail.8.7.6.tar.gz
ftp://ftp.cert.dfn.de/pub/tools/net/sendmail/sendmail.8.7.6.tar.gz
MD5 (sendmail.8.7.6.tar.gz) = 4a1f2179c53c9106bc8d7738f4d55667
Also in that directory are .Z and .sig files. The .Z file contains the
same bits as the .gz file, but 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>
We strongly recommend that when you change to a new version of sendmail
you also change to the configuration files that are provided with that
version.
Significant work has been done to make this task easier. 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.
Finally, for Sun users, a paper is available to help you convert your
sendmail configuration files from the Sun version of sendmail to one
that works with sendmail version 8.7.x. The paper is entitled
"Converting Standard Sun Config Files to Sendmail Version 8"
and was
written by Rick McCarty of Texas Instruments Inc. It is included in
the distribution and is located in contrib/converting.sun.configs.
C. Apply a workaround.
Resource Starvation
-------------------
Eric Allman, the author of sendmail, has provided the following
workaround to the resource starvation vulnerability.
Using smrsh as "prog" mailer limits the programs that can be
run as
the default user. Smrsh does not limit the files that can be written,
but less damage can be done by writing files directly.
The damage can be almost entirely constrained by ensuring that the
default user is an innocuous one. Sendmail defaults to 1:1 (daemon)
only because that is reasonably portable. A special "mailnull"
account that is used only for this purpose would be better. This user
should own no files and should have neither a real home directory nor
a real shell. A sample password entry might be:
mailnull:*:32765:32765:Sendmail Default User:/no/such/dir:/dev/null
A corresponding entry should be made in /etc/group:
mailnull:*:32765:
These assume that there are no other users or groups with id = 32765
on your system; if there are, pick some other unique value. After
creating this user, change the line in /etc/sendmail.cf reading
O DefaultUser=1:1
to read
O DefaultUser=mailnull
If you are running 8.6.*, you will have to change the lines reading
Ou1
Og1
to read
Ou32765
Og32765
Finally, if you are using the m4(1)-based sendmail configuration scheme
provided with sendmail 8.7.*, you should add the following line to the
m4 input file, usually named sendmail.mc:
define(`confDEF_USER_ID'', 32765:32765)
The actual values should, of course, match those in the passwd file.
Buffer Overflows
----------------
There is no workaround for the buffer overflow problem. To address this
problem, you must apply your vendor''s patches or upgrade to the
current
version of sendmail (version 8.7.6).
D. Take additional precautions.
Regardless of which solution you apply, you should take these extra
precautions to protect your systems.
* 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.
A number of 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 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.
* 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. 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.
Note that as of Solaris 2.5 and beyond, mail.local is included with the
standard distribution. 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 executable copies of old versions of mail programs
If you leave 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.
Digital Equipment Corporation
============================[About the resource starvation problem]
Source:
Software Security Response Team
Copyright (c) Digital Equipment Corporation 1996. All rights reserved.
08.SEP.1996
At the time of writing this document, patches (binary kits) for
Digital''s
UNIX related operating systems are being developed. Digital will provide
notice of availability for remedial kits through AES services (DIA, DSNlink
FLASH), placed in the public FTP patch service domain and also be
available from your normal Digital Support channel.
ftp://ftp.service.digital.com/public/{OS/{vn.n}
| |
| |--version
|--osf or ultrix
9/96 - DIGITAL EQUIPMENT CORPORATION
Hewlett-Packard Company
======================[About the resource starvation problem]
HP-UX is vulnerable, and a patch is in progress.
The HP SupportLine Mail Service provides notification of security patches
for HP-UX to its ''security_info'' mailing list. For
information on the
service, send mail to support@us.external.hp.com with
''help'' in the body of
the message (without quotes).
To report new security defects in HP software, send mail to
security-alert@hp.com.
IBM Corporation
=============== The following APARs are being developed and will be available
shortly.
See the appropriate release below to determine your action.
AIX 3.2
-------
Apply the following fixes to your system:
APAR - IX61303 IX61307
AIX 4.1
-------
Apply the following fixes to your system:
APAR - IX61162 IX61306
To determine if you have this APAR on your system, run the following
command:
instfix -ik IX61162 IX61306
AIX 4.2
-------
Apply the following fixes to your system:
APAR - IX61304 IX61305
To determine if you have this APAR on your system, run the following
command:
instfix -ik IX61304 IX61305
To Order
--------
APARs may be ordered using Electronic Fix Distribution (via FixDist)
or from the IBM Support Center. For more information on FixDist,
http://service.software.ibm.com/aixsupport/
or send e-mail to aixserv@austin.ibm.com with a subject of
"FixDist".
IBM and AIX are registered trademarks of International Business Machines
Corporation.
Linux
====[For the resource starvation problem:]
Debian Linux: not vulnerable (uses smail)
Red Hat and derivatives:
ftp://ftp.redhat.com/pub/redhat-3.0.3/i386/updates/RPMS/sendmail*
Open Software Foundation
======================= OSF''s OSF/1 R1.3.2 is not vulnerable to these
types of attacks described in
the resource starvation sections of the advisory.
OSF''s OSF/1 R1.3.2 is vulnerable to the buffer overflow problems.
We will address the problem in our next maintenance release.
The Santa Cruz Operation
=======================
Any SCO operating system running a version of sendmail provided by SCO
is vulnerable to this problem. SCO is providing Support Level
Supplement (SLS) oss443a for the following releases to address this issue:
SCO Internet FastStart release 1.0.0
SCO OpenServer releases 5.0.0 and 5.0.2
This SLS provides a pre-release version of sendmail release 8.7.6
for these platforms. SCO hopes to have a final version of sendmail 8.7.6
available to address both issues mentioned in this advisory in the near
future.
Note that only SCO Internet FastStart uses sendmail as the default mail
system. All other SCO operating systems use other mail systems such as the
Multi-Channel Memorandum Distribution Facility (MMDF) or the
"mailsurr"
mail system as the default, and as such are not vulnerable to this
problem unless otherwise configured to use sendmail.
SCO intends to provide a similar patch for SCO UnixWare release 2.1.0
in the near future.
When configured to use a version of sendmail provided by SCO, releases
prior to the ones mentioned here are also vulnerable, but no
plans have yet been made concerning patches for these earlier releases.
You can download SLS oss443a as shown below.
Anonymous ftp (World Wide Web URL)
-------------
ftp://ftp.sco.COM/SSE/oss443a (SLS image)
ftp://ftp.sco.COM/SSE/oss443a.ltr.sse (cover letter/install notes)
Compuserve
----------
SLS oss443a is also available in the SCO Forum on Compuserve.
SCO Online Support (SOS) BBS
----------------------------
SLS oss443a can also be downloaded interactively via X, Y, or Z MODEM or
Kermit, using the SCO Online Support System (SOS). Follow the menu
selections under "Toolchest" from the main SOS menu.
The phone numbers available for interactive transfer from SOS are:
1-408-426-9495 (USA)
+44 (0)1923 210 888 (United Kingdom)
Checksums
---------
sum -r
------
13804 630 oss443a
35304 14 oss443a.ltr.sse
MD5
---
MD5 (oss443a) = 549260a71ca76f4e98dd38bccb72748c
MD5 (oss443a.ltr.sse) = 7475d83f0db64a1af69eb66cd392a9d3
Be sure to keep track of the README file at ftp://ftp.sco.COM/SSE/README
for updates to this supplement.
If you have further questions, contact your support provider. If you
need to contact SCO, please send electronic mail to support@sco.COM, or
contact SCO as follows.
USA/Canada: 6am-5pm Pacific Daylight Time (PDT)
-----------
1-800-347-4381 (voice)
1-408-427-5443 (fax)
Pacific Rim, Asia, and Latin American customers: 6am-5pm Pacific
------------------------------------------------ Daylight Time
(PDT)
1-408-425-4726 (voice)
1-408-427-5443 (fax)
Europe, Middle East, Africa: 9am-5:30pm Greenwich Mean Time (GMT)
----------------------------
+44 (0)1923 816344 (voice)
+44 (0)1923 817781 (fax)
Silicon Graphics, Inc.
===================== We are analyzing the vulnerability, and will provide
additional
information as it becomes available.
Sun Microsystems, Inc.
===================== Sun is working on a patch which will fix both problems,
and we expect to
have it out by the end of the month. Also, we will send out a Sun bulletin
on this subject at about the same time.
- ------------------------------------------------------------------------------
The CERT Coordination Center staff thanks Eric Allman, the author of sendmail,
for his extensive assistance with this advisory, Wolfgang Ley of DFN-CERT for
his support in the development of the advisory, and D. J. Bernstein of the
University of Illinois at Chicago for reporting the resource starvation
vulnerability.
- -----------------------------------------------------------------------------
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 ftp://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.
You can get the CERT PGP key from ftp://info.cert.org/pub/CERT_PGP.key
Location of CERT PGP key
ftp://info.cert.org/pub/CERT_PGP.key
Getting security information
CERT publications and other security information are available from
http://www.cert.org/
ftp://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 1996 Carnegie Mellon University
This material may be reproduced and distributed without permission provided
it is used for noncommercial purposes and the copyright statement is
included.
CERT is a service mark of Carnegie Mellon University.
- ---------------------------------------------------------------------------
This file:
ftp://info.cert.org/pub/cert_advisories/CA-96.20.sendmail_vul
http://www.cert.org
click on "CERT Advisories"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Revision history
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMj/++HVP+x0t4w7BAQEoBQP/THORrwVlVF6WbC1zJ3V7fMLC3XSXoG7E
WPbIxciOj1xwA14gvVGXyPMtnH6AmgD7PyzQyifzwu/MrecU3UHfgdjVlpJbRjFJ
XplELdcjt39wKGz9TlurK/iE31PN/gOlcBBukyLjIuq9NHJEi9vN7M0nTp3KmW/b
H66I2ElnY7w=tQ1H
-----END PGP SIGNATURE-----
Wolfgang Ley
1996-Dec-08 04:17 UTC
Re: [linux-security] CERT Advisory CA-96.20 - Sendmail Vulnerabilities
-----BEGIN PGP SIGNED MESSAGE----- CERT Advisory wrote:> > ============================================================================> CERT(sm) Advisory CA-96.20 > Original issue date: September 18, 1996 > Last revised: -- > > Topic: Sendmail Vulnerabilities > -----------------------------------------------------------------------------[...] Ugh... Don''t know why this superseeded CERT Advisory has been distributed now via the linux-security mailing list, but it''s definitly out of date! Good signature from user "CERT Coordination Center <cert@cert.org>". Signature made 1996/09/18 13:54 GMT [...]> III. Solution[...]> B. Upgrade to the current version of sendmail. > > Install sendmail 8.7.6. This version is a "drop in" replacement for > 8.7.x. There is no patch for 8.6.x. If you are using version 8.6 or > earlier, you need to upgrade to the current version and rebuild your > sendmail.cf files. Upgrading to version 8.7.6 addresses both > vulnerabilities described in this advisory. > > Sendmail 8.7.6 is available from > > ftp://ftp.sendmail.org/ucb/src/sendmail/sendmail.8.7.6.tar.gz > ftp://info.cert.org/pub/tools/sendmail/sendmail.8.7.6.tar.gz > ftp://ftp.cert.dfn.de/pub/tools/net/sendmail/sendmail.8.7.6.tar.gz > > MD5 (sendmail.8.7.6.tar.gz) = 4a1f2179c53c9106bc8d7738f4d55667The current version of sendmail is 8.8.4. It is strongly recommended to upgrade to that version as it also fixes serious security problems that are also in the 8.7.6 version. The CERT Advisory 96:24 (dated November 22, 1996) suggests upgrading to 8.8.3. A copy of that advisory is appended. Sendmail 8.8.3 contains two other minor security problems described in the (also appended) AUSCERT Advisory 96:15. Summary: Do *not* install the 8.7.6 version but instead use the 8.8.4 version of sendmail. Bye, Wolfgang Ley (DFN-CERT) - -- Wolfgang Ley, DFN-CERT, Vogt-Koelln-Str. 30, 22527 Hamburg, Germany Email: ley@cert.dfn.de Phone: +49 40 5494-2262 Fax: +49 40 5494-2241 PGP-Key available via finger ley@ftp.cert.dfn.de any key-server or via WWW from http://www.cert.dfn.de/~ley/ ...have a nice day -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCVAwUBMqqxmQQmfXmOCknRAQEFuQQAhAj53H277wBDvFiz+ayb6ptcak+qHA5p 01oqxjGb8oEFYKoFBjP9nFMwS6zsoOxyorBTVdYZNSctYzbqJQmyJFRH3xIi26ym izcd3aPlgryk7Wdbj1qzkt+F30ni2Qa3c05kYpKh9lduEXueBkzy7iAvQEvoRiYU esEbbkGGQaw=ZBLo -----END PGP SIGNATURE----- -----BEGIN PGP SIGNED MESSAGE----- ============================================================================CERT(sm) Advisory CA-96.24 Original issue date: November 21, 1996 Last revised: November 22, 1996 Topic: Sendmail Daemon Mode Vulnerability - ----------------------------------------------------------------------------- The CERT Coordination Center has received reports of a serious security problem in sendmail that affects versions 8.7 through 8.8.2. By exploiting this vulnerability, any local user can gain root access. Exploitation details involving this vulnerability have been widely distributed. Independent of this new vulnerability, there are other security problems with older sendmail versions. Even if you are not running a version between 8.7 and 8.8.2, we strongly encourage you to upgrade to the current version of sendmail (8.8.3). See Section IV for details. The CERT/CC team recommends installing vendor patches or upgrading to the current version of sendmail (8.8.3). Until you can do so, we urge you to apply the workaround provided in Section III.C. In all cases, be sure to take the extra precautions listed in Section III.D. We will update this advisory as we receive additional information. Please check advisory files regularly for updates that relate to your site. In addition, you can check ftp://info.cert.org/pub/latest_sw_versions/sendmail to identify the most current version of sendmail. - ----------------------------------------------------------------------------- I. Description Sendmail is often run in daemon mode so that it can "listen" for incoming mail connections on the standard SMTP networking port, usually port 25. The root user is the only user allowed to start sendmail this way, and sendmail contains code intended to enforce this restriction. Unfortunately, due to a coding error, sendmail can be invoked in daemon mode in a way that bypasses the built-in check. When the check is bypassed, any local user is able to start sendmail in daemon mode. In addition, as of version 8.7, sendmail will restart itself when it receives a SIGHUP signal. It does this restarting operation by re-executing itself using the exec(2) system call. Re-executing is done as the root user. By manipulating the sendmail environment, the user can then have sendmail execute an arbitrary program with root privileges. II. Impact Local users can gain root privileges on the local machine. 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, please contact the vendor directly. Berkeley Software Design, Inc. (BSDI) Data General Corporation Digital Equipment Corporation FreeBSD Hewlett-Packard Company IBM Corporation Linux NeXT Software, Inc. Open Software Foundation (OSF) The Santa Cruz Operation, Inc. (SCO) Silicon Graphics, Inc. Sun Microsystems, Inc. B. Upgrade to the current version of sendmail. Install sendmail 8.8.3. This version is a "drop in" replacement for 8.8.x. There is no patch for any version of sendmail before 8.8.0. If you are running such a version, strongly consider moving to version 8.8.3. Sendmail 8.8.3 is available from ftp://ftp.sendmail.org/ucb/src/sendmail/sendmail.8.8.3.tar.gz ftp://info.cert.org/pub/tools/sendmail/sendmail.8.8.3.tar.gz ftp://ftp.cert.dfn.de/pub/tools/net/sendmail/sendmail.8.8.3.tar.gz ftp://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu/ucb/sendmail/* MD5 (sendmail.8.8.3.tar.gz) = 0cb58caae93a19ac69ddd40660e01646 Also in that directory are .Z and .sig files. The .Z file contains the same bits as the .gz file, but 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. Significant work has been done to make this task easier. (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. Sun sendmail users: A paper is available to help you convert your sendmail configuration files from the Sun version of sendmail to one that works with sendmail version 8.8.x. The paper is entitled "Converting Standard Sun Config Files to Sendmail Version 8" and was written by Rick McCarty of Texas Instruments Inc. It is included in the distribution and is located in contrib/converting.sun.configs. C. Apply a workaround. Eric Allman, the author of sendmail, has provided the following workaround. This vulnerability relies on a coding error that has existed in sendmail since November 1982, allowing non-root users to start up an SMTP daemon by invoking sendmail as smtpd. However, that error did not have the current negative implications until sendmail added the ability to re-execute when a SIGHUP signal was received; this was added in 8.7. The anti-smtpd program given in Appendix B refuses to permit sendmail to be invoked as smtpd by a non-root user. It should be installed setuid root in place of sendmail (e.g., as /usr/sbin/sendmail or /usr/lib/sendmail, depending on your system); the real sendmail should be moved to another place. That location should be set in the REAL_SENDMAIL definition, and it should not be accessible by ordinary users. This permits the anti-smtpd program to moderate access to sendmail. 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. A number of 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 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. * 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. 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. IV. Additional Notes Two other sendmail vulnerabilities are described in CERT advisory CA-96.20; see that advisory for details. Since the release of CA-96.20, two additional sendmail vulnerabilities have been discovered and fixed. By upgrading to sendmail version 8.8.3, the two problems, noted below, are also fixed. Note that the wrapper described in Section III.C does not address these vulnerabilities. The best advice is to upgrade to sendmail version 8.8.3. A. A vulnerability in sendmail Versions 8.8.0 and 8.8.1 has been discovered that allows remote users to execute arbitrary commands with root privileges. This vulnerability exploits exploiting a problem related to a buffer overflow when converting between 7-bit and 8-bit MIME messages. Versions prior to Version 8.8.0 do not contain this vulnerability. Versions before 8.7.6 contain other unrelated vulnerabilities. This vulnerability is fixed in version 8.8.2 and beyond. The Australian Emergency Response Team (AUSCERT) issued an advisory on this vulnerability, AA-96.06a, available from http://www.auscert.org.au/ ftp://ftp.auscert.org.au/pub/ B. A problem in sendmail has been reported that permits users on a system to redirect any email in the queue addressed to an unqualified domain name to a host of their choosing; that is, they can steal queued email. In some versions of the resolver, they may also be able to steal queued email addressed to fully qualified addresses. This bug is believed to exist in all versions of sendmail up to and including 8.8.0. It is fixed in version 8.8.1 and beyond. ........................................................................... 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) ===================================BSD/OS is vulnerable to the sendmail daemon problem and we have issued an official patch (U210-029) which may be obtained from our mail-back patches server at patches@BSDI.COM or via anonymous ftp from: ftp://ftp.bsdi.com/bsdi/patches/patches-2.1/U210-029 Data General Corporation =======================The sendmail included with Data General''s DG/UX is not subject to this vulnerability. Digital Equipment Corporation ============================DIGITAL Engineering is aware of these reported problems and testing is currently underway to determine the impact against all currently supported releases of DIGITAL UNIX and ULTRIX. Patches will be developed (as necessary) and made available via your normal DIGITAL Support channel. Notice will be through normal AES services and DIGITAL''S Web site http://www.service.digital.com/html/whats-new.html FreeBSD ======All currently shipping releases of FreeBSD are affected, including the just released 2.1.6. An update for 2.1.6 will be available shortly. This problem has been corrected in the -current sources. In the mean time, FreeBSD users should follow the instructions in the CERT advisory. Sendmail will compile and operate "out of the box" on FreeBSD systems. Hewlett-Packard Company ======================Sendmail daemon problem: Not Vulnerable HP-UX 9.X, 10.00, 10.01, 10.10 Vulnerable HP-UX 10.2 even with PHNE_8702 Patches in process IBM Corporation ==============See the appropriate release below to determine your action. AIX 3.2 ------- No fix required. AIX 3.2 sendmail is not vulnerable. AIX 4.1 ------- No fix required. AIX 4.1 sendmail is not vulnerable. AIX 4.2 ------- AIX 4.2 sendmail is vulnerable. APAR IX63068 will be available shortly. To determine if you have this APAR on your system, run the following command: instfix -ik IX63068 To Order -------- APARs may be ordered using Electronic Fix Distribution (via FixDist) or from the IBM Support Center. For more information on FixDist, reference URL: http://service.software.ibm.com/aixsupport/ or send e-mail to aixserv@austin.ibm.com with a subject of "FixDist". IBM and AIX are registered trademarks of International Business Machines Corporation. Linux ==== Linux has provided these URLs for S.u.S.E. Linux: ftp://ftp.suse.de/suse_update/S.u.S.E.-4.3/sendmail ftp://ftp.gwdg.de/pub/linux/suse/suse_update/S.u.S.E.-4.3/sendmail Checksums for the files in these directories: 6279df0597c972bff65623da5898d5dc sendmail.tgz 0c0d20eecb1019ab4e629b103cac485c sendmail-8.8.3.dif 0cb58caae93a19ac69ddd40660e01646 sendmail-8.8.3.tar.gz - ----- Caldera OpenLinux has released a security advisory, available from http://www.caldera.com/tech-ref/cnd-1.0/security/SA-96.06.html - ----- Red Hat has patched sendmail 8.7.6. The fixes are available from Red Hat Linux/Intel: rpm -Uvh ftp://ftp.redhat.com/updates/4.0/i386/sendmail-8.7.6-5.i386.rpm Red Hat Linux/Alpha: rpm -Uvh ftp://ftp.redhat.com/updates/4.0/axp/sendmail-8.7.6-5.axp.rpm NeXT Software, Inc. ==================NeXT is not vulnerable to the problem described in Section IV.A. NeXT is vulnerable to the problem described in Section IV.B, and it will be fixed in release 4.2 of OpenStep/Mach. Open Software Foundation (OSF) =============================OSF/1 R1.3 is not vulnerable to this problem. The Santa Cruz Operation, Inc. (SCO) ===================================SCO is investigating the problem and will have more information in the near future. If we find that patches are needed, please check the following URLs and this advisory appendix. ftp://ftp.sco.com/SLS/README ftp://ftp.sco.com/SSE/README Silicon Graphics, Inc. ====================Silicon Graphics has historically provided a version 8.6.x sendmail program. The most recent SGI sendmail patch (1502) provides a version 8.6.12 sendmail program also. 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 not vulnerable to the exploitation as described in the CERT Advisory CA-96:24. No further action is required. Silicon Graphics also published an advisory for their customers on November 21, 1996--SGI advisory number 19961103-01-I. SGI advisories are available from http://www.sgi.com/Support/Secur/advisories.html ftp://sgigate.sgi.com/security/ Sun Microsystems, Inc. =====================No Sun versions of sendmail are affected by this vulnerability. ........................................................................... Appendix B - anti-smtpd.c Below is the code for the anti-smtpd.c sendmail wrapper. Here is an example of how to compile and install this wrapper. You may have to change these commands for your system. Further, you may have to change the code for anti-smtpd.c to get it to compile on your system. Finally, you may also have to turn off sendmail before running these commands and then turn sendmail back on after running them. Run these commands as root. # mkdir /usr/hidden # chmod 700 /usr/hidden # mv /usr/lib/sendmail /usr/hidden/sendmail # cc anti-smtpd.c -o anti-smtpd # mv anti-smtpd /usr/lib/sendmail # chmod u+s /usr/lib/sendmail Here is the code for anti-smtpd.c: #include <stdio.h> #include <string.h> #include <syslog.h> #include <sysexits.h> static char *Version = "Version 1.0 November 21, 1996"; /* ** Sendmail wrapper for CA-96:24 HUP to smtpd problem ** ** This is trivial -- it just ensures that sendmail cannot be ** invoked as smtpd. ** ** To install this, move the real sendmail into /usr/hidden, ** which should be a mode 700 directory owned by root. Install ** this program setuid root in place of sendmail. */ #ifndef REAL_SENDMAIL # define REAL_SENDMAIL "/usr/hidden/sendmail" #endif main(argc, argv) int argc; char **argv; { char *p; extern int errno; if (argc < 1) { fprintf(stderr, "sendmail: need a program name\n"); exit(EX_USAGE); } p = strrchr(argv[0], ''/''); if (p == NULL) p = argv[0]; else p++; if (strcmp(p, "smtpd") == 0 && getuid() != 0) { fprintf(stderr, "sendmail: cannot be invoked as smtpd\n"); syslog(LOG_ALERT, "sendmail: invoked as smtpd by %d", getuid()); exit(EX_USAGE); } execv(REAL_SENDMAIL, argv); fprintf(stderr, "sendmail: cannot exec %s: errno = %d\n", REAL_SENDMAIL, errno); exit(EX_OSFILE); } - ----------------------------------------------------------------------------- The CERT Coordination Center thanks Eric Allman and AUSCERT for their contributions to the development of this advisory. - ----------------------------------------------------------------------------- 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 ftp://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 ftp://info.cert.org/pub/CERT_PGP.key Getting security information CERT publications and other security information are available from http://www.cert.org/ ftp://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 1996 Carnegie Mellon University This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and the copyright statement is included. CERT is a service mark of Carnegie Mellon University. - --------------------------------------------------------------------------- This file: ftp://info.cert.org/pub/cert_advisories/CA-96.24.sendmail.daemon.mode http://www.cert.org click on "CERT Advisories" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Revision history Nov. 22, 1996 Updates - added vendor information for Silicon Graphics. Modified Hewlett Packard''s patch information. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMpYPlnVP+x0t4w7BAQFGKAP+MIpp+ID0L1QodewKQVa6VWO8xGUbluaS w0TaYOwNVx/PJnDhl6HlONJhh81D++hrP1YcXI9iTpVSMhr7tauC7VmKJalbSLAo W2+PhOVjaZKKOygDmdQh2ufaF6sAADtffPiwIf5w4dey1/901xiR4U5uztfgDtgD MtHINoWvYx8=dgHc -----END PGP SIGNATURE----- -----BEGIN PGP SIGNED MESSAGE----- ==========================================================================AA-96.15 AUSCERT Advisory sendmail Group Permissions Vulnerability 3 December 1996 Last Revised: -- - --------------------------------------------------------------------------- AUSCERT has received information of a security problem in sendmail affecting version 8. This vulnerability may allow local users to run programs with group permissions of other users. This vulnerability requires group writable files to be available on the same file system as a file that the attacker can convince sendmail to trust. AUSCERT recommends that sites take the steps outlined in Section 3 as soon as possible. - --------------------------------------------------------------------------- 1. Description When delivering mail to a program listed in a .forward or :include: file, that program is run with the group permissions possessed by the owner of that .forward or :include: file. The owner of the file is used to initialize the list of group permissions that are in force when the program is run. This list is determined by scanning the /etc/group file. It is possible to attain group permissions you should not have by linking to a file that is owned by someone else, but on which you have group write permissions. By changing that file you can acquire the group permissions of the owner of that file. 2. Impact An attacker can gain group permissions of another user, if the attacked user has a file that is group writable by the attacker on the same filesystem as either (a) the attacker''s home directory, or (b) a :include: file that is referenced directly from the aliases file and is in a directory writable by the attacker. The first (.forward) attack only works against root. N.B.: this attack does not give you root "owner" permissions, but does give you access to the groups that list root in /etc/group. 3. Workarounds/Solution AUSCERT recommends that sendmail 8.8.4 be installed as soon as possible (see Section 3.1). For sites that can not install sendmail 8.8.4, apply the workaround described in Section 3.2. 3.1 Upgrade to sendmail 8.8.4. Eric Allman has released sendmail 8.8.4 which fixes this vulnerability. There is no patch for any version of sendmail prior to 8.8.0. Sites are encouraged to upgrade to sendmail 8.8.4 as soon as possible. The current version of sendmail is available from: ftp://ftp.sendmail.org/pub/sendmail/ ftp://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu/ucb/sendmail/ ftp://ftp.cert.dfn.de/pub/tools/net/sendmail/ The MD5 checksum for this distribution is: MD5 (sendmail.8.8.4.patch) = bb0f24abdb1416748b0c7a9f9315fa59 MD5 (sendmail.8.8.4.tar.Z) = 0b4e4d09c75733ab63dde1cb6a52c615 MD5 (sendmail.8.8.4.tar.gz) = 64ce6393a6968a0dc7c6652dace127b0 3.2 Workaround Eric Allman, the author of sendmail, has provided the following workaround. Set the UnsafeGroupWrites option in the sendmail.cf file. This option tells sendmail that group-writable files should not be considered safe for mailing to programs or files. This causes sendmail to refuse to run any programs referenced from group-writable files. Setting this option is a good idea in any case, but may require that your users tighten permissions on their .forward files and :include: files. The command "find <filesystem> -user root -type f -perm -020 -print" will print the names of all files owned by root that are group writable on a given <filesystem>. In addition, group memberships should be audited regularly. Users should not be in groups without a specific need. In particular, root generally does not need to be listed in most groups. As a policy matter, root should have a umask of (at least) 022 so that group writable files are made consciously. Also, the aliases file should not reference :include: files in writable directories. 4. Additional Measures This section describes some additional measures for increasing the security of sendmail. These measures are unrelated to the vulnerability described in this advisory but should be followed. Sites must apply the Workarounds/Solution described in Section 3 first, and then optionally apply the additional measures described in this Section. 4.1 Restrict Ability to Mail to Programs If the ability to send electronic mail to programs (for example, vacation programs) is not required, this feature should be disabled. This is achieved by modifying the "Mprog" line in the configuration file to mail to "/bin/false" rather than "/bin/sh". The following line in the ".mc" file will achieve this: define(`LOCAL_SHELL_PATH'', `/bin/false'')dnl If mailing to programs is required, it is recommended that the sendmail restricted shell, smrsh, be used at all times. This applies to all versions of sendmail, including vendor versions. smrsh is supplied with the current version of sendmail and includes documentation and installation instructions. 5. Additional Information Sendmail 8.8.4 also fixes a denial of service attack. If your system relies on the TryNullMXList option in order to forward mail to third party MX hosts, an attacker can force that option off, thereby causing mail to bounce. As a workaround, you can use the mailertable feature to deliver to third party MX hosts regardless of the setting of the TryNullMXList option. - --------------------------------------------------------------------------- AUSCERT thanks Eric Allman for his rapid response to this vulnerability, and for providing much of the technical content used in this advisory. AUSCERT also thanks Terry Kyriacopoulos (Interlog Internet Services) and Dan Bernstein (University of Illinois at Chicago) for their reporting of these vulnerabilities. - --------------------------------------------------------------------------- The AUSCERT team have made every effort to ensure that the information contained in this document is accurate. However, the decision to use the information described is the responsibility of each user or organisation. The appropriateness of this document for an organisation or individual system should be considered before application in conjunction with local policies and procedures. AUSCERT takes no responsibility for the consequences of applying the contents of this document. If you believe that your system has been compromised, contact AUSCERT or your representative in FIRST (Forum of Incident Response and Security Teams). AUSCERT is located at The University of Queensland within the Prentice Centre. AUSCERT is a full member of the Forum of Incident Response and Security Teams (FIRST). AUSCERT maintains an anonymous FTP service which is found on: ftp://ftp.auscert.org.au/pub/. This archive contains past SERT and AUSCERT Advisories, and other computer security information. AUSCERT also maintains a World Wide Web service which is found on: http://www.auscert.org.au/. Internet Email: auscert@auscert.org.au Facsimile: (07) 3365 4477 Telephone: (07) 3365 4417 (International: +61 7 3365 4417) AUSCERT personnel answer during Queensland business hours which are GMT+10:00 (AEST). On call after hours for emergencies. Postal: Australian Computer Emergency Response Team c/- Prentice Centre The University of Queensland Brisbane Qld. 4072. AUSTRALIA ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Revision History ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: ftp://ftp.auscert.org.au/pub/auscert/AUSCERT_PGP.key iQCVAwUBMqQecyh9+71yA2DNAQFvkAP6Ax9BOb7moKyEoLi/1N9H44pU0J/EgMQG gn5sf6oO6BbR/Lrz+JjCUpyHVojoyYa9togccx9HgGqhDvrH/CwURg2cx2val7WX N4R4bKJl/qab0LJxfcHvZqbUyVGYdnYrgBz+y5xwSj6vOWcQ3/8bfPvn0abpSQgn r5aB7lz2Klc=LgWC -----END PGP SIGNATURE-----