ADBecker@chmortgage.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
