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. November 2nd, 2016 MSIE 11 MSHTML CView::Calculate­Image­Immunity use-after-free

MSIE 11 MSHTML CView::Calculate­Image­Immunity use-after-free

(The fix and CVE number for this bug are not known)

Synopsis

A specially crafted web-page can cause Microsoft Internet Explorer 11 to free a memory block that contains information about an image. The code continues to use the data in freed memory block immediately after freeing it. It does not appear that there is enough time between the free and reuse to exploit this issue.

Known affected versions, attack vectors and mitigations

  • Microsoft Internet Explorer 11

    An attacker would need to get a target user to open a specially crafted web-page. As far as can be determined, disabling Java­Script should prevent an attacker from triggering the vulnerable code path.

 Repro.html <script> // This Po­C attempts to exploit a memory disclosure bug in VBScript.dll // See http://blog.skylined.nl/20161102001.html for details. var o­Document­Fragment = document.create­Document­Fragment(), o­Element = document.create­Element('x'); o­Document­Fragment.append­Child(o­Element); o­Element.style.list­Style­Image = "url(x)"; o­Document­Fragment.remove­Child(o­Element); // This work by Sky­Lined is licensed under a Creative Commons // Attribution-Non-Commercial 4.0 International License. </script>

Details

Setting the list­Style­Image property of an Element object causes MSIE to allocate 0x4C bytes for an "image context" structure, which contains a reference to the document object as well as a reference to the same CMarkup object as the document. When the element is removed from the document (-fragment), this image context is freed on the next "draw". However, the code continues to use the freed context almost immediately after it is freed.

Exploit

I tried a few tricks to see if there was an easy way to reallocate the freed memory before the reuse, but was unable to find anything. I do not know if there is a way to cause further reuse of the freed memory later on in the code. Running the repro as-is without page heap does not appear to trigger crashes. It does not appear that there is enough time between the free and reuse to exploit this issue.

Time-line

  • May 2014: This vulnerability was found through fuzzing.
  • June 2014: This vulnerability was submitted to ZDI.
  • July 2014: ZDI rejects the submission.
  • November 2016: The issue does not reproduce in the latest build of MSIE 11.
  • November 2016: Details of this issue are released.

Unfortunately, my records of what happened after ZDI rejected the issue are patchy. It appears that I did not pursue reporting the issue anywhere else, but Microsoft does appear to have patched the issue, as I can no longer reproduce it.

 Bug­Id report: MSHTML.dll!CView::Calculate­Image­Immunity Arbitrary~FB0 AVR(2B4083E3) 
id:             MSHTML.dll!CView::Calculate­Image­Immunity Arbitrary~FB0 AVR(2B4083E3)
description:    Security: Attempt to read from unallocated arbitrary memory (@0x56F06FB0) in MSHTML.dll!CView::Calculate­Image­Immunity
note:           The exception happens in the main process. Based on this information, this is expected to be a critical security issue!
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. © Copyright 2024 by Sky­Lined. Last updated on March 23rd, 2024. Creative Commons License This work is licensed under a Creative Commons Attribution-Non‑Commercial 4.0 International License. If you find this web-site useful and would like to make a donation, you can send bitcoin to 183yyxa9s1s1f7JBp­PHPmz­Q346y91Rx5DX.