Message-ID: <010501c66736$ca944f50$6600a8c0@OEMCOMPUTER>
Date: Mon Apr 24 01:34:12 2006
From: pvnick at gmail.com (Paul Nickerson)
Subject: MSIE (mshtml.dll) OBJECT tag vulnerability

Confirmed on IE 7 beta 2 on Windows XP SP2

For the record, I don't approve of your disclosure practices, Mr. Zalewski,
but good work none-the-less.

Paul

-----Original Message-----
From: full-disclosure-bounces@...ts.grok.org.uk
[mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf Of Ben Lambrey
Sent: Sunday, April 23, 2006 12:17 PM
To: full-disclosure@...ts.grok.org.uk
Subject: Re: [Full-disclosure] MSIE (mshtml.dll) OBJECT tag vulnerability

On Sunday 23 April 2006 01:30, Michal Zalewski wrote:
> 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.

IE 6 on Windows 2003+SP1 also crashes.

IE version: 6.0.3790.1830
mshtml.dll version 6.0.3790.2666

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.5/322 - Release Date: 4/22/2006
 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.5/322 - Release Date: 4/22/2006
 

Powered by blists - more mailing lists