(The fix and CVE number for this issue are not known)
A specially crafted web-page can trigger a use-after-free vulnerability in
Microsoft Internet Explorer 9. During a method call, the this
object can be
freed and then continues to be used by the code that implements the method.
It appears that there is little to no time for an attacker to attempt to
control the contents of the freed memory before the re-use, which would allow
remote code execution.
Microsoft Internet Explorer 9
An attacker would need to get a target user to open a specially crafted web-page. Disabling JavaScript should prevent an attacker from triggering the vulnerable code path.
By switching the a document's designMode
property to on
in a deferred
script, MSIE 9 can be made to reload a web page using
CMarkup::
. This method calls CDoc::
,
which indirectly calls CScriptCollection::~CScriptCollection
, which releases
the CMarkup
object used as this
in CMarkup::
.
The relevant stack for the freeing of this CMarkup
object is:
76e8c484 kernel32!HeapFree+0x00000014
6780c4d8 MSHTML!CMarkup::`vector deleting destructor'+0x00000026
6776fb9b MSHTML!CScriptCollection::~CScriptCollection+0x00000152
67816a0d MSHTML!CScriptCollection:: Release+0x00000053
6751f7e7 MSHTML!CWindow:: SuperNavigateInternal+0x000004c4
675209f7 MSHTML!CWindow:: SuperNavigate2WithBindFlags+0x00000032
679b05f8 MSHTML!CDoc:: CompatViewRefresh+0x000000a0
679c00d4 MSHTML!CMarkup:: ReloadInCompatView+0x0000021f
Immediately after returning to CMarkup::
, the code will use
the (now freed) CMarkup
object. When page heap is enabled, this lead to an
immediate access violation.
I did not immediately find a way to control the freed memory before the reuse
following the CDoc::
call. I did not immediately find other
locations in the code where the same stale pointer to the CMarkup
object is
used after it has been freed. It may not be possible to exploit this
use-after-free, as there does not appear to be an easy window of opportunity to
modify the freed memory before its reuse.
However, when loading the repro in MSIE with page heap disabled, I do see crashes from time to time, but in different locations in the code. This indicates that one or more of the following should be true:
CMarkup
object before it is reused.CMarkup
object is used after it
has been freed, and the freed CMarkup
object can be modified before this
happens.As these other crash stacks do not include CMarkup::
, it
seems most likely that they are caused by the second or third option, which
could indicate that the bug is in fact exploitable.
This report was generated using a predecessor of BugId, a Python script created to detect, analyze and id application bugs. Don't waste time manually analyzing issues and writing reports but try BugId out yourself today! You'll get even better reports than this one with the current version.id: MSHTML.dll!CMarkup:: ReloadInCompatView Arbitrary~E58 AVR(D6B0C524) description: Security: Attempt to read from unallocated arbitrary memory (@0x22E22E58) in MSHTML. dll!CMarkup:: ReloadInCompatView note: The exception happens in the main process. Based on this information, this is expected to be a critical security issue!