[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