Original issue date: September 18, 1996<BR>
Last revised: December 9, 1998<BR>
Updated vendor information for Silicon Graphics, Inc.

<P>A complete revision history is at the end of this file.

<STRONG> See also <A HREF="http://www.cert.org/advisories/CA-96.24.sendmail.daemon.mode.html">CA-96.24.sendmail.daemon.mode.html</A> for information
about additional vulnerabilities in sendmail. </STRONG>

<P>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.

<P>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.

<P>For beta testers of sendmail 8.8: The vulnerabilities described in
this advisory have been fixed in the beta version.

<P>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 
<A HREF=ftp://ftp.cert.org/pub/latest_sw_versions/sendmail>
ftp://ftp.cert.org/pub/latest_sw_versions/sendmail</A>
to identify the most current version of sendmail.

<H2>I. Description</H2>

<P>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.

<H4>Resource Starvation</H4>

<P>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
&quot;controlling user.&quot;

<P>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.

<P>Only the name of the controlling user is written in the queue
file. This name is derived by calling the system routine
<I>getpwuid(3)</I> 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 &quot;u&quot; and &quot;g&quot; options in older
releases) is assumed.

<P>In some cases, the system can be forced into resource starvation,
thus forcing <I>getpwuid(3)</I> 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 &quot;resource failure&quot; as
distinct from &quot;user id not found,&quot; sendmail has no way of
distinguishing between these cases; it assumes that the uid is unknown
and falls back to the default user.

<P>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.

<H4>Buffer Overflows</H4>

<P>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.

<P>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.

<H2>II. Impact</H2>

<H3>Resource Starvation</H3>

<P>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.

<P>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.

<H3>Buffer Overflows</H3>

<P>Anyone with access to an account on the system can gain root
access.

<H2>III. Solution</H2>

<P>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.

<P>In all cases, you should take the precautions listed in Sec. D.

<P>Note to beta testers of sendmail 8.8: The vulnerabilities described
in this advisory have been fixed in the beta version of 8.8.

<H3>A. Install a vendor patch.</H3>

<P>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.

<UL>
            Digital Equipment Corporation<BR>
            FreeBSD<BR>
            Hewlett-Packard Company<BR>
            IBM Corporation<BR>
            Linux<BR>
            Open Software Foundation<BR>
            The Santa Cruz Operation<BR>
            Silicon Graphics Inc.<BR>
	    Sun Microsystems, Inc.
</UL>

<H3>B. Upgrade to the current version of sendmail.</H3>

<P>Install sendmail 8.7.6. This version is a &quot;drop in&quot;
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.

<P>Sendmail 8.7.6 is available from

<P>
<A HREF=ftp://ftp.sendmail.org/ucb/src/sendmail/sendmail.8.7.6.tar.gz>ftp://ftp.sendmail.org/ucb/src/sendmail/sendmail.8.7.6.tar.gz</A>

<P>
<A HREF=ftp://ftp.cert.org/pub/tools/sendmail/>ftp://ftp.cert.org/pub/tools/sendmail/sendmail.8.7.6.tar.gz</A>

<P>
<A HREF=ftp://ftp.cert.dfn.de/pub/tools/net/sendmail/sendmail.8.7.6.tar.gz>ftp://ftp.cert.dfn.de/pub/tools/net/sendmail/sendmail.8.7.6.tar.gz</A>

<P>
<A HREF=ftp://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu/ucb/sendmail/*>ftp://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu/ucb/sendmail/*</A>

<P>MD5  (sendmail.8.7.6.tar.gz) = 4a1f2179c53c9106bc8d7738f4d55667

<P>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
<PRE>

 Type bits/keyID    Date       User ID
  pub  1024/BF7BA421 1995/02/23 Eric P. Allman &lt;eric@CS.Berkeley.EDU&gt;
            Key fingerprint =  C0 28 E6 7B 13 5B 29 02  6F 7E 43 3A 48 4F 45 29
                                Eric P. Allman  &lt;eric@Reference.COM&gt;
                                Eric P. Allman &lt;eric@Usenix.ORG&gt;
                                Eric P. Allman &lt;eric@Sendmail.ORG&gt;
                                Eric P. Allman &lt;eric@CS.Berkeley.EDU&gt;

</PRE>

<P>We strongly recommend that when you change to a newXS version of sendmail
you also change to the configuration files that are provided with that
version.

<P>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.

