Thread-topic: [VulnWatch] MSIE (mshtml.dll) OBJECT tag vulnerability
> -----Original Message-----
> From: Michal Zalewski [mailto:lcamtuf@xxxxxxxxxxxx]
> Sent: Sunday, April 23, 2006 3:30 AM
> To: bugtraq@xxxxxxxxxxxxxxxxx; vulnwatch@xxxxxxxxxxxxx;
> full-disclosure@xxxxxxxxxxxxxxxxx
> Subject: [VulnWatch] 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):
>
> (eax=0x0, instant
> dereference)
> (bogus esi on reload/leave)
> (page fault on
> browser close)
> (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.
>
