[TriLUG] Dang! Another Sendmail vulnerability
Jeremy Portzer
jeremyp at pobox.com
Sat Mar 29 23:53:04 EST 2003
Remember that article that Roy Vestal posted a few weeks back? The guy
who claimed to have broken into CERT said he was going to release a
damaging exploit/hole on a Friday night, specifically to cause problems
for administrators on a weekend. I wonder if this is the hole in
question? Anyone have any details on why this came out on a Saturday?
--Jeremy
On Sat, 2003-03-29 at 18:40, Jon Carnes wrote:
> Time to upgrade *again* (or move to Postfix).
>
> Jon
>
> ----- Original Message -----
> From: "CERT Advisory" <cert-advisory at cert.org>
> To: <cert-advisory at cert.org>
> Sent: Saturday, March 29, 2003 2:57 PM
> Subject: CERT Advisory CA-2003-12 Buffer Overflow in Sendmail
>
>
> >
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> >
> > CERT Advisory CA-2003-12 Buffer Overflow in Sendmail
> >
> > Original release date: March 29, 2003
> > Last revised:
> > Source: CERT/CC
> >
> > A complete revision history can be found at the end of this file.
> >
> > Systems Affected
> >
> > * Sendmail Pro (all versions)
> > * Sendmail Switch 2.1 prior to 2.1.6
> > * Sendmail Switch 2.2 prior to 2.2.6
> > * Sendmail Switch 3.0 prior to 3.0.4
> > * Sendmail for NT 2.X prior to 2.6.3
> > * Sendmail for NT 3.0 prior to 3.0.4
> > * Systems running open-source sendmail versions prior to 8.12.9,
> > including UNIX and Linux systems
> >
> > Overview
> >
> > There is a vulnerability in sendmail that can be exploited to cause a
> > denial-of-service condition and could allow a remote attacker to
> > execute arbitrary code with the privileges of the sendmail daemon,
> > typically root.
> >
> > I. Description
> >
> > There is a remotely exploitable vulnerability in sendmail that could
> > allow an attacker to gain control of a vulnerable sendmail server.
> > Address parsing code in sendmail does not adequately check the length
> > of email addresses. An email message with a specially crafted address
> > could trigger a stack overflow. This vulnerability was discovered by
> > Michal Zalewski.
> >
> > This vulnerability is different than the one described in CA-2003-07.
> >
> > Most organizations have a variety of mail transfer agents (MTAs) at
> > various locations within their network, with at least one exposed to
> > the Internet. Since sendmail is the most popular MTA, most
> > medium-sized to large organizations are likely to have at least one
> > vulnerable sendmail server. In addition, many UNIX and Linux
> > workstations provide a sendmail implementation that is enabled and
> > running by default.
> >
> > This vulnerability is message-oriented as opposed to
> > connection-oriented. That means that the vulnerability is triggered by
> > the contents of a specially-crafted email message rather than by
> > lower-level network traffic. This is important because an MTA that
> > does not contain the vulnerability will pass the malicious message
> > along to other MTAs that may be protected at the network level. In
> > other words, vulnerable sendmail servers on the interior of a network
> > are still at risk, even if the site's border MTA uses software other
> > than sendmail. Also, messages capable of exploiting this vulnerability
> > may pass undetected through many common packet filters or firewalls.
> >
> > This vulnerability has been successfully exploited to cause a
> > denial-of-service condition in a laboratory environment. It is
> > possible that this vulnerability could be used to execute code on some
> > vulnerable systems.
> >
> > The CERT/CC is tracking this issue as VU#897604. This reference number
> > corresponds to CVE candidate CAN-2003-0161.
> >
> > For more information, please see
> >
> > http://www.sendmail.org
> > http://www.sendmail.org/8.12.9.html
> > http://www.sendmail.com/security/
> >
> > For the latest information about this vulnerability, including the
> > most recent vendor information, please see
> >
> > http://www.kb.cert.org/vuls/id/897604
> >
> > This vulnerability is distinct from VU#398025.
> >
> > II. Impact
> >
> > Successful exploitation of this vulnerability may cause a
> > denial-of-service condition or allow an attacker to gain the
> > privileges of the sendmail daemon, typically root. Even vulnerable
> > sendmail servers on the interior of a given network may be at risk
> > since the vulnerability is triggered by the contents of a malicious
> > email message.
> >
> > III. Solution
> >
> > Apply a patch from Sendmail, Inc.
> >
> > Sendmail has produced patches for versions 8.9, 8.10, 8.11, and 8.12.
> > However, the vulnerability also exists in earlier versions of the
> > code; therefore, site administrators using an earlier version are
> > encouraged to upgrade to 8.12.9. These patches, and a signature file,
> > are located at
> >
> > ftp://ftp.sendmail.org/pub/sendmail/prescan.tar.gz.uu
> > ftp://ftp.sendmail.org/pub/sendmail/prescan.tar.gz.uu.asc
> >
> > Apply a patch from your vendor
> >
> > Many vendors include vulnerable sendmail servers as part of their
> > software distributions. We have notified vendors of this vulnerability
> > and recorded the statements they provided in Appendix A of this
> > advisory. The most recent vendor information can be found in the
> > systems affected section of VU#897604.
> >
> > Enable the RunAsUser option
> >
> > There is no known workaround for this vulnerability. Until a patch can
> > be applied, you may wish to set the RunAsUser option to reduce the
> > impact of this vulnerability. As a good general practice, the CERT/CC
> > recommends limiting the privileges of an application or service
> > whenever possible.
> >
> > Appendix A. - Vendor Information
> >
> > This appendix contains information provided by vendors for this
> > advisory. As vendors report new information to the CERT/CC, we will
> > update this section and note the changes in our revision history. If a
> > particular vendor is not listed below, we have not received their
> > comments.
> >
> > Red Hat Inc.
> >
> > Red Hat distributes sendmail in all Red Hat Linux distributions. We
> > are currently [Mar29] working on producing errata packages to correct
> > this issue, when complete these will be available along with our
> > advisory at the URL below. At the same time users of the Red Hat
> > Network will be able to update their systems using the 'up2date' tool.
> >
> > Red Hat Linux:
> >
> > http://rhn.redhat.com/errata/RHSA-2003-120.html
> >
> > Red Hat Enterprise Linux:
> >
> > http://rhn.redhat.com/errata/RHSA-2003-121.html
> >
> > The Sendmail Consortium
> >
> > The Sendmail Consortium recommends that sites upgrade to 8.12.9
> > whenever possible. Alternatively, patches are available for 8.9, 8.10,
> > 8.11, and 8.12 on http://www.sendmail.org/.
> >
> > Sendmail, Inc.
> >
> > All commercial releases including Sendmail Switch, Sendmail Advanced
> > Message Server (which includes the Sendmail Switch MTA), Sendmail for
> > NT, and Sendmail Pro are affected by this issue. Patch information is
> > available at http://www.sendmail.com/security/.
> > _________________________________________________________________
> >
> > Our thanks to Eric Allman, Claus Assmann, Greg Shapiro, and Dave
> > Anderson of Sendmail for reporting this problem and for their
> > assistance in coordinating the response to this problem. We also thank
> > Michal Zalewski for discovering this vulnerability.
> > _________________________________________________________________
> >
> > Authors: Art Manion and Shawn V. Hernan
> > ______________________________________________________________________
> >
> > This document is available from:
> > http://www.cert.org/advisories/CA-2003-12.html
> > ______________________________________________________________________
> >
> > CERT/CC Contact Information
> >
> > Email: cert at cert.org
> > Phone: +1 412-268-7090 (24-hour hotline)
> > Fax: +1 412-268-6989
> > Postal address:
> > CERT Coordination Center
> > Software Engineering Institute
> > Carnegie Mellon University
> > Pittsburgh PA 15213-3890
> > U.S.A.
> >
> > CERT/CC personnel answer the hotline 08:00-17:00 EST(GMT-5) /
> > EDT(GMT-4) Monday through Friday; they are on call for emergencies
> > during other hours, on U.S. holidays, and on weekends.
> >
> > Using encryption
> >
> > We strongly urge you to encrypt sensitive information sent by email.
> > Our public PGP key is available from
> > http://www.cert.org/CERT_PGP.key
> >
> > If you prefer to use DES, please call the CERT hotline for more
> > information.
> >
> > Getting security information
> >
> > CERT publications and other security information are available from
> > our web site
> > http://www.cert.org/
> >
> > To subscribe to the CERT mailing list for advisories and bulletins,
> > send email to majordomo at cert.org. Please include in the body of your
> > message
> >
> > subscribe cert-advisory
> >
> > * "CERT" and "CERT Coordination Center" are registered in the U.S.
> > Patent and Trademark Office.
> > ______________________________________________________________________
> >
> > NO WARRANTY
> > Any material furnished by Carnegie Mellon University and the Software
> > Engineering Institute is furnished on an "as is" basis. Carnegie
> > Mellon University makes no warranties of any kind, either expressed or
> > implied as to any matter including, but not limited to, warranty of
> > fitness for a particular purpose or merchantability, exclusivity or
> > results obtained from use of the material. Carnegie Mellon University
> > does not make any warranty of any kind with respect to freedom from
> > patent, trademark, or copyright infringement.
> > _________________________________________________________________
> >
> > Conditions for use, disclaimers, and sponsorship information
> >
> > Copyright 2003 Carnegie Mellon University.
> > Revision History
> >
> > March 29,2003: Initial release
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: PGP 6.5.8
> >
> > iQCVAwUBPoX5XGjtSoHZUTs5AQHvjgQAqTy3GQnszPHtUnUBX7VDM4NKSesFHHvC
> > 2JmDAMPYmCO2b32xvWDmMcWdPhOBmJLB2o6zv7mRWX1K0B1GN5TBErIii6dxTaDD
> > OAUNjirMGdTr+WnxIjdk0gj57JbOU6ZdHHcAijG5SE/dZq4sMrOCGEAMJTVNDzYp
> > BtHbFwDeLEY=
> > =dgBI
> > -----END PGP SIGNATURE-----
> _______________________________________________
> TriLUG mailing list
> http://www.trilug.org/mailman/listinfo/trilug
> TriLUG Organizational FAQ:
> http://www.trilug.org/~lovelace/faq/TriLUG-faq.html
>
More information about the TriLUG
mailing list