- NZNOG - lists.nznog.org

CCIP EXTERNAL ADVISORY REDISTRIBUTION: Remote Sendmail HeaderProcessing Vulnerability
by Andrew Evans 03 Mar '03

03 Mar '03

A little heads up for those running sendmail. Information on the vulnerability was released at around 6:30am NZT. Note that this vulnerability is message oriented, i.e. an exploit can be contained in the body of an email message. CCIP EXTERNAL ADVISORY REDISTRIBUTION ---------------- Start of External Reference --------------- CERT® Advisory CA-2003-07 Remote Buffer Overflow in Sendmail Original release date: March 3, 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.5 * Sendmail Switch 2.2 prior to 2.2.5 * Sendmail Switch 3.0 prior to 3.0.3 * Sendmail for NT 2.X prior to 2.6.2 * Sendmail for NT 3.0 prior to 3.0.3 * Systems running open-source sendmail versions prior to 8.12.8, including UNIX and Linux systems Overview There is a vulnerability in sendmail that may allow remote attackers to gain the privileges of the sendmail daemon, typically root. I. Description Researchers at Internet Security Systems (ISS) have discovered a remotely exploitable vulnerability in sendmail. This vulnerability could allow an intruder to gain control of a vulnerable sendmail server. 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. Sendmail has indicated to the CERT/CC that this vulnerability has been successfully exploited in a laboratory environment. We do not believe that this exploit is available to the public. However, this vulnerability is likely to draw significant attention from the intruder community, so the probability of a public exploit is high. A successful attack against an unpatched sendmail system will not leave any messages in the system log. However, on a patched system, an attempt to exploit this vulnerability will leave the following log message: Dropped invalid comments from header address Although this does not represent conclusive evidence of an attack, it may be useful as an indicator. A patched sendmail server will drop invalid headers, thus preventing downstream servers from receiving them. The CERT/CC is tracking this issue as VU#398025. This reference number corresponds to CVE candidate CAN-2002-1337. For more information, please see http://www.sendmail.org http://www.sendmail.org/8.12.8.html http://www.sendmail.com/security/ http://www.iss.net/issEn/delivery/xforce/alertdetail.jsp?oid=21950 http://www.kb.cert.org/vuls/id/398025 II. Impact Successful exploitation of this vulnerability may 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 from the contents of a malicious email message. III. Solution Apply a patch from Sendmail 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.8. These patches are located at ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.12.security.cr.patch ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.11.6.security.cr.patch ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.9.3.security.cr.patch 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 their responses in the systems affected section of VU#398025. Several vendors have provided a statement for direct inclusion in this advisory; these statements are available in Appendix A. 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. Apple Computer, Inc. Security Update 2003-03-03 is available to fix this issue. Packages are available for Mac OS X 10.1.5 and Mac OS X 10.2.4. It should be noted that sendmail is not enabled by default on Mac OS X, so only those systems which have explicitly enabled it are susceptible to the vulnerability. All customers of Mac OS X, however, are encouraged to apply this update to their systems. Avaya, Inc. Avaya is aware of the vulnerability and is investigating impact. As new information is available this statement will be updated. BSD/OS Wind River Systems has created patches for this problem which are available from the normal locations for each release. The relevant patches are M500-006 for BSD/OS version 5.0 or the Wind River Platform for Server Appliances 1.0, M431-002 for BSD/OS 4.3.1, or M420-032 for BSD/OS 4.2 systems. Cisco Systems Cisco is investigating this issue. If we determine any of our products are vulnerable that information will be available at: http://www.cisco.com/go/psirt Cray Inc. The code supplied by Cray, Inc. in Unicos, Unicos/mk, and Unicos/mp may be vulnerable. Cray has opened SPRs 724749 and 724750 to investigate. Cray, Inc. is not vulnerable for the MTA systems. Hewlett-Packard Company SOURCE: Hewlett-Packard Company HP Services Software Security Response Team x-ref: SSRT3469 sendmail HP will provide notice of the availability of patches through standard security bulletin announcements and be available from your normal HP Services support channel. IBM Corporation The AIX operating system is vulnerable to the sendmail issues discussed in releases 4.3.3, 5.1.0 and 5.2.0. A temporary patch is available through an efix package which can be found at ftp://ftp.software.ibm.com/aix/efixes/security/sendmail_efix.tar.Z IBM will provide the following official fixes: APAR number for AIX 4.3.3: IY40500 (available approx. 03/12/2003) APAR number for AIX 5.1.0: IY40501 (available approx. 04/28/2003) APAR number for AIX 5.2.0: IY40502 (available approx. 04/28/2003) Openwall GNU/*/Linux Openwall GNU/*/Linux is not vulnerable. We use Postfix as the MTA, not sendmail. Red Hat Inc. Updated sendmail packages that are not vulnerable to this issue are available for Red Hat Linux, Red Hat Advanced Server, and Red Hat Advanced Workstation. Red Hat Network users can update their systems using the 'up2date' tool. Red Hat Linux: http://rhn.redhat.com/errata/RHSA-2003-073.html Red Hat Linux Advanced Server, Advanced Workstation: http://rhn.redhat.com/errata/RHSA-2003-074.html SGI SGI acknowledges VU#398025 reported by CERT and has released an advisory to address the vulnerability on IRIX. Refer to SGI Security Advisory 20030301-01-P available from ftp://patches.sgi.com/support/free/security/advisories/20030301-01-P or http://www.sgi.com/support/security/. The Sendmail Consortium The Sendmail Consortium suggests that sites upgrade to 8.12.8 if 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 Internet Security Systems, Inc. for discovering this problem, and to Eric Allman, Claus Assmann, and Greg Shapiro of Sendmail for notifying us of this problem. We thank both groups for their assistance in coordinating the response to this problem. Authors: Jeffrey P. Lanza and Shawn V. Hernan This document is available from: http://www.cert.org/advisories/CA-2003-07.html CERT/CC Contact Information Email: cert(a)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(a)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 Mar 03, 2003: Initial release ---------------- End of External Reference --------------- CCIP only issues those external alerts that we assess as serious and would affect a large number of NZ users. For notification of all discovered software vulnerabilities we recommend that you subscribe to a commercial Computer Emergency Response Team or to vendor alert lists. The CCIP also maintains a list of the more recent mainstream alerts and advisories at: http://www.ccip.govt.nz/alerts-advisories/alerts-advisories.htm While this advisory is accurate to the best of our knowledge, CCIP does not accept any responsibility for errors or omissions. If the vulnerability affects you, you are advised to ensure that you have the most current information available. CCIP will not be liable for any loss or damage howsoever caused, arising from or in connection with the use of information contained in this advisory. Reference in this advisory in any manner to any commercial product, process or service does not constitute or imply its endorsement or recommendation by CCIP. Views and opinions expressed herein may not be used for advertising or product endorsement purposes. Please refer to the CCIP web site (www.ccip.govt.nz) for a complete list of recent alerts and advisories. Issued by: Watch Centre, Centre for Critical Infrastructure Protection, P O Box 12-209, Wellington. Internet: www.ccip.govt.nz E-mail: alerts(a)ccip.govt.nz Tel: +64 4 498 7654 Fax: +64 4 498 7655

