Kazennov, Vladimir wrote:
>>-----Original Message-----
>>From: Michal Zalewski [mailto:lcamtuf@xxxxxxxxxxxx]
>>Sent: Thursday, March 16, 2006 10:23 PM
>>To: bugtraq@xxxxxxxxxxxxxxxxx
>>Cc: vulnwatch@xxxxxxxxxxxxx; full-disclosure@xxxxxxxxxxxxxxxxx
>>Subject: Remote overflow in MSIE script action handlers (mshtml.dll)
>>
>>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 (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.
>>
>>
ðÏÐÒÏÂÏ×ÁÌ IE 6.0.2800.1106 SP1 ÎÁ Win2k AS SP4. îÅ ÐÁÄÁÅÔ.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060205
Debian/1.7.12-1.1 ÔÏÖÅ ÎÅ ÐÁÄÁÅÔ.
MSIE 6.0.2900.2180.xpsp2.040806-1825 ÎÁ XP SP2 ÄÅÊÓÔ×ÉÔÅÌØÎÏ ÐÁÄÁÅÔ.
>>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
>>
>>
>>
--
Alexander Dilevsky
mailto:dil@xxxxxx
