S-96-70 sendmail Group Permissions Vulnerability (fwd)

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

Forwarded message:
>From systeembeheerders-error@rulsur.LeidenUniv.NL Wed Dec  4 10:53:55 1996
Resent-date: Wed, 04 Dec 1996 10:30:12 +0100 (MET)
Resent-date: Wed, 04 Dec 1996 10:28:35 +0001
Date: Tue, 3 Dec 1996 21:46 GMT+1
Resent-from: Ryko Prins <R.Prins@cri.LeidenUniv.NL>
From: Gert.Meijerink@utwente.nl
Subject: S-96-70 sendmail Group Permissions Vulnerability
Sender: GERT A MEIJERINK +31 53 892326 <RCGERT@utwente.nl>
To: cert-nl-ssc@dl.surfnet.nl
Cc: cert-nl-kernel@surfnet.nl
Errors-to: systeembeheerders-error@rulsur.LeidenUniv.NL
Resent-message-id: <01ICLXKO0GF60005Y8@rulsur.LeidenUniv.NL>
Message-id: <EBD8BD8A20000EBB@UTWENTE.NL>
X-VMS-To: IN%"cert-nl-ssc@surfnet.nl"
X-VMS-Cc: IN%"cert-nl-kernel@surfnet.nl",RCGERT
Content-transfer-encoding: 7BIT
Comments: Authenticated sender is <prins@rulcri>

-----BEGIN PGP SIGNED MESSAGE-----



===============================================================================
Security Advisory                                                       CERT-NL
===============================================================================
Author/Source : Gert Meijerink                              Index  :    S-96-70
Distribution  : World                                       Page   :
Classification: External                                    Version:
Subject       : sendmail Group Permissions Vulnerability    Date   :   3-Dec-96
===============================================================================

By courtesy of AUSCERT, the Australian CERT, we received information on a
vulnerability in sendmail affecting version 8.

This information is made publicly available by AUSCERT advisory AA-96.15, 
dated 3-dec-96.

CERT-NL recommends that sites apply the steps outlines in Section 3.

Keywords:    sendmail, group permissions

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

=============================================================================
CERT-NL is the Computer Emergency Response Team for SURFnet customers.
SURFnet is the Dutch network for educational, research and related institutes.
CERT-NL is a member of the Forum of Incident Response and Security Teams
(FIRST).

All CERT-NL material is available under:
  http://www.surfnet.nl/surfnet/security/cert-nl.html
  ftp://ftp.surfnet.nl/surfnet/net-security

In case of computer or network security problems please contact your
local CERT/security-team or CERT-NL  (if your institute is NOT a SURFnet
customer please address the appropriate (local) CERT/security-team).

CERT-NL is one/two hour(s) ahead of UTC (GMT) in winter/summer,
i.e. UTC+0100 in winter and UTC+0200 in summer (DST).
   Email:     cert-nl@surfnet.nl
   Phone:     +31 302 305 305
   Fax:       +31 302 305 329
   Snailmail: SURFnet bv
       Attn. CERT-NL
       P.O. Box 19035
       NL - 3501 DA  UTRECHT
       The Netherlands
   A 7 * 24 hours phone number is available to SURFnet SSC's and FIRST
   members on request.
==============================================================================


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: cp850

iQCVAwUBMqSI8mL2fnkJN/jpAQEVtAP9EmQ5Di17VmI8sHn884qd9ncgaLsrK1/s
YwZ+d+Cv6y12qbUBF5o139evilWSC8c4Hfksoa//sVtlFQumv8FjYnZ0TzpODtgG
BPl42h7D/EM+sW4IYe2we+a1FqzZheLFyCwwaEfJsWzcyIQjuD9/WlUy3WNGoPHD
TwsNxjiGUE4=
=swlL
-----END PGP SIGNATURE-----



-- 
Cyberspace, a final frontier. These are the voyages of my messages, 
on a lightspeed mission to explore strange new systems and to boldly go
where no data has gone before. 


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