<P>For sites that use the ampersand character ('&amp;') in the gecos
field of /etc/passwd, they should be aware that this may cause the
full name returned to be corrupted or empty. (See man (4) passwd for
further details on the purpose of the ampersand character in the gecos
field.) Therefore when configuring sendmail, sites may also wish to
ensure that information in the gecos field is explicitly complete,
rather than rely on name expansion using the ampersand character.

<P>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
&quot;Converting Standard Sun Config Files to Sendmail Version 8&quot;
and was written by Rick McCarty of Texas Instruments Inc. It is
included in the distribution and is located in
contrib/converting.sun.configs.

<H3>C. Apply a workaround.</H3>

<H4>Resource Starvation</H4>

<P>Eric Allman, the author of sendmail, has provided the following
workaround to the resource starvation vulnerability.

<P>Using smrsh as &quot;prog&quot; 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.

<P>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
&quot;mailnull&quot; 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:

<PRE>

          mailnull:*:32765:32765:Sendmail Default User:/no/such/dir:/dev/null

</PRE>
A corresponding entry should be made in /etc/group:
<PRE>

          mailnull:*:32765:

</PRE>
These assume that there are no other users or groups with id = 32765
on your system; if there are, pick some other unique value.


<P>NOTE: When allocating a numeric uid to the &quot;mailnull&quot;
user you should be careful to ensure that this value is less than the
value of the UID_MAX kernel variable, if your system implements this
variable. To check whether your system implements this variable (and
the value that it uses), check for a reference to it in the
&quot;limits.h&quot; header file, which should be located in the
directory /usr/include, or one of its subdirectories.  For further
information on the use and content on the &quot;limits.h&quot; header
file, see the man (4) limits.

<P>After creating this user, change the line in /etc/sendmail.cf reading
<PRE>
          O DefaultUser=1:1
</PRE>
to read
<PRE>
          O DefaultUser=mailnull
</PRE>
If you are running 8.6.*, you will have to change the lines reading
<PRE>
          Ou1
          Og1
</PRE>
to read
<PRE>
          Ou32765
          Og32765
</PRE>

<P>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:

