Segment Heap is a new native heap implementation introduced in Windows 10 that is enabled in Windows apps (formerly called Modern/Metro apps) and certain system processes. This blog post discusses CVE-2016-0117, a vulnerability in the Windows PDF library (WinRT PDF) that triggered my research of the Segment Heap.

Early this year, Microsoft patched a vulnerability I discovered in WinRT PDF. The vulnerability is interesting in that it can be used to perform an arbitrary write to Edge’s content process memory, one of the critical elements for remote code execution. But another interesting aspect of the vulnerability is that to perform a reliable arbitrary write in the Edge content process, one needs to perform precise layout manipulation of a heap that is managed by the new heap implementation in Windows 10.

About CVE-2016-0117

The vulnerability (CVE-2016-0117, MS16-028) is in WinRT PDF’s PostScript interpreter for Type 4 (PostScript Calculator) functions. PostScript Calculator functions use a subset of the PostScript language operators, which use the PostScript operand stack when performing their functions.

The PostScript operand stack is a vector containing 0x65 CType4Operand pointers. Each CType4Operand is a data structure consisting of one DWORD that represents the type and one DWORD representing the value in the PostScript operand stack.

The PostScript operand stack and the CType4Operands are allocated from the MSVCRT heap:

The issue is that the PostScript interpreter fails to validate if the PostScript operand stack index is past the end of the PostScript operand stack (PostScript operand stack index is 0x65). This leads to a dereference of a CType4Operand pointer located right after the end of the PostScript operand stack.

An Opportunity for Attackers

If an attacker is able to implant a target address right after the end of the PostScript operand stack, the attacker will be able to perform a memory write to the target address via a PostScript operation that pushes a value in the PostScript operand stack.

In the illustration below, multiple integers (1094795585 or 0x41414141) are pushed to the PostScript operand stack, with the last 0x41414141 pushed to invalid index 0x65 of the PostScript operand stack:

Below is a WinDbg session when WinDbg is attached to the Edge content process when the vulnerability was triggered:

The first item to notice is the address (marked orange) of the memory write operation. It is not controlled in this particular run because heap layout manipulation was not performed. On the other hand, the high 32 bits of the value to write (red) is controlled; its value is from the PostScript Calculator function in the PDF.

Segment Heap

The next item to notice in the WinDbg session is the PostScript operand stack address (blue). When information about it is dumped, the heap (green) where the PostScript operand stack is allocated is displayed. The MSVCRT heap address is then dumped and verified to be the same heap where the PostScript operand stack was allocated. Finally, the heap listing of the Edge content process shows that the MSVCRT heap is managed by the Segment Heap.

Reliably implanting the target address right after the end of the PostScript operand stack requires precise heap layout manipulation, which in this case necessitates some level of understanding of how the Segment Heap works. Certain cases, such as the tactic that I will discuss in my talk, require deep understanding of some of Segment Heap’s internals.

Learn More at Black Hat USA

I will present my research on the internals and the security mechanisms of the Segment Heap at the upcoming Black Hat USA 2016 conference. If you’re a security researcher writing proof-of-concept code, seeking to understand the internals of the Segment Heap, or just interested to see how this new heap implementation works, please drop by at my talk, “Windows 10 Segment Heap Internals.” It will be held Aug. 4, 2016, at 9:45 a.m in the South Seas CDF room.