[linux-security] CERT Advisory CA-96.20 - Sendmail Vulnerabilities (fwd)

[jdassen@wi.leidenuniv.nl (J.H.M.Dassen)]

This CERT advisory is quite misleading wrt its Debian related information.

> Linux
> =====
> [For the resource starvation problem:]
> 
>    Debian Linux: not vulnerable (uses smail)

smail is our preferred MTA; sendmail is available too.

CERT should be contacted and provided with updated information.

Ray

Here's the full message:
> From linux-security-request@redhat.com Sun Dec  8 01:36:11 1996
> MBOX-Line: From linux-security-request@redhat.com  Sat Dec  7 19:03:39 1996
> Resent-Date: Thu, 19 Sep 1996 09:17:11 -0400
> Resent-From: Jeff Uphoff <juphoff@tarsier.cv.nrao.edu>
> Resent-Message-Id: <199609191317.JAA00237@tarsier.cv.nrao.edu>
> Resent-To: linux-security@tarsier.cv.nrao.edu, linux-alert@tarsier.cv.nrao.edu
> Message-Id: <199609181434.KAA18644@why.cert.org>
> Organization: CERT(sm) Coordination Center -  +1 412-268-7090
> From: CERT Advisory <cert-advisory@cert.org>
> To: cert-advisory@cert.org
> Date: Wed, 18 Sep 1996 10:34:33 -0400
> X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1
> X-Attribution: Up
> Sender: owner-linux-alert@tarsier.cv.nrao.edu
> Resent-Date: Fri, 6 Dec 1996 12:44:53 +0100 (MEZ)
> Resent-From: Sascha Kettler <kettler@rummelplatz.uni-mannheim.de>
> Resent-To: Sascha Kettler <kettler@dekbwl.bwl.uni-mannheim.de>
> Resent-Message-Id: <Pine.HPP.3.91.961206124452.4690w@rummelplatz.uni-mannheim.de>
> Old-Status: RO
> Reply-To: linux-security@redhat.com
> X-Mailing-List: <linux-security@redhat.com> archive/latest/59
> X-Loop: linux-security@redhat.com
> Precedence: list
> Resent-Sender: linux-security-request@redhat.com
> Subject: [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-----
> 
> 
-- 
ART  A friend of mine in Tulsa, Okla., when I was about eleven years old. 
I'd be interested to hear from him. There are so many pseudos around taking 
his name in vain. 
- The Hipcrime Vocab by Chad C. Mulligan 


--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com