Microsoft Internet Explorer 11 MSHTML CGeneratedContent::HasGeneratedSVGMarker Type Confusion

`Throughout November, I plan to release details on vulnerabilities I  
found in web-browsers which I've not released before. This is the  
eighteenth entry in that series. Unfortunately I won't be able to  
publish everything within one month at the current rate, so I may  
continue to publish these through December and January.  
  
The below information is available in more detail on my blog at  
http://blog.skylined.nl/20161124001.html. There you can find a repro  
that triggered this issue, reversed snippets from the vulnerable code  
and more details in addition to the information below.  
  
Follow me on http://twitter.com/berendjanwever for daily browser bugs.  
  
MSIE 11 MSHTML CGeneratedContent::HasGeneratedSVGMarker type confusion  
=======================================================  
(The fix and CVE number for this issue are unknown)  
  
Synopsis  
--------  
A specially crafted web-page can cause a type confusion in HTML layout  
in Microsoft Internet Explorer 11. An attacker might be able to exploit  
this issue to execute arbitrary code.  
  
Known affected software and attack vectors  
------------------------------------------  
+ 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  
-------  
Internally MSIE uses various lists of linked `CTreePos` objects to  
represent the DOM tree. For HTML/SVG elements a `CTreeNode` element is  
created, which embeds two `CTreePos` instances: one that contains  
information about the first child of the element and one that indicates  
the next sibling or parent of the element. For text nodes an object  
containing only one `CTreePos` is created, as such nodes never have any  
children. `CTreePos` instances have various flags set. This includes a  
flag that indicates if they are the first (`fTPBegin`) or second  
(`fTPEnd`) `CTreePos` instance for an element, or the only instance for  
a test node (`fTPText`).  
  
The `CTreePos::Branch` method of an `CTreePos` instance embedded in a  
`CTreeNode` can be used to calculate a pointer to the `CTreeNode`. It  
determines if the `CTreePos` instance is the first or second in the  
`CTreeNode` by looking at the `fTPBegin` flag and subtract the offset of  
this `CTreePos` object in a `CTreeNode` object to calculate the address  
of the later. This method assumes that the `CTreePos` instance is part  
of a `CTreeNode` and not a `TextNode`. It will yield invalid results  
when called on the later. In a `TextNode`, the `CTreePos` does not have  
the `fTPBegin` flag set, so the code assumes this is the second  
`CTreePos` instance in a `CTreeNode` object and subtracts 0x24 from its  
address to calculate the address of the `CTreeNode`. Since the  
`CTreePos` instance is the first element in a `TextNode`, the returned  
address will be 0x24 bytes before the `TextNode`, pointing to memory  
that is not part of the object.  
  
Note that this behavior is very similar to another issue I found around  
the same time, in that that issues also caused the code to access memory  
0x24 bytes before the start of a memory region containing an object.  
Looking back I believe that both issues may have had the same root cause  
and were fixed at the same time. You can find more details about that  
other issue in my blog post here:  
  
http://blog.skylined.nl/20161104001.html  
  
The `CGeneratedContent::HasGeneratedSVGMarker` method walks the DOM  
using one of the `CTreePos` linked lists. It looks for any descendant  
node of an element that has a `CTreePos` instance with a specific flag  
set. If found, the `CTreePos::Branch` method is called to find the  
related `CTreeNode`, without checking if the `CTreePos` is indeed part  
of a `CTreeNode`. If a certain flag is set on this `CTreeNode`, it  
returns true. Otherwise it continues scanning. If nothing is found, it  
returns false.  
  
The repro creates a situation where the  
`CGeneratedContent::HasGeneratedSVGMarker` method is called on an SVG  
path element which has a `TextNode` instance as a descendant with the  
right flags set to cause it to call `CTreePos::Branch` on this  
`TextNode`. This leads to type confusion/a bad cast where a pointer that  
points before a `TextNode` is used as a pointer to a `CTreeNode`.  
  
Exploit  
-------  
  
I did not find any code path that could lead to exploitation. However, I  
did not do a thorough step through of the code to find out if and how I  
might control execution flow upwards in the stack. Also, it appears  
trivial to have MSIE survive the initial crash by massaging the heap. It  
might be possible that other methods are affected by a similar issue and  
that further DOM manipulations can be used to trigger a more interesting  
code path.  
  
Time-line  
---------  
* *July 2014*: This vulnerability was found through fuzzing.  
* *September 2014*: This vulnerability was submitted to ZDI.  
* *September 2014*: This vulnerability appears to have been fixed.  
* *October 2014*: This vulnerability was rejected by ZDI.  
* *November 2016*: Details of this issue are released.  
  
Cheers,  
  
SkyLined  
  
  
  
Repro.html  
  
<html>  
<head>  
<meta http-equiv="X-UA-Compatible" content="IE=Edge" />  
<script>  
window.onload = function () {  
document.getAElementsAByATagAName("iframe")[0].src = "repro-iframe.html";  
}  
</script>  
</head>  
<body>  
<iframe></iframe>  
</body>  
</html>  
  
  
Repro-iframe.html  
  
<svg><path marker-start="url(#)"><title><q><button>  
  
`