IE最新发现的漏洞-MSIE (mshtml.dll) OBJECT tag vulnerability

王朝html/css/js·作者佚名  2006-04-26
窄屏简体版  字體: |||超大  

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.

======================

Remote overflow in MSIE script action handlers (mshtml.dll)

This message: [ Message body ] [ More options ]

Related messages: [ Next message ] [ Previous message ] [ Next in thread ] [ Replies ]

From: Michal Zalewski <lcamtuf_at_dione.ids.pl>

Date: Thu, 16 Mar 2006 20:22:55 +0100 (CET)

Good morning,

This might not come as a surprise, but there appears to be a *very*

interesting and apparently very much exploitable overflow in Microsoft

Internet Explorer (mshtml.dll).

This vulnerability can be triggered by specifying more than a couple

thousand script action handlers (such as onLoad, onMouseMove, etc) for any

single HTML tag. Due to a programming error, MSIE will then attempt to

write memory array out of bounds, at an offset corresponding to the ID of

the script action handler multiplied by 4 (due to 32-bit address clipping,

the result is a small positive integer).

The list of IDs can be found on the Web, and is as follows (values in

parentheses = resulting offsets):

onhelp = 0x8001177d (+0x45df4)

onclick = 0x80011778 (+0x45de0)

ondblclick = 0x80011779 (+0x45de4)

onkeyup = 0x80011776 (+0x45dd8)

onkeydown = 0x80011775 (+0x45dd4)

onkeypress = 0x80011777 (+0x45ddc)

onmouseup = 0x80011773 (+0x45dcc)

onmousedown = 0x80011772 (+0x45dc8)

onmousemove = 0x80011774 (+0x45dd0)

onmouseout = 0x80011771 (+0x45dc4)

onmouseover = 0x80011770 (+0x45dc0)

onreadystatechange = 0x80011789 (+0x45e24)

onafterupdate = 0x80011786 (+0x45e18)

onrowexit = 0x80011782 (+0x45e08)

onrowenter = 0x80011783 (+0x45e0c)

ondragstart = 0x80011793 (+0x45e4c)

onselectstart = 0x80011795 (+0x45e54)

What happens next depends on the structure of the page in which the

malicious tag is embedded, as well as previously visited page and

previously initialized extensions (all these factors can be controlled by

the attacker).

When the offending page contains no additional elements, and the user is

not redirected from elsewhere, the browser will typically crash

immediately, because there is no allocated memory at the resulting offset.

In all other cases, crashes will typically occur later, due to attempted

use of unrelated but corrupted in-memory buffers -for example, when the

user attempts to leave or reload the page. Another good example is coming

from a page that contains Macromedia Flash - this usually causes the Flash

plugin itself to choke on corrupted memory on cleanup.

For non-believers, there's a short but fiery demonstration page available

at http://lcamtuf.coredump.cx/iedie.html (yes, it will probably crash your

browser).

Tested on MSIE 6.0.2900.2180.xpsp2.040806-1825 on Windows XP SP2. As far

as I can tell, other browser makes (Firefox, Opera) are not susceptible to

this attack.

I eagerly await due reprimend from Microsoft for not disclosing this

vulnerability in a manner that benefits them most, not passing start, not

collecting $200 (from iDefense?).

Regards,

/mz

http://lcamtuf.coredump.cx/silence/

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
 
 
© 2005- 王朝網路 版權所有 導航