1 0

RBL's used
by Craig Whitmore 28 Feb '03

28 Feb '03

As the amount of spam grows as the internet grows bigger, using RBL's is growing as well (to try and stop/slow the spam). I am wondering what RBL's other ISP's/Companies in NZ Use? There are quite a number (of RBL's) but a few can't be used as they still have Xtra's Network in them (for "Sueing ORBS" they say), but the best I've found so far has been http://relays.osirusoft.com. Can anyone suggest a better one/comments/pitfalls on using RBL's for slowing down spam. Thanks Craig Whitmore Orcon Internet http://www.nzdsl.co.nz

16 27

Re: [nznog] RBL's used
by Michael Newbery 27 Feb '03

27 Feb '03

At 5:24 PM -0800 27/2/03, Chris Wedgwood wrote: >On Fri, Feb 28, 2003 at 11:27:06AM +1300, Russell Fulton wrote: > >> This isn't really feasible since the whole point of the RBL is that >> you dump the session before it sends anything so you don't know who >> its for. > >I *think* barfing (5xx) when you get a connection or on "MAIL FROM" >strictly speaking isn't allowed in the RFC (I've not check rfc2821 so >this may have changed since '821). From RFC 2821 3.1 Session Initiation The SMTP protocol allows a server to formally reject a transaction while still allowing the initial connection as follows: a 554 response MAY be given in the initial connection opening message instead of the 220. I.e. if an RBL'd host connects to you, even before the HELO/EHLO, you can tell them to go away 554 Transaction failed (go away evil spammer) -- Michael Newbery IP Architect TelstraClear Limited

1 0

Persistent spammer 210.24.225.148
by Simon Byrnand 26 Feb '03

26 Feb '03

