full-disclosure - RE: BAD NEWS: Microsoft Security Bulletin MS03-032

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: RE: BAD NEWS: Microsoft Security Bulletin
 MS03-032

ADBecker@...ortgage.com replied to GreyMagic to "http-equiv":

> > >The patch for Drew's object data=funky.hta doesn't work:
> > This is the exact same issue as http://greymagic.com/adv/gm001-ie/,
> > which explains the problem in detail. Microsoft again patches the object
> > element in HTML, but it doesn't patch the dynamic version of that same
> > element.
> > 
> > >1. Disable Active Scripting
> > 
> > This actually means that no scripting is needed at all in order to
> > exploit this amazingly critical vulnerability:
> > 
> > <span datasrc="#oExec" datafld="exploit" dataformatas="html"></span>
> > <xml id="oExec">
> >     <security>
> >         <exploit>
> >             <![CDATA[
> >             <object data=x.asp></object>
> >             ]]>
> >         </exploit>
> >     </security>
> > </xml>
> > 
> > Ouch.
> 
> Updated antivirus software should catch this exploit and prevent any
> application from being launched.  ...

Really?

I was not aware that most (or any) typically deployed AV s/w  
interdicts itself between the web browser and browsed sites.  To 
reliably detect Object Data Tag exploits that would be necessary, as 
exploiting this vulnerability depends on "properly formed" HTML 
requesting a remote resource that is then provided with an "unexpected" 
type (as indicated in the HTTP protocol reply headers).  It is this 
mismatch of the types that is the problem as the initial (HTML) parser 
has already decided (based on the apparent filename of the resource) 
that the type is "safe" to execute but there is no secondary check that 
the type returned by the server actually matches the expected type.

If your scanner is detecting anything, the odds are extremely high that 
it will be the code of a specific exploit, rather than generic exploit 
code as there really is no such thing in this case.

> ...  We have McAfee VirusScan 7 Ent. which
> caught both exploit examples at http://greymagic.com/adv/gm001-ie/

Hmmmmmm -- if what you meant was simply that your scanner detects both 
of the exploits linked from GreyMagic's page, I suspect that you have 
too much blind faith in your scanner.  When GreyMagic said "This is the 
exact same issue as ..." he did not mean that it is the same exploit.  
He did not even mean that the same exploit mechanism was at work.  That 
means scanners that detect his PoC exploits will not (with the same 
detection code) detect exploits of this new problem.  What he meant was 
that the exact same slothful and incomplete analysis of the problem by 
Microsoft as led to his exposure of flaws in a previous IE patch are at 
work in producing the exact same kind of flawed patch here.

...

Further, _if_ your virus scanner detects the PoC exploits http-equiv 
has posted, don't sit back content in the "knowledge" that your scanner 
will save you from the next "in the wild" exploit of this vulnerability 
to fly past your Email scanners.  In such cases the odds are 
exceptionally high that your scanner is _not_ detecting an attempt to 
exploit the vulnerability but is simply detecting the "decode, drop and 
execute an EXE file from an HTML-embedded script" code from the script 
that runs as a result of the vulnerability already having been 
exploited.  Whilst it is true that many skiddies and some spammers are 
far too untalented to come up with new encoding/decoding schemes that 
will "slip past" most virus scanners (until their next updates add 
detection of each new, specific method), not all those who would use 
exploits of MS03-032 against you are that lame.  You would be much 
better off to, as Drew Copley posted earlier today to Bugtraq and some 
other lists, implement blocking of anything supplied as application/hta 
type at a firewall or web proxy, or locally on every Windows client by 
butchering the application/hta settings under:

   HKEY_LOCAL_MACHINE\SOFTWARE\Classes\MIME\Database\Content Type 

Drew's message is archived at the following for those wishing to read 
it in its entirety:

   http://www.securityfocus.com/archive/1/336625

-- 
Nick FitzGerald
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3529854