RE: [Full-disclosure] 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@xxxxxxxxxxxxxxxxx
[mailto:full-disclosure-bounces@xxxxxxxxxxxxxxxxx] On Behalf Of Ben Lambrey
Sent: Sunday, April 23, 2006 12:17 PM
To: full-disclosure@xxxxxxxxxxxxxxxxx
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


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