Anyone else had trouble with a very persistant spammer on adsl148.dyn225.pacific.net.sg [210.24.225.148] or nearby ip addresses belonging to the same ISP lately ? Doing dictionary attacks, and attempting connections at the rate of several hundred per minute, (up to 50 simultaneous connections at once) and still attempting the same connection rate even after being firmly 550'ed.....not funny at all. Had the same thing happen a week ago from another adsl ip address belonging to the same ISP and actually got what seemed like a positive response to abuse@ saying that they had sorted out the problem, only for it to happen again less than a week later from a slightly different ip address. Just paying lip service to abuse emails, or do they have a high percentage of scum like customers I wonder... :) Regards, Simon Byrnand iGRIN Internet

1 0

Heads Up - streaming event thursday
by Richard Naylor 26 Feb '03

26 Feb '03

Heads up There is a streaming event in Wgtn tomorrow, covering a presentation by the CEO of MTV-Europe, Brent Hansen. The stream will start with test pattern and "curtain opener" stuff at around 4:30pm with the main event at 5:30pm until around 8:00pm. Streams will be at 56k, 128k and 384kbps and will be on WIX coming from l1.r2.co.nz (203.118.144.36) While we don't expect the traffic volumes of the LOTR event last year, they have managed to sell some tickets and maybe someone might watch (other than us in the hall). So there appears to be some interest. We also have advanced warning of a LOTR event in mid March. I'll advise as soon as I get told something. rich

1 0

E1 / PRI equipment (Lucent Ascend Max)
by Michael Hallager 22 Feb '03

22 Feb '03

Hello all, Has anyone on the list had experiance with setting up and/or using imported Lucent Ascend Max 4048 56k RAS servers? (E1 version of course). I would like to know what peoples experiences are. I can be contacted at: michael(a)comsolve.net.nz Michael Hallager

1 0

Big increase in 419 spam?
by Juha Saarinen 22 Feb '03

22 Feb '03

Am I just being unlucky, or are others seeing a big surge in 419 spam? Not just from Nigeria (blocked), but from freemail servers all over the place -- Europe, Asia, the US, South America etc. 419 spam accounts for the vast majority of UCE/UBE that I receive now. -- Juha Saarinen

4 3

ENUM
by Philip D'Ath 21 Feb '03

21 Feb '03

I've been doing quite a bit of development in the VoIP word of late, and one project I need to get going is a +64 ENUM reverse delegation for 4.6.e164.arpa. Is anyone on this list working is this area, or have done work in this area? Philip D'Ath IFM Ltd http://www.ifm.net.nz/

1 0

RE: [nznog] Big increase in 419 spam?
by Mike Clark 20 Feb '03

20 Feb '03

for a proactive approach try the nigerian fraud masterclass: http://www.fattibastardo.com/fraud.html -----Original Message----- From: Michael Newbery [mailto:Michael.Newbery(a)team.telstraclear.co.nz] Sent: Friday, 21 February, 2003 12:43 To: NZNOG Subject: Re: [nznog] Big increase in 419 spam? At 12:19 PM +1300 21/2/03, Juha Saarinen wrote: >Am I just being unlucky, or are others seeing a big surge in 419 spam? Someone appears to be working on a filter. http://www.theregister.co.uk/content/6/29410.html -- Michael Newbery IP Architect TelstraClear Limited _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

Re: [nznog] NZNOG 2003 Content
by Jamie Baddeley 19 Feb '03

19 Feb '03

Hi, "..Managing IP Networks with Free Software.." Free as in speech or Free as in Beer? I'd be happy to help out/swap notes with anyone doing "..Managing IP Networks with Open Source Software.." jamie >>> "Donald Neal" <Donald.Neal(a)telecom.co.nz> 02/20 3:58 PM >>> Suggestions I've received for NZNOG 2003 content are summarised below. The first number listed after each topic is the number of expressions of interest I've received, the second is the number of offers to present. NB: One volunteer has heroically made multiple offers to present and can't possibly deliver on all of them. So further feed back on preferences and/or offers to present definitely remain relevant. DNS [1/0] DNS Security [0/1] f-root Server Deployment [0/1] Email [1/0] Measurement New Zealand Network Measurement Infrastructure [1/0] Passive Network Measurement [2/1] New Zealand Next Generation Internet [2/0] The Future of IP Addressing [0/1] Spam [1/0] Spam Filtering at the Provider Level [0/1] Tutorials BGP [0/1] Congestion Mitigation [0/1] Managing IP Networks with Free Software [0/1] Mitigating Network Abuse using BGP [0/1] Real-World Network Operations [0/1] For now I'm seeking content independent of the conference format. I'm hoping we'll be guided in the format by the content. Feedback to me rather than the list, please. - Donald Neal ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you." ------------------------------------------------------------------------------ _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

2 1