[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [linux-security] CERT Advisory CA-96.20 - Sendmail Vulnerabilities
- From: Wolfgang Ley <ley cert dfn de>
- To: linux-security redhat com
- Subject: Re: [linux-security] CERT Advisory CA-96.20 - Sendmail Vulnerabilities
- Date: Sun, 8 Dec 1996 13:17:20 +0100 (MET)
-----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) = 4a1f2179c53c9106bc8d7738f4d55667
The 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-----
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]