full-disclosure - Re: Remote overflow in MSIE script action handlers (mshtml.dll)

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e1e1d5f40603161301t21e9d053ib7ca787858ef6186@mail.gmail.com>
Date: Fri Mar 17 15:40:11 2006
From: thehazard at gmail.com (Daniel Bonekeeper)
Subject: Re: Remote overflow in MSIE script action
	handlers (mshtml.dll)

BTW, tested the POC on MSIE (File Version =
6.00.2900.2180(xpsp_sp2_rtm.040803-2158))
with mshtml.dll (6.00.2900.2802 (xpsp_sp2_gdr.051123-1230)) and it didn't
worked.


On 3/16/06, Michal Zalewski <lcamtuf@...ne.ids.pl> wrote:
>
> 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/
>



--
What this world needs is a good five-dollar plasma weapon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20060316/7bab701f/attachment-0001.html