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" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > 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: [EMAIL PROTECTED] > > 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 [EMAIL PROTECTED] 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 > _______________________________________________ TriLUG mailing list http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ: http://www.trilug.org/~lovelace/faq/TriLUG-faq.html
