NEW FLAW in IE6 SP2: Remote overflow in mshtml.dll

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

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/
 
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/
Click to expand...

Interesting that it shuts down IE on my XP machine but Avant, an IE shell,
my default browser seems unbothered.
 
Back
Top