Introduction to EdgeHTML

EdgeHTML is the rendering engine of the Edge browser in Windows 10. It is a fork of the MSHTML/Trident rendering engine currently used in Internet Explorer. The forking was done to support modern Web standards and remove legacy code.

Early last year, before the release of Edge, Microsoft estimated that around 220,000-plus lines of code were removed, while over 300,000 lines of code were added for interoperability fixes and new features. From a security research standpoint, it is both interesting and important to understand what the side effects of these changes are in terms of how the attack surface of the rendering engine has changed. It is also important to identify what exploit mitigations are in place to understand how difficult it is for attackers to exploit vulnerabilities.

Attack Surface

Due to the number of different file types a rendering engine needs to process — plus the numerous features and Web standards it needs to support — the attack surface of a rendering engine is quite extensive.

The diagram below lists the different types of untrusted input that EdgeHTML can process (left), the entry point EdgeHTML class that handles the input (middle) and the dependency used by EdgeHTML to parse the input (right), if any:

Figure 1

One of the core functions of a rendering engine is to parse and render HTML and CSS files. Therefore, internal EdgeHTML classes handle the processing of the said files. However, for certain types of files, EdgeHTML uses its dependencies for the actual parsing of the content:

• XML-based data and markups: XmlLite and MSXML6
• Images: Windows Imaging Component (WIC)
• Audio/Video: Media Foundation (MF)
• Fonts: DirectWrite

What that means in terms of attack surface is that attackers can also remotely reach the parsing code of the above libraries via EdgeHTML.

In addition to the different file types that are handled by EdgeHTML, one of the largest attack vectors in EdgeHTML is the Document Object Model (DOM) API. Via the DOM API, JavaScript code can interact directly with DOM objects in the rendering engine. These DOM objects may in turn invoke code in other internal rendering engine objects and, if applicable, invoke code in the libraries they use:

Figure 2

Because DOM API calls can affect the state of the DOM tree, DOM objects and other internal rendering engine objects, unexpected input, unexpected state changes, or an incorrect state when a DOM API is called can result in
memory corruption vulnerabilities. Examples of memory corruption vulnerabilities are use-after-free vulnerabilities that were previously used by zero-day exploits against MSHTML in Internet Explorer (IE).

In the initial release of EdgeHTML, 80 new DOM object types were found. The methods and properties of these new DOM object types represent new code or code paths that can be remotely reached by an attacker. It is expected that new DOM object types, methods and properties will be added as new functionalities need to be exposed to developers via the DOM API.

An interesting feature of EdgeHTML that was discussed previously is that it renders PDF files using the built-in WinRT PDF Renderer library in Windows by default:

Figure 3

From an attacker’s perspective, complex renderers such as the WinRT PDF Renderer and Adobe Flash Player, which are both used by EdgeHTML, provide another attack surface and set of vulnerabilities that can be leveraged. Additionally, the functionalities of these complex renderers can potentially be repurposed to bypass exploit mitigations.

Finally, the notable rendering engine attack surface reduction I noticed in my research was the removal of support for WMF and EMF images, EOT fonts and binary behaviors (which includes VML). The code that handles these file types or functionalities had a history of remotely exploitable vulnerabilities that were previously used by zero-day exploits.

In addition to attack surface reduction in the rendering engine, a lack of support for a number of legacy IE technologies further contributes to the overall attack surface reduction in Edge.

Exploit Mitigations

To successfully exploit vulnerabilities in EdgeHTML or any of its dependencies, an attacker would need to bypass a number of exploit mitigations. There are exploit mitigations applied to the Edge content process where EdgeHTML and its dependencies are hosted, and there are also additional mitigations applied to EdgeHTML and its dependencies. Figure 1 above lists these exploit mitigations.

The Edge content process, by default, runs 64-bit and has ASLR (with High Entropy and Force ASLR) and DEP enabled. The combination of these exploit mitigations increases the difficulty of exploiting memory corruption vulnerabilities, requiring the attacker to perform precise heap grooming and leaking the contents of memory that are needed in the later stages of an exploit.

Assuming that an exploit against the Edge content process is successful, another mitigation called AppContainer limits what the payload can do and access. The attacker would have to exploit another vulnerability in a privileged process or the kernel to escape the AppContainer sandbox to gain higher privileges and achieve persistence.

EdgeHTML and its dependencies are also compiled with Buffer Security Check (/GS) and Control Flow Guard (CFG) enabled. /GS is a well-known mitigation against stack-based buffer overflows. CFG, on the other hand, is a newer mitigation that attempts to detect abnormal control flow, which can occur when an exploit is attempting to execute return-oriented programming (ROP) gadgets. With CFG enabled, an attacker would need to find a way to control the execution flow of the target process without triggering the CFG checks.

Finally, there are mitigations specific to EdgeHTML. The first is Virtual Table Guard (VTGuard), which attempts to detect an invalid virtual function table that can occur if an exploit is trying to control execution flow via a controlled C++ object in memory.

The second mitigation is MemGC. With MemGC, a number of use-after-frees that were previously exploitable became unexploitable. MemGC achieves this via a garbage collection mechanism that only frees an object’s memory chunk when no references to it are found in the registers, stack and MemGC heap.

Figure 4

With all these mitigations in place, finding exploitable vulnerabilities and reliably exploiting them becomes more difficult and, thus, more costly. Since its initial release, Microsoft continues to add new exploit mitigations in Edge.

Conclusion

As new features and Web standards are implemented by Microsoft, we can expect the attack surface of the EdgeHTML rendering engine to expand. This expansion in attack surface, however, is balanced by the comprehensive exploit mitigations. They make a number of vulnerabilities in EdgeHTML and its dependencies unexploitable or very difficult and costly to exploit.

For more information on my research of EdgeHTML’s attack surface and exploit mitigations, please refer to my presentation slides and white paper.