full-disclosure - MSIE (mshtml.dll) OBJECT tag vulnerability

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-next>] [day] [month] [year] [list]

Date: Mon Apr 24 22:18:21 2006
From: ipatches at hushmail.com (ipatches@...hmail.com)
Subject: MSIE (mshtml.dll) OBJECT tag vulnerability

> Perhaps not surprisingly, there appears to be a vulnerability in 
how
> Microsoft Internet Explorer handles (or fails to handle) certain
> combinations of nested OBJECT tags. This was tested with MSIE
> 6.0.2900.2180.xpsp.040806-1825 and mshtml.dll 6.00.2900.2873
> xpsp_sp2_gdr.060322-1613.
> 
> At first sight, this vulnerability may offer a remote compromise 
vector,
> although not necessarily a reliable one. The error is convoluted 
and
> difficult to debug in absence of sources; as such, I cannot offer 
a
> definitive attack scenario, nor rule out that my initial 
diagnosis will be
> proved wrong [*]. As such, panic, but only slightly.
> 
> Probably the easiest way to trigger the problem is as follows:
> 
>   perl -e '{print "<STYLE></STYLE>\n<OBJECT>\nBork\n"x32}' 
>test.html
> 
> ...this will (usually) cause a NULL pointer + fixed offset 
(eax+0x28)
> dereference in mshtml.dll, the pointer being read from allocated 
but still
> zeroed memory region.
> 
> The aforementioned condition is not exploitable, but padding the 
page with
> preceeding OBJECT tag (and other tags), increasing the number of 
nested
> OBJECTs, and most importantly, adding bogus 'type=' parameters of 
various
> length to the final sequence of OBJECTs, will cause that 
dereference to
> become non-NULL on many installations; then, a range of other 
interesting
> faults should ensue, including dereferences of variable bogus 
addresses
> close to stack, or crashes later on, when the page is reloaded or 
closed.
> 
> [ In absence of sources, I do not understand the precise 
underlying
>   mechanics of the bug, and I am not inclined to spend hours with 
a
>   debugger to find out. I'm simply judging by the symptoms, but 
these
>   seem to be indicative of an exploitable flaw. ]
> 
> Several examples of pages that cause distinct faults in my setup 
(your
> mileage may and probably WILL vary; on three test machines, this 
worked as
> described; on one, all examples behaved in non-exploitable 0x28 
way):
> 
>   http://lcamtuf.coredump.cx/iedie2-1.html (eax=0x0, instant 
dereference)
>   http://lcamtuf.coredump.cx/iedie2-2.html (bogus esi on 
reload/leave)
>   http://lcamtuf.coredump.cx/iedie2-3.html (page fault on browser 
close)
>   http://lcamtuf.coredump.cx/iedie2-4.html (bogus esi on 
reload/leave)
> 
> Well, that's it. Feel free to research this further. This 
vulnerability,
> as requested by customers, is released in strict observance of 
the Patch
> Wednesday & Bug Saturday policy.
> 
> [*] The ability of the attacker to document the attack scenario 
probably
>     doesn't matter for those who pretend to care; cryptic "hi" to
>     Secunia and their standards of conduct.
Sir, You work very well! I think you must also pester Microsoft. I 
also remember LSD pesters Microsoft and they were rapidly sold out.



Concerned about your privacy? Instantly send FREE secure email, no account required
http://www.hushmail.com/send?l=480

Get the best prices on SSL certificates from Hushmail
https://www.hushssl.com?l=485