home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / hacking / general / cert0137.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  21.6 KB  |  498 lines
  1.  
  2. -----BEGIN PGP SIGNED MESSAGE-----
  3.  
  4. =============================================================================
  5. CERT(sm) Advisory CA-97.05
  6. Original issue date: January 28, 1997
  7. Last revised: March 5, 1997
  8.               Appendix A, updated NEC entry.              
  9.  
  10. Topic: MIME Conversion Buffer Overflow in Sendmail Versions 8.8.3 and 8.8.4
  11. - -----------------------------------------------------------------------------
  12.  
  13. The CERT Coordination Center has received reports of a vulnerability in
  14. sendmail versions 8.8.3 and 8.8.4. By sending a carefully crafted email
  15. message to a system running a vulnerable version of sendmail, intruders
  16. may be able to force sendmail to execute arbitrary commands with root
  17. privileges.
  18.  
  19. The CERT/CC team recommends that you install a vendor patch (Section III.A) or
  20. upgrade to sendmail 8.8.5 (Section III.B). We have provided a workaround that
  21. you can use on vulnerable versions of 8.8.3 and 8.8.4 until you are able to
  22. implement one of these solutions (Section III.C). Regardless of the solution
  23. you apply, we urge you to take the additional precautions described in Section
  24. III.D. Note that this advisory contains additional material to that previously
  25. published by other response teams.
  26.  
  27. We will update this advisory as we receive additional information. Please
  28. check advisory files regularly for updates that relate to your site.
  29.  
  30. - -----------------------------------------------------------------------------
  31.  
  32. I.   Description
  33.  
  34.      Sendmail version 8 contains support for MIME (Multipurpose Internet
  35.      Mail Extensions) as defined initially by RFC 1341 and modified by RFC
  36.      1521. The central idea behind MIME is the following, taken from the
  37.      introduction to RFC 1341:
  38.  
  39.        "... designed to provide facilities to include multiple objects
  40.        in a single message, to represent body text in character sets other
  41.        than US-ASCII, to represent formatted multi-font text messages, to
  42.        represent non-textual material such as images and audio fragments,
  43.        and generally to facilitate later extensions defining new types of
  44.        Internet mail for use by cooperating mail agents."
  45.  
  46.      The support in sendmail version 8 includes data translations in which a
  47.      message's body is either stripped to 7-bit ASCII, achieved by forcing the
  48.      8th bit to be off, or 8-bit MIME, achieved by leaving the 8th bit as is.
  49.  
  50.      Sendmail can be configured for either of these translations on a
  51.      mailer-by-mailer basis depending on the flags defined for that
  52.      mailer. The flags in question here are `7', `8', and `9' (the default).
  53.      Refer to the "Sendmail Installation and Operations Guide," Section 5.4,
  54.      for a more complete discussion. A PostScript version of this guide is
  55.      included in the sendmail distribution in the /doc/op directory.
  56.  
  57.      With the release of sendmail version 8.8.3, a serious security
  58.      vulnerability was introduced that allows remote users to execute
  59.      arbitrary commands on the local system with root privileges. By sending
  60.      a carefully crafted email message to a system running a vulnerable
  61.      version of sendmail, intruders may be able to force sendmail to execute
  62.      arbitrary commands with root privileges. Those commands are run on the
  63.      same system where the vulnerable sendmail is running.
  64.  
  65.      In most cases, the MIME conversion of email is done on final delivery;
  66.      that is, to the local mailbox or a program. Therefore, this vulnerability
  67.      may be exploited on systems despite firewalls and other network boundary
  68.      protective measures.
  69.  
  70.      Versions before 8.8.3 do not contain this vulnerability, but they
  71.      do contain other vulnerabilities. We strongly recommended that you
  72.      follow the steps given in Section III below to eliminate those
  73.      vulnerabilities from your systems.
  74.  
  75.  
  76.      Determining if you are vulnerable
  77.      ---------------------------------
  78.      Systems are vulnerable to this attack if both of the following
  79.      conditions are true:
  80.  
  81.      1. The version of sendmail is 8.8.3 or 8.8.4. To determine the
  82.         version of sendmail, use the following command:
  83.  
  84.          % /usr/lib/sendmail -d0 -bt < /dev/null | grep -i Version
  85.  
  86.         If the string returned is "Version 8.8.3" or "Version 8.8.4", then
  87.         this version of sendmail contains the vulnerability. Typically,
  88.         sendmail is located in the /usr/lib directory, but it may be elsewhere
  89.         on your system.
  90.  
  91.      2. When you examine the sendmail configuration file (usually,
  92.         /etc/sendmail.cf), the `9' flag is set in the "F=" (Flags) section for
  93.         any Mailer specifications (Sections starting with `M' in the first
  94.         column, such as "Mprog" or "Mlocal").
  95.  
  96.         Use of the `9' flag can usually be determined using the
  97.         following command (depending on your sendmail configuration):
  98.  
  99.          % grep '^M.*F=[^,]*9' /etc/sendmail.cf
  100.  
  101.         If any lines are output from this command, then the sendmail
  102.         configuration may be vulnerable.
  103.  
  104.         The `9' flag is set by default for the local and program mailers when
  105.         the sendmail.cf file is generated using the m4 files distributed with
  106.         sendmail version 8.8.x. Versions of sendmail before 8.8.0 did not set
  107.         this flag by default when generating sendmail.cf. The `9' flag is also
  108.         set by default in the precompiled example configuration files found in
  109.         the cf/cf/obj/ subdirectory of the sendmail version 8.8.x distribution.
  110.  
  111. II. Impact
  112.  
  113.      Remote users can gain root privileges on a machine running sendmail
  114.      versions 8.8.3 or 8.8.4 that does 7-to-8 bit conversion. They do not
  115.      need access to an account on the system to exploit the vulnerability.
  116.  
  117. III. Solution
  118.  
  119.      Install a patch from your vendor if one is available (Section A) or
  120.      upgrade to the current version of sendmail (Section B). Until you can
  121.      take one of those actions, we recommend applying the workaround described
  122.      in Section C. In all cases, you should take the precautions described
  123.      in Section D.
  124.  
  125.      A. Install a vendor patch.
  126.  
  127.         Below is a list of vendors who have provided information about
  128.         sendmail. Details are in Appendix A of this advisory; we will update
  129.         the appendix as we receive more information. If your vendor's name
  130.         is not on this list, the CERT/CC did not hear from that vendor.
  131.         Please contact the vendor directly.
  132.  
  133.            Berkeley Software Design, Inc. (BSDI)
  134.            Caldera OpenLinux
  135.            Cray Research - A Silicon Graphics Company
  136.            Data General Corporation
  137.            Digital Equipment Corporation
  138.            Hewlett-Packard Corporation
  139.            IBM Corporation
  140.            NEC Corporation
  141.            NeXT Software, Inc.
  142.            Silicon Graphics, Inc.
  143.            Sun Microsystems, Inc.
  144.  
  145.      B. Upgrade to sendmail version 8.8.5.
  146.  
  147.         Eric Allman has released a new version of sendmail which fixes this
  148.         vulnerability. This can be obtained from the following locations:
  149.  
  150.         ftp://ftp.sendmail.org/pub/sendmail/
  151.         ftp://ftp.cs.berkeley.edu/ucb/src/sendmail/
  152.         ftp://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu/ucb/sendmail/
  153.         ftp://ftp.cert.dfn.de/pub/tools/net/sendmail/
  154.         ftp://ftp.cert.org/pub/tools/sendmail/
  155.  
  156.         The MD5 checksum for this distribution is:
  157.  
  158.         MD5 (sendmail.8.8.5.patch) = 775c47d16d40ebd2b917dfcc65d92e90
  159.         MD5 (sendmail.8.8.5.tar.gz) = 7c32c42a91325dd00b8518e90c26cffa
  160.         MD5 (sendmail.8.8.5.tar.sig) = b62ba16c7e863853b3efeb955eec4214
  161.         MD5 (sendmail.8.8.5.tar.Z) = 7b847383899c0eb65987213a5caf89c8
  162.  
  163.         Also in that directory are .Z and .sig files. The .Z file contains
  164.         the same bits as the .gz file, but it is compressed using UNIX compress
  165.         instead of gzip. The .sig is Eric Allman's PGP signature for the
  166.         uncompressed tar file. The key fingerprint is
  167.  
  168.     Type bits/keyID    Date       User ID
  169.     pub  1024/BF7BA421 1995/02/23 Eric P. Allman <eric@CS.Berkeley.EDU>
  170.             Key fingerprint =  C0 28 E6 7B 13 5B 29 02  6F 7E 43 3A 48 4F 45 29
  171.                                 Eric P. Allman <eric@Reference.COM>
  172.                                 Eric P. Allman <eric@Usenix.ORG>
  173.                                 Eric P. Allman <eric@Sendmail.ORG>
  174.                                 Eric P. Allman <eric@CS.Berkeley.EDU>
  175.  
  176.         When you change to a new version of sendmail, we strongly recommend
  177.         also changing to the configuration files that are provided with that
  178.         version. (In fact, it is highly likely that older configuration files
  179.         will not work correctly with sendmail version 8.) It is now possible
  180.         to build a sendmail configuration file (sendmail.cf) using the
  181.         configuration files provided with the sendmail release. Consult the
  182.         cf/README file for a more complete explanation. Creating your
  183.         configuration files using this method makes it easier to incorporate
  184.         future changes to sendmail into your configuration files.
  185.  
  186.      C. Workaround for existing sendmail version 8.8.3 and 8.8.4 installations
  187.  
  188.         Eric Allman, the author of sendmail, has provided the following
  189.         workaround, which you can use until you can take the steps recommended
  190.         in Sec. A or B.
  191.  
  192.         The /etc/sendmail.cf file should be modified to remove the use of the
  193.         `9' flag for all Mailer specifications (lines starting with `M').
  194.  
  195.         As an example, the sendmail.cf file should look similar to the
  196.         following which is for a Solaris 2.5.1 system running sendmail
  197.         version 8.8.4:
  198.  
  199. Mlocal,    P=/usr/lib/mail.local, F=lsDFMAw5:/|@qSnE, S=10/30, R=20/40,
  200.            T=DNS/RFC822/X-Unix,
  201.            A=mail -d $u
  202. Mprog,     P=/usr/local/bin/smrsh, F=lsDFMoqeu, S=10/30, R=20/40,
  203.            D=$z:/,
  204.            T=X-Unix,
  205. !          A=smrsh -c $u
  206.  
  207.         This can be achieved for the "Mlocal" and "Mprog" Mailers by modifying
  208.         the ".mc" file to include the following lines:
  209.  
  210.                 OSTYPE(solaris2)
  211.                 FEATURE(smrsh, /usr/local/bin/smrsh)
  212. +               define(`LOCAL_SHELL_ARGS', `smrsh -c $u')
  213.                 define(`LOCAL_MAILER_PATH', /usr/lib/mail.local)
  214.                 define(`LOCAL_MAILER_FLAGS',
  215.                         ifdef(`LOCAL_MAILER_FLAGS',
  216.                                 `translit(LOCAL_MAILER_FLAGS, `9')',
  217.                                 `rmn'))
  218.                 define(`LOCAL_SHELL_FLAGS',
  219.                         ifdef(`LOCAL_SHELL_FLAGS',
  220.                                 `translit(LOCAL_SHELL_FLAGS, `9')',
  221.                                 `eu'))
  222.  
  223.         Next, rebuild the sendmail.cf file using m4(1). See also Section III.D
  224.         for additional precautions that you should take. These precautions
  225.         have been taken in the example above.
  226.  
  227.         The defines of LOCAL_MAILER_FLAGS and LOCAL_SHELL_FLAGS should be
  228.         placed in your m4(1) input file *after* the operating system is
  229.         identified using the OSTYPE directive, and after any other defines of
  230.         either the LOCAL_MAILER_FLAGS or LOCAL_SHELL_FLAGS.
  231.  
  232.         It is possible to directly edit the sendmail.cf file to resolve this
  233.         vulnerability. However, take caution to ensure that the sendmail.cf
  234.         file is not replaced in the future with a new version rebuilt from
  235.         configuration files that include the `9' flag.
  236.  
  237.         Once the configuration file has been modified, all running versions
  238.         of sendmail should be killed and the sendmail daemon restarted with
  239.         the following (done as root):
  240.  
  241.                 # kill -1 `head -1 /var/run/sendmail.pid`
  242.  
  243.         The pathname may be different on your system. Verify that a new
  244.         daemon was started using "(echo quit; sleep 1) | telnet localhost 25".
  245.         Alternatively, reboot your system.
  246.  
  247.     D.  Take additional precautions
  248.  
  249.         Regardless of which solution you apply, you should take these extra
  250.         precautions to protect your systems. These precautions do not address
  251.         the vulnerabilities described herein, but are recommended as good
  252.         practices to follow for the safer operation of sendmail.
  253.  
  254.         * Use the sendmail restricted shell program (smrsh)
  255.  
  256.            With *all* versions of sendmail, use the sendmail restricted
  257.            shell program (smrsh). You should do this whether you use
  258.            vendor-supplied sendmail or install sendmail yourself. Using
  259.            smrsh gives you improved administrative control over the programs
  260.            sendmail executes on behalf of users.
  261.  
  262.            Many sites have reported some confusion about the need to continue
  263.            using the sendmail restricted shell program (smrsh) when they
  264.            install a vendor patch or upgrade to a new version of sendmail. You
  265.            should always use the smrsh program.
  266.  
  267.            smrsh is included in the sendmail Version 8 distribution in the
  268.            subdirectory smrsh. See the RELEASE_NOTES file for a description
  269.            of how to integrate smrsh into your sendmail configuration file.
  270.  
  271.            smrsh is also distributed with some operating systems.
  272.  
  273.            If you are using the m4(1)-based configuration scheme provided
  274.            with sendmail 8.X, add the following to your configuration file,
  275.            where /usr/local/bin is replaced by the name of the directory
  276.            where you have installed smrsh on your system:
  277.  
  278.              FEATURE(smrsh, /usr/local/bin/smrsh)
  279.  
  280.         * Use mail.local
  281.  
  282.           If you run /bin/mail based on BSD 4.3 UNIX, replace /bin/mail with
  283.           mail.local, which is included in the sendmail distribution. As of
  284.           Solaris 2.5 and beyond, mail.local is included with the standard
  285.           distribution. It is also included with some other operating systems
  286.           distributions, such as FreeBSD.
  287.  
  288.           Although the current version of mail.local is not a perfect
  289.           solution, it is important to use it because it addresses
  290.           vulnerabilities that are being exploited. For more details, see
  291.           CERT advisory CA-95:02:
  292.  
  293.   ftp://info.cert.org/pub/cert_advisories/CA-95:02.binmail.vulnerabilities
  294.  
  295.           To use mail.local, replace all references to /bin/mail with
  296.           /usr/lib/mail.local. If you are using the M4(1)-based configuration
  297.           scheme provided with sendmail 8.X, add the following to your
  298.           configuration file:
  299.  
  300.              define(`LOCAL_MAILER_PATH', /usr/lib/mail.local)
  301.  
  302.         * WARNING: Check for setuid executable copies of old versions of
  303.                    mail programs
  304.  
  305.           If you leave setuid executable copies of older versions of
  306.           sendmail installed in /usr/lib (on some systems it may be
  307.           installed elsewhere), the vulnerabilities in those versions could
  308.           be exploited if an intruder gains access to your system. This
  309.           applies to sendmail.mx as well as other sendmail programs. Either
  310.           delete these versions or change the protections on them to be
  311.           non-executable.
  312.  
  313.           Similarly, if you replace /bin/mail with mail.local, remember to
  314.           remove old copies of /bin/mail or make them non-executable.
  315.  
  316. ...........................................................................
  317.  
  318. Appendix A - Vendor Information
  319.  
  320. Below is a list of the vendors who have provided information for this
  321. advisory. We will update this appendix as we receive additional information.
  322. If you do not see your vendor's name, please contact the vendor directly.
  323.  
  324.  
  325. Berkeley Software Design, Inc. (BSDI)
  326. =====================================
  327.    Fully patched BSD/OS 2.1 systems are vulnerable to this problem. An
  328.    official patch is available from the patches server at <patches@BSDI.COM>
  329.    or via anonymous ftp from:
  330.  
  331.                 ftp://ftp.bsdi.com/bsdi/patches/patches-2.1/U210-036
  332.  
  333.  
  334. Caldera OpenLinux
  335. =================
  336.    An upgrade for Caldera OpenLinux Base 1.0 can be found at:
  337.  
  338.          ftp://ftp.caldera.com/pub/col-1.0/updates/Helsinki/003/RPMS/sendmail-8.8.5-1.i386.rpm
  339.  
  340.    See also the README at:
  341.  
  342.           ftp://ftp.caldera.com/pub/col-1.0/updates/Helsinki/003/README
  343.  
  344.  
  345. Cray Research - A Silicon Graphics Company
  346. ==========================================
  347.    Cray Research has not yet released a sendmail based on a version 8.8.3 or
  348.    later, so this is not a problem for any released Unicos system.
  349.  
  350.  
  351. Data General Corporation
  352. ========================
  353.    The sendmail that ships with DG/UX is not subject to this vulnerability.
  354.  
  355.  
  356. Digital Equipment Corporation
  357. =============================
  358.    This reported problem is not present for Digital's ULTRIX or
  359.    Digital UNIX Operating Systems Software.
  360.  
  361.    SOURCE:
  362.         Digital Equipment Corporation
  363.         Software Security Response Team
  364.         Copyright (c) Digital Equipment Corporation 1997. All rights reserved.
  365.         27/1/97 - DIGITAL EQUIPMENT CORPORATION
  366.  
  367.  
  368. Hewlett-Packard Corporation
  369. ===========================
  370.    After an investigation based on the information contained in the CERT
  371.    bulletin, we have come to the conclusion that none of the current versions
  372.    of HP sendmail (HPUX 9.x, HPUX pre-10.2, HPUX 10.2) are vulnerable to the
  373.    security hole mentioned in the bulletin.
  374.  
  375.  
  376. IBM Corporation
  377. ===============
  378.    The version of sendmail shipped with AIX is not vulnerable to the 7
  379.    to 8 bit MIME conversion vulnerability detailed in this advisory.
  380.  
  381.    IBM and AIX are registered trademarks of International Business Machines
  382.    Corporation.
  383.  
  384.  
  385. NEC Corporation
  386. ===============
  387.    
  388. Systems below are not shipped with a sendmail based on
  389. a version 8.8.3 or later, so this problem is not present
  390. for them.
  391.  
  392.    UX/4800              Not vulnerable for all versions.
  393.    EWS-UX/V(Rel4.2MP)   Not vulnerable for all versions.
  394.    EWS-UX/V(Rel4.2)     Not vulnerable for all versions.
  395.    UP-UX/V(Rel4.2MP)    Not vulnerable for all versions.
  396.    EWS-UX/V(Rel4.0)     Not vulnerable for all versions.
  397.    UP-UX/V              Not vulnerable for all versions.
  398.  
  399.  
  400. NeXT Software, Inc.
  401. ===================
  402.    NeXT is not vulnerable to the MIME-buffer overflow attack.
  403.  
  404.  
  405. Silicon Graphics, Inc.
  406. ======================
  407.    The versions of sendmail provided in the distributed Silicon Graphics IRIX
  408.    operating system versions 5.2, 5.3, 6.0, 6.0.1, 6.1, 6.2 and 6.3 (and in
  409.    SGI patch 1502, which is the latest released patch for sendmail) are
  410.    8.6.x versions of the sendmail program. The latest official released
  411.    version of sendmail from Silicon Graphics is 8.6.12. As such, Silicon
  412.    Graphics finds no current version of Silicon Graphics sendmail to be
  413.    vulnerable to this 8.8.x based attack.
  414.  
  415.  
  416. Sun Microsystems, Inc.
  417. ======================
  418.    Sun is confident that no Sun sendmail is vulnerable to the MIME-buffer
  419.    overflow attack.
  420.  
  421. - -----------------------------------------------------------------------------
  422. The CERT Coordination Center thanks Eric Allman for his help in developing
  423. the patches for sendmail and in the writing of this advisory. Thanks also
  424. to DFN-CERT and AUSCERT for their assistance in producing this document.
  425. - -----------------------------------------------------------------------------
  426.  
  427. If you believe that your system has been compromised, contact the CERT
  428. Coordination Center or your representative in the Forum of Incident Response
  429. and Security Teams (see ftp://info.cert.org/pub/FIRST/first-contacts).
  430.  
  431.  
  432. CERT/CC Contact Information
  433. - ----------------------------
  434. Email    cert@cert.org
  435.  
  436. Phone    +1 412-268-7090 (24-hour hotline)
  437.                 CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4)
  438.                 and are on call for emergencies during other hours.
  439.  
  440. Fax      +1 412-268-6989
  441.  
  442. Postal address
  443.          CERT Coordination Center
  444.          Software Engineering Institute
  445.          Carnegie Mellon University
  446.          Pittsburgh PA 15213-3890
  447.          USA
  448.  
  449. Using encryption
  450.    We strongly urge you to encrypt sensitive information sent by email. We can
  451.    support a shared DES key or PGP. Contact the CERT/CC for more information.
  452.    Location of CERT PGP key
  453.          ftp://info.cert.org/pub/CERT_PGP.key
  454.  
  455. Getting security information
  456.    CERT publications and other security information are available from
  457.         http://www.cert.org/
  458.         ftp://info.cert.org/pub/
  459.  
  460.    CERT advisories and bulletins are also posted on the USENET newsgroup
  461.         comp.security.announce
  462.  
  463.    To be added to our mailing list for advisories and bulletins, send your
  464.    email address to
  465.         cert-advisory-request@cert.org
  466.  
  467. - ---------------------------------------------------------------------------
  468. Copyright 1997 Carnegie Mellon University
  469. This material may be reproduced and distributed without permission provided
  470. it is used for noncommercial purposes and the copyright statement is
  471. included.
  472.  
  473. CERT is a service mark of Carnegie Mellon University.
  474. - ---------------------------------------------------------------------------
  475.  
  476. This file: ftp://info.cert.org/pub/cert_advisories/CA-97.05.sendmail
  477.            http://www.cert.org
  478.                click on "CERT Advisories"
  479.  
  480.  
  481. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  482. Revision history
  483.  
  484. Mar. 05, 1997  Appendix A, updated NEC entry.
  485. Feb. 11, 1997  Sec. III. C, example sendmail.cf file - one line changed and one
  486.                added (changes marked at the left margin)
  487.  
  488. -----BEGIN PGP SIGNATURE-----
  489. Version: 2.6.2
  490.  
  491. iQCVAwUBMx1+2XVP+x0t4w7BAQE1IAP9FC8u/Q+DXKTA6zilarwYgywj5s3dVDC+
  492. diM8EcKpz2zi+HuzCklanbfSYibh4Y8gsP37GrTYek4xg/cvnaEx2eFeGbA+kSih
  493. T56uJ79AiNRdu/pWELFeFXl1oo6Y7XrA6Dsf3RYhEUuEQA1fBE6gkmhFW5u06GGR
  494. TyHm+Yb9F2c=
  495. =EYcf
  496. -----END PGP SIGNATURE-----
  497.  
  498.