So it looks like there's a new IE Vuln floating around the past couple of days. Not much to say about it... other than it's effective.. definately crashes IE... Wonder if anyone will find a way to also have it execute code..
The proof of concept that's out is available from - http://lcamtuf.coredump.cx/iedie.html. One important thing to note that followed the initial email is that this is most effective if run with only a single copy of IE open.
Here is the complete email for your reading pleasure:
----SNIP----
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/
----SNIP----
Peace,
HT
