Microsoft Internet Explorer 9 MSHTML CMarkup::ReloadInCompatView Use-After-Free

`Since November I have been releasing details on all vulnerabilities I  
found that I have not released before. This is the thirty-first entry  
in the series. This information is available in more detail on my blog  
at http://blog.skylined.nl/20161213001.html. There you can find a repro  
that triggered this issue in addition to the information below.  
  
If you find these releases useful, and would like to help me make time  
to continue releasing this kind of information, you can make a donation  
in bitcoin to 183yyxa9s1s1f7JBpAPHPmzAQ346y91Rx5DX.  
  
Follow me on http://twitter.com/berendjanwever for daily browser bugs.  
  
MSIE9 MSHTML CMarkup::ReloadInCompatView use-after-free  
=======================================================  
(The fix and CVE number for this issue are not known)  
  
Synopsis  
--------  
  
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.  
  
Known affected software and attack vectors  
------------------------------------------  
* 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.  
  
Details  
-------  
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::ReloadInCompatView`. This method calls  
`CDoc::CompatViewRefresh`, which indirectly calls  
`CScriptCollection::~CScriptCollection`, which releases the `CMarkup`  
object used as `this` in `CMarkup::ReloadInCompatView`.  
  
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::ReloadInCompatView`, the code  
will use the (now freed) `CMarkup` object. When page heap is enabled,  
this lead to an immediate access violation.  
  
Exploit  
-------  
I did not immediately find a way to control the freed memory before the  
reuse following the `CDoc::CompatViewRefresh` 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:  
* There are ways to modify the freed `CMarkup` object before it is  
reused.  
* There are other locations where the freed `CMarkup` object is used  
after it has been freed, and the freed `CMarkup` object can be  
modified before this happens.  
* There could be other stale pointers to freed memory that get reused,  
and there are ways to modify the freed memory they point to before  
that reuse.  
  
As these other crash stacks do not include  
`CMarkup::ReloadInCompatView`, it seems most likely that they are caused  
by the second or third option, which could indicate that the bug is in  
fact exploitable.  
  
Time-line  
---------  
* 5 May 2014: This vulnerability was found through fuzzing.  
* 14 May 2014: This vulnerability was submitted to ZDI.  
* 3 July 2014: This vulnerability was rejected by ZDI.  
* 9 July 2014: This vulnerability was submitted to EIP.  
* July/August 2014: This vulnerability was rejected by EIP.  
* 13 August 2014: This vulnerability was submitted to iDefense.  
* Date unknown: This issue was withdrawn from iDefense.  
* Date unknown: This vulnerability was address by Microsoft.  
* 13 December 2016: Details of this vulnerability are released.  
  
Cheers,  
  
SkyLined  
  
  
Repro.html  
  
<!DOCTYPE>  
<script defer>  
document.designAMode = "on";  
</script>  
<q dir="ltr">  
<ruby dir="rtl">  
`