home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / hacking / general / cert0130.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  20.2 KB  |  467 lines
  1.  
  2. -----BEGIN PGP SIGNED MESSAGE-----
  3.  
  4. =============================================================================
  5. CERT(sm) Advisory CA-96.25
  6. Original issue date: December 10, 1996
  7. Last revised: -- December 20, 1996
  8.                  Appendix A - Added Cray vendor information
  9.  
  10.                  A complete revision history is at the end of this file.
  11.  
  12. Topic: Sendmail Group Permissions Vulnerability
  13. - -----------------------------------------------------------------------------
  14.  
  15. The CERT Coordination Center has received reports of a security problem in
  16. sendmail affecting version 8. By exploiting this vulnerability, a local user
  17. can run programs with group permissions of other users. For the exploitation
  18. to be successful, group-writable files must be available on the same file
  19. system as a file that the attacker can convince sendmail to trust.
  20.  
  21. The CERT/CC team recommends installing vendor patches or upgrading to the
  22. current version of sendmail (8.8.4). Until you can do so, we urge you to
  23. apply the workaround provided in Section III.C. In all cases, be sure to take
  24. the extra precautions listed in Section III.D.
  25.  
  26. We will update this advisory as we receive additional information. Please
  27. check advisory files regularly for updates that relate to your site. In
  28. addition, you can check ftp://info.cert.org/pub/latest_sw_versions/sendmail
  29. to identify the most current version of sendmail.
  30.  
  31. - -----------------------------------------------------------------------------
  32.  
  33. I.  Description
  34.  
  35.      When sendmail causes mail to be delivered to a program listed in a
  36.      .forward or :include: file, that program is run with the group
  37.      permissions possessed by the user who owns that .forward or :include:
  38.      file. The file's owner attribute is used to initialize the list of group
  39.      permissions that are in force when the program is run. This list is
  40.      determined by scanning the /etc/group file, NIS or NIS+ group maps, or
  41.      other similar vendor-specific databases (such as netinfo on OpenStep).
  42.  
  43.      It is possible for users to obtain group permissions they should not
  44.      have by linking to a file that is owned by someone else, but on which
  45.      they have group write permissions. By changing that file, users can
  46.      acquire the group permissions of the owner of that file.
  47.  
  48.      Exploitation is possible if the attacked user has a file that is
  49.      group writable by the attacker on the same file system as either (a) the
  50.      attacker's home directory or (b) an :include: file that is referenced
  51.      directly from the aliases file and is in a directory writable by the
  52.      attacker. The first (.forward) attack only works against root. This
  53.      attack does not give users root "owner" permissions, but does give them
  54.      access to the groups that list root in /etc/group.
  55.  
  56.  
  57. II.  Impact
  58.  
  59.      A local attacker can gain the group permissions of another user.
  60.  
  61. III. Solution
  62.  
  63.      Install a patch from your vendor if one is available (Section A) or
  64.      upgrade to the current version of sendmail (Section B). Until you can
  65.      take one of those actions, we recommend applying the workaround described
  66.      in Section C. In all cases, you should take the precautions described in
  67.      Section D.
  68.  
  69.      A.  Install a vendor patch.
  70.  
  71.          Below is a list of vendors who have provided information about
  72.          sendmail. Details are in Appendix A of this advisory; we will update
  73.          the appendix as we receive more information. If your vendor's name is
  74.          not on this list, please contact the vendor directly.
  75.  
  76.             Berkeley Software Design, Inc. (BSDI)
  77.             Cray Research
  78.             Digital Equipment Corporation
  79.             FreeBSD, Inc.
  80.             Hewlett-Packard Company
  81.             IBM Corporation
  82.             NEC Corporation
  83.             The Santa Cruz Operation, Inc. (SCO)
  84.             Silicon Graphics Inc
  85.             Solbourne (Grumman Support Systems)
  86.             Sun Microsystems, Inc.
  87.  
  88.      B.  Upgrade to the current version of sendmail.
  89.  
  90.          Install sendmail 8.8.4. This version is a "drop in" replacement for
  91.          8.8.x. There is no patch for any version of sendmail before 8.8.0.
  92.          If you are running such a version, strongly consider moving to
  93.          version 8.8.4.
  94.  
  95.          Sendmail 8.8.4 is available from
  96.  
  97.        ftp://ftp.sendmail.org/ucb/src/sendmail/sendmail.8.8.4.tar.gz
  98.        ftp://info.cert.org/pub/tools/sendmail/sendmail.8.8.4.tar.gz
  99.        ftp://ftp.cert.dfn.de/pub/tools/net/sendmail/sendmail.8.8.4.tar.gz
  100.        ftp://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu/ucb/sendmail/
  101.  
  102.          MD5 (sendmail.8.8.4.tar.gz) = 64ce6393a6968a0dc7c6652dace127b0
  103.  
  104.          Also in that directory are .Z and .sig files. The .Z file contains
  105.          the same bits as the .gz file, but is compressed using UNIX compress
  106.          instead of gzip. The .sig is Eric Allman's PGP signature for the
  107.          uncompressed tar file. The key fingerprint is
  108.  
  109.   Type bits/keyID    Date       User ID
  110.   pub  1024/BF7BA421 1995/02/23 Eric P. Allman <eric@CS.Berkeley.EDU>
  111.            Key fingerprint =  C0 28 E6 7B 13 5B 29 02  6F 7E 43 3A 48 4F 45 29
  112.                                 Eric P. Allman <eric@Reference.COM>
  113.                                 Eric P. Allman <eric@Usenix.ORG>
  114.                                 Eric P. Allman <eric@Sendmail.ORG>
  115.                                 Eric P. Allman <eric@CS.Berkeley.EDU>
  116.  
  117.          When you change to a new version of sendmail, we strongly recommend
  118.          also changing to the configuration files that are provided with that
  119.          version. Significant work has been done to make this task easier.
  120.          (In fact, it is highly likely that older configuration files will
  121.          not work correctly with sendmail version 8.) It is now possible to
  122.          build a sendmail configuration file (sendmail.cf) using the
  123.          configuration files provided with the sendmail release. Consult the
  124.          cf/README file for a more complete explanation. Creating your
  125.          configuration files using this method makes it easier to incorporate
  126.          future changes to sendmail into your configuration files.
  127.  
  128.          Sun sendmail users: A paper is available to help you convert your
  129.          sendmail configuration files from the Sun version of sendmail to one
  130.          that works with sendmail version 8.8.x. The paper is entitled
  131.          "Converting Standard Sun Config Files to Sendmail Version 8" and was
  132.          written by Rick McCarty of Texas Instruments Inc. It is included in
  133.          the distribution and is located in contrib/converting.sun.configs.
  134.  
  135.      C.  Apply a workaround.
  136.  
  137.          Eric Allman, the author of sendmail, has provided the following
  138.          workaround. Note that this workaround is for sendmail 8.8.3. If you
  139.          are running a version less than 8.8.3 we strongly recommend to
  140.          upgrade at least to that version (or install the appropriate vendor
  141.          patches). See CERT advisories CA-95:08 and CA-96.24 for more
  142.          information on vulnerabilities in older sendmail versions.
  143.  
  144.          Set the UnsafeGroupWrites option in the sendmail.cf file. This
  145.          option tells sendmail that group-writable files should not be
  146.          considered safe for mailing to programs or files, causing sendmail
  147.          to refuse to run any programs referenced from group-writable files.
  148.          Setting this option is a good idea in any case, but may require
  149.          your users to tighten permissions on their .forward files and
  150.          :include: files.
  151.  
  152.          The command "find <filesystem> -user root -type f -perm -020 -print"
  153.          will print the names of all files owned by root that are group
  154.          writable on a given file system. While this is only a partial
  155.          solution we encourage you to carefully check all entries in your
  156.          alias and .forward files (incl. aliases obtained via NIS, NIS+,
  157.          or similar information systems) to check for group writable files.
  158.  
  159.          In addition, group memberships should be audited regularly. Users
  160.          should not be in groups without a specific need. In particular,
  161.          root generally does not need to be listed in most groups.
  162.  
  163.          As a policy matter, root should have a umask of 022 so that
  164.          group-writable files are made consciously. Also, the aliases
  165.          file should not reference :include: files in writable directories.
  166.  
  167.          While checking for writable directories, it's not enough to check the
  168.          permissions of the directory the file itself lives in. You also have
  169.          to check all other directories "on top" of that dir. If you, for
  170.          example, want to check the permissions of the file
  171.          /where/ever/here/file you have to check for group-write permissions
  172.          not only in the directory /where/ever/here but also check the
  173.          directories /where/ever and /where.
  174.  
  175.  
  176.      D.  Take additional precautions
  177.  
  178.          Regardless of which solution you apply, you should take these extra
  179.          precautions to protect your systems. These precautions do not address
  180.          the vulnerabilities described herein, but are recommended as good
  181.          practices to follow for the safer operation of sendmail.
  182.  
  183.          * Use the sendmail restricted shell program (smrsh)
  184.  
  185.            With *all* versions of sendmail, use the sendmail restricted shell
  186.            program (smrsh). You should do this whether you use vendor-supplied
  187.            sendmail or install sendmail yourself. Using smrsh gives you
  188.            improved administrative control over the programs sendmail executes
  189.            on behalf of users.
  190.  
  191.            A number of sites have reported some confusion about the need to
  192.            continue using the sendmail restricted shell program (smrsh) when
  193.            they install a vendor patch or upgrade to a new version of
  194.            sendmail. You should always use the smrsh program.
  195.  
  196.            smrsh is included in the sendmail Version 8 distribution in the
  197.            subdirectory smrsh. See the RELEASE_NOTES file for a description
  198.            of how to integrate smrsh into your sendmail configuration file.
  199.  
  200.            smrsh is also distributed with some operating systems.
  201.  
  202.          * Use mail.local
  203.  
  204.            If you run /bin/mail based on BSD 4.3 UNIX, replace /bin/mail with
  205.            mail.local, which is included in the sendmail distribution. As of
  206.            Solaris 2.5 and beyond, mail.local is included with the standard
  207.            distribution. It is also included with some other operating systems
  208.            distributions, such as FreeBSD.
  209.  
  210.            Although the current version of mail.local is not a perfect
  211.            solution, it is important to use it because it addresses
  212.            vulnerabilities that are being exploited. For more details, see
  213.            CERT advisory CA-95:02.
  214.  
  215.            To use mail.local, replace all references to /bin/mail with
  216.            /usr/lib/mail.local. If you are using the M4(1)-based configuration
  217.            scheme provided with sendmail 8.X, add the following to your
  218.            configuration file:
  219.  
  220.               define(`LOCAL_MAILER_PATH', /usr/lib/mail.local)
  221.  
  222.          * WARNING: Check for setuid executable copies of old versions of
  223.                     mail programs
  224.  
  225.            If you leave setuid executable copies of older versions of
  226.            sendmail installed in /usr/lib (on some systems, it may be
  227.            installed elsewhere), the vulnerabilities in those versions could
  228.            be exploited if an intruder gains access to your system. This
  229.            applies to sendmail.mx as well as other sendmail programs. Either
  230.            delete these versions or change the protections on them to be
  231.            non-executable.
  232.  
  233.            Similarly, if you replace /bin/mail with mail.local, remember to
  234.            remove old copies of /bin/mail or make them non-executable.
  235.  
  236. IV.  Additional Notes
  237.  
  238.      Three other sendmail vulnerabilities are described in CERT advisory
  239.      CA-96.20 and CA-96.24; see those advisories for details.
  240.  
  241.      Sendmail 8.8.4 also fixes a denial-of-service attack. If your system
  242.      relies on the TryNullMXList option to forward mail to third-party MX
  243.      hosts, an attacker can force that option off, thereby causing mail to
  244.      bounce. As a workaround, you can use the mailertable feature to deliver
  245.      to third party MX hosts regardless of the setting of the TryNullMXList
  246.      option.
  247.  
  248. ...........................................................................
  249.  
  250. Appendix A - Vendor Information
  251.  
  252. Below is a list of the vendors who have provided information for this
  253. advisory. We will update this appendix as we receive additional information.
  254. If you do not see your vendor's name, please contact the vendor directly.
  255.  
  256. Berkeley Software Design, Inc.
  257. ==============================
  258.   BSD/OS is vulnerable to this problem and a patch (U210-030) is
  259.   available from our mail-back patches server at <patches@BSDI.COM>
  260.   or via ftp at
  261.  
  262.   ftp://ftp.BSDI.COM/bsdi/patches/patches-2.1/U210-030
  263.  
  264. Cray Research
  265. =============
  266.   Sendmail version 8 has not been included in any released Unicos
  267.   system, so this is not a problem for current Unicos systems.
  268.  
  269.  
  270. Digital Equipment Corporation
  271. =============================
  272.   This problem is currently under review by engineering to determine if
  273.   it impacts DIGITAL UNIX and DIGITAL ULTRIX sendmail implementations.
  274.  
  275.  
  276. FreeBSD, Inc.
  277. =============
  278.   FreeBSD versions 2.1.5, 2.1.6, and 2.1.6.1 are affected by the group
  279.   vulnerability.  Versions 2.1.6 and 2.1.6.1 are affected by the denial of
  280.   service vulnerability.  All known sendmail security problems will have been
  281.   addressed prior to the upcoming 2.2 release.  Given the complex nature of
  282.   the patches produced by the sendmail author, user's are encouraged to follow
  283.   the workarounds described in this advisory or apply and install patches
  284.   available directly from the author to upgrade to Sendmail 8.8.4 available
  285.   from the URLs listed in this advisory.
  286.  
  287.   We believe FreeBSD version 2.1.0 and prior to be unaffected by these
  288.   particular vulnerabilities, however there are significant other security
  289.   vulnerabilities in the sendmail supplied in prior releases.  All FreeBSD
  290.   users should consider upgrading to sendmail 8.8.4 or removing sendmail from
  291.   their systems if they are concerned about unauthorized root access from an
  292.   unprivileged user account.
  293.  
  294.  
  295. Hewlett-Packard Company
  296. =======================
  297.    Vulnerabilities
  298.    ---------------
  299.    1. Sendmail Group Permissions Vulnerability
  300.    2. Denial of Service Attack using the sendmail configuration variable
  301.        TryNullM\XList.
  302.  
  303.    Vulnerable releases
  304.    --------------------
  305.    9.x
  306.    pre-10.2 10.x
  307.    10.2
  308.  
  309.    The 9.x, pre-10.2 10.x sendmail is vulnerable with respect to the "Sendmail
  310.    Group Permissions Vulnerability".
  311.  
  312.    The 10.2 sendmail is vulnerable with respect to both the reported security
  313.    holes.
  314.  
  315.    Patches for these vulnerabilities are in progress.
  316.  
  317.  
  318. IBM Corporation
  319. ===============
  320.   The version of sendmail that ships with AIX is vulnerable to the
  321.   conditions listed in this advisory. A fix is in progress and the
  322.   APAR numbers will be available soon.
  323.  
  324.   IBM and AIX are registered trademarks of International Business Machines
  325.   Corporation.
  326.  
  327.  
  328. NEC Corporation
  329. ===============
  330.   Checking out the vulnerability. Contacts for further information
  331.   by e-mail:UX48-security-support@nec.co.jp.
  332.  
  333.  
  334. The Santa Cruz Operation, Inc. (SCO)
  335. ====================================
  336.   Any SCO operating system running a version of sendmail provided by SCO
  337.   is vulnerable to this problem. SCO will soon be providing a Support Level
  338.   Supplement, (SLS), to address this issue for the following releases of SCO
  339.   software:
  340.  
  341.   SCO Internet FastStart release 1.0.0, 1.1.0
  342.   SCO OpenServer releases 5.0.0 and 5.0.2
  343.  
  344.   The SLS will provide a version of sendmail release 8.8.4 for these
  345.   platforms.
  346.  
  347.   Note that only SCO Internet FastStart uses sendmail as the default mail
  348.   system. All other SCO operating systems use other mail systems such as the
  349.   Multi-Channel Memorandum Distribution Facility (MMDF) or the "mailsurr" mail
  350.   system as the default, and as such are not vulnerable to this problem unless
  351.   otherwise configured to use sendmail.
  352.  
  353.   Please watch the following URLs for availability information:
  354.  
  355.   ftp://ftp.sco.COM/SLS/README
  356.   ftp://ftp.sco.COM/SSE/README
  357.  
  358.  
  359. Silicon Graphics Inc.
  360. =====================
  361.   Currently Silicon Graphics Inc does not provide a 8.8.x sendmail
  362.   version but instead provides a 8.6.12 version. Silicon Graphics
  363.   has evaluated this issue as possibly applicable to the 8.6.12 version
  364.   provided by Silicon Graphics and has not found this version to be
  365.   vulnerable. No further action is required.
  366.  
  367.  
  368. Solbourne (Grumman Support Systems)
  369. ==================================
  370.  
  371.   Solbourne customers running the supported sendmail version
  372.  
  373.         SendMail version 1.1 of 92/11/12
  374.  
  375.   are not vulnerable to this 'denial-of-service' attack.
  376.  
  377.   Those Solbourne customers running later versions of sendmail
  378.   are probably vulnerable and should consider applying the
  379.   workaround or installing the latest version of sendmail.
  380.   No patches are available.
  381.  
  382.  
  383. Sun Microsystems, Inc.
  384. ======================
  385.   All Sun sendmails are susceptible to both vulnerabilities. We will
  386.   produce and announce patches for all supported versions of SunOS.
  387.   We expect the patches to be available later this month.
  388.  
  389.  
  390. - -----------------------------------------------------------------------------
  391. The CERT Coordination Center thanks Eric Allman, AUSCERT, Terry Kyriacopoulos
  392. of Interlog Internet Services, and Dan Bernstein of the University of
  393. Illinois, Chicago for their contributions to the development of this advisory.
  394. - -----------------------------------------------------------------------------
  395.  
  396. If you believe that your system has been compromised, contact the CERT
  397. Coordination Center or your representative in the Forum of Incident Response
  398. and Security Teams (see ftp://info.cert.org/pub/FIRST/first-contacts).
  399.  
  400.  
  401. CERT/CC Contact Information
  402. - ----------------------------
  403. Email    cert@cert.org
  404.  
  405. Phone    +1 412-268-7090 (24-hour hotline)
  406.                 CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4)
  407.                 and are on call for emergencies during other hours.
  408.  
  409. Fax      +1 412-268-6989
  410.  
  411. Postal address
  412.          CERT Coordination Center
  413.          Software Engineering Institute
  414.          Carnegie Mellon University
  415.          Pittsburgh PA 15213-3890
  416.          USA
  417.  
  418. Using encryption
  419.    We strongly urge you to encrypt sensitive information sent by email. We can
  420.    support a shared DES key or PGP. Contact the CERT/CC for more information.
  421.    Location of CERT PGP key
  422.          ftp://info.cert.org/pub/CERT_PGP.key
  423.  
  424. Getting security information
  425.    CERT publications and other security information are available from
  426.         http://www.cert.org/
  427.         ftp://info.cert.org/pub/
  428.  
  429.    CERT advisories and bulletins are also posted on the USENET newsgroup
  430.         comp.security.announce
  431.  
  432.    To be added to our mailing list for advisories and bulletins, send your
  433.    email address to
  434.         cert-advisory-request@cert.org
  435.  
  436. - ---------------------------------------------------------------------------
  437. Copyright 1996 Carnegie Mellon University
  438. This material may be reproduced and distributed without permission provided
  439. it is used for noncommercial purposes and the copyright statement is
  440. included.
  441.  
  442. CERT is a service mark of Carnegie Mellon University.
  443. - ---------------------------------------------------------------------------
  444.  
  445. This file:
  446.           ftp://info.cert.org/pub/cert_advisories/CA-96.25.sendmail_groups
  447.           http://www.cert.org
  448.                click on "CERT Advisories"
  449.  
  450.  
  451. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  452. Revision history
  453.  
  454. Dec. 20, 1996    Appendix A, Cray - added vendor information.
  455.  
  456.  
  457. -----BEGIN PGP SIGNATURE-----
  458. Version: 2.6.2
  459.  
  460. iQCVAwUBMrq8k3VP+x0t4w7BAQGLBAQAwQP9WcB4MaMzlYyETDUQ9jQRAWGIGr6i
  461. FXI+0HpceZsI8cYYvse8VuPGA79zEYlCZ3RQJM4xbZU/4sonhi4tUhheScx78moh
  462. jrJK/sA7MDl1M098Vb3VKigQqhPv+gaaSCbkbRGNoE/pGNCqW0pa5OIPmxWEDxeh
  463. tgLPgD3IJfU=
  464. =vzb0
  465. -----END PGP SIGNATURE-----
  466.  
  467.