<PRE>
          define(`confDEF_USER_ID', 32765:32765)
</PRE>

<P>The actual values should, of course, match those in the passwd file.

<H4>Buffer Overflows</H4>
   
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).

<H3>D. Take additional precautions.</H3>

Regardless of which solution you apply, you should take these extra
precautions to protect your systems.
<UL>
<LI> Use the sendmail restricted shell program (smrsh)</LI>

<P>With *all* versions of sendmail, use the sendmail restricted shell
program (smrsh). You should do this whether you use vendor-supplied
sendmail or install sendmail yourself. Using smrsh gives you improved
administrative control over the programs sendmail executes on behalf
of users.

<P>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.

<P>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.

<P>smrsh is also distributed with some operating systems.

<LI><P>Use mail.local
</LI>

<P>If you run /bin/mail based on BSD 4.3 UNIX, replace /bin/mail with
mail.local, which is included in the sendmail distribution. It is also
included with some other operating systems distributions, such as
FreeBSD.

<P>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 <A HREF="http://www.cert.org/advisories/CA-95.02.binmail.vulnerabilities.html">CA-95.02</A>.

<P>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:

<P>define(`LOCAL_MAILER_PATH', /usr/lib/mail.local)

<LI><P>WARNING: Check for executable copies of old versions of mail programs
</LI>

<P>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.

<P>Similarly, if you replace /bin/mail with mail.local, remember to remove
old copies of /bin/mail or make them non-executable.
</UL>
<HR>

<H2>Appendix A - Vendor Information</H2>

<P>Below is a list of the vendors who have provided information for
this advisory. We will update this appendix as we receive additional
information.  If you do not see your vendor's name, please contact the
vendor directly.

<P>
<H3>Berkeley Software Design, Inc.</H3>

   BSDI has released a patch for BSD/OS V2.1 to update  sendmail to the 8.7.6
version. The patch is available from the 
	<A HREF=mailto:patches@BSDI.COM>patches@BSDI.COM</A> 
mailback server
<BR> or via ftp at:
<A HREF=ftp://ftp.BSDI.COM/bsdi/patches/patches-2.1/U210-024>ftp://ftp.BSDI.COM/bsdi/patches/patches-2.1/U210-024</A>

<H3>Digital Equipment Corporation</H3>

[About the resource starvation problem]

<P>  Source:

<P>Software Security Response Team<BR>
Copyright (c) Digital Equipment Corporation 1996. All rights reserved.<BR>
08.SEP.1996

<P>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.

<P><PRE>
    ftp://ftp.service.digital.com/public/{OS}/{vn.n}
                                                |     |
                                                |     |--version
                                                |--osf or ultrix

</PRE>
<P Align=right>- DIGITAL EQUIPMENT CORPORATION<BR> 9/96</P>

<H3>FreeBSD</H3>

All currently released FreeBSD distributions have this vulnerability, as
we distribute sendmail 8.7.x as part of our operating system.  However,
our -current and -stable source distributions were updated on 18 Sep 1996
to sendmail 8.7.6.  Users tracking -current or -stable are advised to
upgrade and recompile sendmail at their earliest convinience.

<P>An official FreeBSD security advisory, including patches to close this
vulnerability in FreeBSD 2.1.5 will be available shortly.  The security
advisory will appear at

<P>
<A HREF=ftp://freebsd.org/pub/CERT/patches/SA-96:18/>ftp://freebsd.org/pub/CERT/patches/SA-96:18/</A>
when available.

<H3>Hewlett-Packard Company</H3>

  HPSBUX9704-059

<P>HEWLETT-PACKARD SECURITY BULLETIN: #00059, 30 April 1997

<P>Description: Sendmail patches for HP-UX releases 9.X thru 10.20

<P>Security Bulletins are available from the HP Electronic<BR>
Support Center via electronic mail.

<P>User your browser to get to the HP Electronic Support<BR>
Center page at:

<P>
<A HREF=http://us-support.external.hp.com>http://us-support.external.hp.com</A>
<BR>
(for US, Canada, Asia-Pacific, &amp; Latin-America)

<P>
<A HREF=http://europe-support.external.hp.com>http://europe-support.external.hp.com</A>
<BR>
(for Europe)

<H3>IBM Corporation</H3>

The following APARs are being developed and will be available shortly.
See the appropriate release below to determine your action.

<H4>AIX 3.2</H4>

Apply the following fixes to your system:

<P>APAR - IX61303 IX61307

<H4>AIX 4.1</H4>

Apply the following fixes to your system:

APAR - IX61162 IX61306

<P>To determine if you have this APAR on your system, run the following
command:

<P>instfix -ik IX61162 IX61306

<H4>AIX 4.2</H4>

Apply the following fixes to your system:

APAR - IX61304 IX61305

<P>To determine if you have this APAR on your system, run the following
command:

<P>instfix -ik IX61304 IX61305



<H4>To Order</H4>

APARs may be ordered using Electronic Fix Distribution (via FixDist)
or from the IBM Support Center.  For more information on FixDist,

<P>
<A HREF=http://service.software.ibm.com/aixsupport/>http://service.software.ibm.com/aixsupport/</A>

<P>or send e-mail to 
	<A HREF=mailto:aixserv@austin.ibm.com>aixserv@austin.ibm.com</A> 
with a subject of &quot;FixDist&quot;.

<P>IBM and AIX are registered trademarks of International Business Machines
Corporation.



<H3>Linux</H3>

[For the resource starvation problem:]

<P>Debian Linux: not vulnerable (uses smail)

<P>Red Hat and derivatives:<BR>
<A HREF=ftp://ftp.redhat.com/pub/redhat-3.0.3/i386/updates/RPMS/sendmail*>ftp://ftp.redhat.com/pub/redhat-3.0.3/i386/updates/RPMS/sendmail*</A>


<H3>Open Software Foundation</H3>

OSF's OSF/1 R1.3.2 is not vulnerable to these types of attacks described in
the resource starvation sections of the advisory.

<P>OSF's OSF/1 R1.3.2 is vulnerable to the buffer overflow problems.
We will address the problem in our next maintenance release.

<H3>The Santa Cruz Operation</H3>

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:

<P>   SCO Internet FastStart release 1.0.0<BR>
SCO OpenServer releases 5.0.0 and 5.0.2

<P>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.

<P>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 &quot;mailsurr&quot;
mail system as the default, and as such are not vulnerable to this
problem unless otherwise configured to use sendmail.

<P>SCO intends to provide a similar patch for SCO UnixWare release 2.1.0
in the near future.

<P>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.

<P>You can download SLS oss443a as shown below.

<P>Anonymous ftp   (World Wide Web URL)

<A HREF="ftp://ftp.sco.COM/SSE/oss443a"> ftp://ftp.sco.COM/SSE/oss443a </A>          (SLS image)<BR>
<A HREF="ftp://ftp.sco.COM/SSE/oss443a.ltr.sse">ftp://ftp.sco.COM/SSE/oss443a.ltr.sse</A>   (cover letter/install notes)

<H4>Compuserve</H4>

SLS oss443a is also available in the SCO Forum on Compuserve.

<H4>SCO Online Support (SOS) BBS</H4>

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 &quot;Toolchest&quot; from the main SOS menu.

<P>The phone numbers available for interactive transfer from SOS are:

<P>1-408-426-9495                (USA)<BR>
+44 (0)1923 210 888          (United Kingdom)

<H4>Checksums</H4>
<PRE>
 sum -r
   ------

   13804   630 oss443a
   35304    14 oss443a.ltr.sse

   MD5
   ---

   MD5 (oss443a) = 549260a71ca76f4e98dd38bccb72748c
   MD5 (oss443a.ltr.sse) = 7475d83f0db64a1af69eb66cd392a9d3

</PRE>
Be sure to keep track of the README file at <A HREF=ftp://ftp.sco.COM/SSE/README>ftp://ftp.sco.COM/SSE/README</A>

for updates to this supplement.
<BR>
If you have further questions, contact your support provider. If you
need to contact SCO, please send electronic mail to 
	<A HREF=mailto:support@sco.COM>support@sco.COM</A> 
, or
contact SCO as follows:

<P>USA/Canada: 6am-5pm Pacific Daylight Time (PDT)

<P>

<P>1-800-347-4381  (voice)<BR>
1-408-427-5443  (fax)

<P>Pacific Rim, Asia, and Latin American customers: 6am-5pm Pacific Daylight Time
        (PDT)       

<P> 1-408-425-4726  (voice)<BR>
1-408-427-5443  (fax)

<P>Europe, Middle East, Africa: 9am-5:30pm Greenwich Mean Time (GMT)

<P>       +44 (0)1923 816344 (voice)<BR>
+44 (0)1923 817781 (fax)
XS

<H3>Silicon Graphics, Inc.</H3>

<P>Please refer to Silicon Graphics Inc. Security Advisory, "IRIX
mail(1)/rmail(1M)/sendmail(1M) Security Vulnerabilities," Number:
19980604-02-PX, distributed September 29, 1998 for additional information
relating to this vulnerability.

<P>The primary SGI anonymous FTP site for security information and patches is
sgigate.sgi.com (204.94.209.1).  Security information and patches are located
under the directories ~ftp/security and ~ftp/patches, respectively. The
Silicon Graphics Security Headquarters Web page is accessible at the URL
<A HREF="http://www.sgi.com/Support/security/security.html">http://www.sgi.com/Support/security/security.html</A>.

<P>
<H3>Sun Microsystems, Inc.</H3>

Sun Microsystems has provided the following list of patches in response
to this advisory:
<UL>
 
        103594-10 5.5.1 
       <BR> 103595-10 5.5.1_86   
       <BR> 102980-13 5.5    
       <BR> 102981-13 5.5_x86 
       <BR> 102066-18 5.4    
        <BR>102064-17 5.4_x86 
       <BR> 101739-17 5.3         
       <BR> 102423-07 4.1.4   
       <BR> 101665-10 4.1.3_U1
</UL>
<HR>
The CERT Coordination Center staff thanks Eric Allman, the author of sendmail,
for his extensive assistance with this advisory, Wolfgang Ley of DFN-CERT and
members of the AUSCERT for their contributions, and D. J. Bernstein of the
University of Illinois at Chicago for reporting the resource starvation
vulnerability.

<!--#include virtual="/include/footer_nocopyright.html" -->
<P>Copyright 1996 Carnegie Mellon University.</P>

<HR>

Revision History
<PRE>
Dec.  9, 1998  Updated vendor information for Silicon Graphics, Inc.
Aug. 24, 1998  Updated vendor information for Silicon Graphics, Inc.
Oct. 20, 1997  Appendix A - updated vendor information for Sun.
Sep. 24, 1997  Updated copyright statement
May 8, 1997    Appendix A - updated vendor information for Hewlett-Packard.
Nov. 21, 1996  Introduction - Added a pointer to CA-96.24 for information
               on more sendmail vulnerabilities.
Nov. 19, 1996  Appendix A - Updated Hewlett-Packard information to address
               both problems.
Sep. 21, 1996  Sec. III.B - added instructions on configuring sendmail at
               sites that use '&' in the gecos filed of /etc/passwd.
	       Sec. III.C - added a note on uid for &quot;mailnull&quot; user.
Sep. 19, 1996  Sec. III.B - added URL in Australia for sendmail
               Acknowledgements - included reference that had been omitted
               earlier.<BR>
               Appendix, FreeBSD - added an entry.<BR>
Sep. 18, 1996  Appendix, BSDI - added an entry containing patch information.

</PRE>