[Esa-l] Does anyone know if John's filter catches this?

[Brett Glass]

http://www.malware.com/dropper.html 

Unless I'm reading John's code incorrectly, it doesn't
look for excessively long subject lines.

Note that, according to the attached Bugtraq message, the
subject length only has to exceed 256 characters, which may
be shorter than the limit imposed by the sanitizer.

--Brett

>Approved-By: aleph1 at SECURITYFOCUS.COM
>Delivered-To: bugtraq at lists.securityfocus.com
>Received: from securityfocus.com (mail.securityfocus.com [66.38.151.9]) by
>          lists.securityfocus.com (Postfix) with SMTP id 6892B24CA1E for
>          <bugtraq at lists.securityfocus.com>; Thu,  5 Apr 2001 21:46:13 -0600
>          (MDT)
>Received: (qmail 20413 invoked by alias); 6 Apr 2001 03:46:13 -0000
>Delivered-To: BUGTRAQ at SECURITYFOCUS.COM
>Received: (qmail 20410 invoked from network); 6 Apr 2001 03:46:12 -0000
>Received: from mtiwmhc23.worldnet.att.net (204.127.131.48) by
>          mail.securityfocus.com with SMTP; 6 Apr 2001 03:46:12 -0000
>Received: from officeeagle ([12.44.150.252]) by mtiwmhc23.worldnet.att.net
>          (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id
>          <20010406034607.MNHQ21907.mtiwmhc23.worldnet.att.net at officeeagle> for
>          <BUGTRAQ at SECURITYFOCUS.COM>; Fri, 6 Apr 2001 03:46:07 +0000
>References:  <004701c0bd0b$19071b80$09001aac at LaHabana> 
>             <003401c0bd59$ee7f40f0$606545ab at na.cisco.com>
>MIME-Version: 1.0
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: 7bit
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-Mailer: Microsoft Outlook Express 5.50.4522.1200
>X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
>Message-ID:  <013701c0be4c$1cd22560$220a400a at officeeagle>
>Date:         Thu, 5 Apr 2001 22:35:27 -0500
>Reply-To: Paul Schmehl <pauls at UTDALLAS.EDU>
>Sender: Bugtraq List <BUGTRAQ at SECURITYFOCUS.COM>
>From: Paul Schmehl <pauls at UTDALLAS.EDU>
>Subject:      A subject line buffer overflow in Outlook Express (was Re:
>              EML Content Spoofing and Informed Consent)
>To: BUGTRAQ at SECURITYFOCUS.COM
>X-UIDL: b196b8c7473ff8213a6c77ed6252b2cb
>
>----- Original Message -----
>From: "Dan Kaminsky" <dankamin at CISCO.COM>
>To: <BUGTRAQ at SECURITYFOCUS.COM>
>Sent: Wednesday, April 04, 2001 5:52 PM
>Subject: EML Content Spoofing and Informed Consent (was: Re: MS patch
>Q292108 opens a vulnerability)
>
>[snip]
>>
>> [The short version of this:  If I try to open a MP3 file remotely, and I
>> actually execute a Word Macro Document or even a full fledged install of
>> BackOrifice, I'm the victim of a security hole:  My ruleset for choosing
>> what to download was tricked; the trust I applied to one format(MP3) was
>> used upon another(EXE, DOC).  The rest of this is essentially a quick
>> refresher in security theory for whoever at MS argued that "querying the
>> user, even with a spoofed query, means no security hole.", along with a
>> surprising connection to bioethics.]
>>
>> Good example of why full disclosure is useful--I went ahead and checked
>out
>> the demo myself, and immediately found that Microsoft's argument holds
>> little water.  Essentially, there's a simple rule of browser security that
>> states that explicitly asking the user to authorize a transaction with an
>> informed set of validated security parameters is more secure than simply
>> having a default list of parameters that must be satisfied and
>automatically
>> accepting if that list is accepted.
>
>In the interest of full disclosure, and because Microsoft has given us the
>exact same answer to *this*, a buffer overflow exists in the subject line
>buffer of Outlook Express, versions 5.0.x.x and 5.50.x.x.  This overflow is
>exploitable (in the latter version) with the same EML content spoofing being
>discussed in the previous thread.
>
>One of my techs, Su Wadlow, did some testing after we had problems with
>Outlook Express clients crashing when trying to read a certain VP's email.
>(He likes to send email with excessively long subject lines, such as the
>entire first paragraph of his email message.)
>
>If a subject line with more than 256 characters is constructed, OE will
>overflow and crash (ver 5.0.x.x) or construct an attachment out of the
>message body (OE 5.50.x.x).  (Su read a post in vuln-dev discussing a buffer
>overflow in the news reader of OE, and putting two and two together decided
>that must be what was happening in OE's subject line.  I asked her to do
>some testing, and she found that the buffer could be overflowed
>inconsistently with as few as 161 characters [no determination as to cause
>other than length] and consistently with 256 characters.)
>
>This bug was identified and posted on malware.com's site in January of this
>year.  I don't know of any earlier discussions of it.  Malware.com claims
>this bug exists in Outlook as well, but we have been unable to reproduce
>that.
>
>If you visit the malware.com site (http://www.malware.com/dropper.html), you
>will find some proof of concept exploits that demonstrate how this bug can
>be exploited to run any application you want on the victim's machine by
>"fooling" them with a fake icon.  (This would only work in the later
>versions.  Ver. 5.0.x.x will crash.  We didn't test any older versions such
>as 4.x)
>
>We corresponded with MS Security about this issue, but they will not do
>anything unless we provide them with a proof of concept exploit.  Since we
>aren't in the exploit business (and have many other things to do), I sent a
>copy of all this to Georg Guniski and asked him if he could craft an exploit
>that would convince MS that this is a very real problem, but I haven't heard
>back from him.  I don't know if he is working on it or not.  I don't know if
>the BO in the earlier versions could be exploited, but since one of my many
>responsibilities is anti-virus protection for our campus, the behavior of
>the later versions (5.50.x.x) bothers me a great deal, and I'm very
>disappointed that MS passes it off as a "user education" issue.  Since this
>bug creates an "attachment" that isn't identified by the headers, I wonder
>if virus scanners would even catch anything crafted in this fashion.
>
>I suspect the crashed version could be exploited by someone who understand
>registers and assembly well enough.  A convenient copy of the Dr. Watson log
>will show you exactly where in the stack the overflow occurs.
>
><rant>When are CS departments going to start teaching proper bounds
>checking??????  And when are programmers going to start using it???</rant>
>
>Paul Schmehl pauls at utdallas.edu
>Supervisor, Support Services
>University of Texas at Dallas
>AVIEN Founding Member