This is a friendly warning that your web-browser does not currently protecting your privacy and/or security as well as you might want. Click on this message to see more information about the issue(s) that were detected.

MSIE 9 MSHTML CMarkup::Reload­In­Compat­View 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, attack vectors and potential mitigations

Repro.html <!DOCTYPE> <script defer> document.design­Mode = "on"; </script> <q dir="ltr"> <ruby dir="rtl">

Details

By switching the a document's design­Mode property to on in a deferred script, MSIE 9 can be made to reload a web page using CMarkup::Reload­In­Compat­View. This method calls CDoc::Compat­View­Refresh, which indirectly calls CScript­Collection::~CScript­Collection, which releases the CMarkup object used as this in CMarkup::Reload­In­Compat­View. The relevant stack for the freeing of this CMarkup object is:

    76e8c484 kernel32!Heap­Free+0x00000014
    6780c4d8 MSHTML!CMarkup::`vector deleting destructor'+0x00000026
    6776fb9b MSHTML!CScript­Collection::~CScript­Collection+0x00000152
    67816a0d MSHTML!CScript­Collection::Release+0x00000053
    6751f7e7 MSHTML!CWindow::Super­Navigate­Internal+0x000004c4
    675209f7 MSHTML!CWindow::Super­Navigate2With­Bind­Flags+0x00000032
    679b05f8 MSHTML!CDoc::Compat­View­Refresh+0x000000a0
    679c00d4 MSHTML!CMarkup::Reload­In­Compat­View+0x0000021f

Immediately after returning to CMarkup::Reload­In­Compat­View, 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::Compat­View­Refresh 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:

As these other crash stacks do not include CMarkup::Reload­In­Compat­View, 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

Bug­Id report: MSHTML.dll!CMarkup::Reload­In­Compat­View Arbitrary~E58 AVR(D6B0C524) This report was generated using a predecessor of Bug­Id, a Python script created to detect, analyze and id application bugs. Don't waste time manually analyzing issues and writing reports but try Bug­Id out yourself today! You'll get even better reports than this one with the current version.
id:             MSHTML.dll!CMarkup::Reload­In­Compat­View Arbitrary~E58 AVR(D6B0C524)
description:    Security: Attempt to read from unallocated arbitrary memory (@0x22E22E58) in MSHTML.dll!CMarkup::Reload­In­Compat­View
note:           The exception happens in the main process. Based on this information, this is expected to be a critical security issue!
© Copyright 2016 by Sky­Lined.
Creative Commons License This work is licensed under a Creative Commons Attribution-Non‑Commercial 4.0 International License.

Last updated on 2016-11-21.
If you find this web-site useful and would like to make a donation, you can send bitcoin to 183yyxa9s1s1f7JBp­PHPmz­Q346y91Rx5DX.