Full Report
Exploiting MS17-017 EoP Using Color Palettes This post is an accompaniment to the Defcon 25 talk given by Saif. One of the core topics of the talk was the release of a new technique GDI object abuse technique, name Palette Objects. Saif presented a previously unreleased Windows 7 SP1 x86 exploit involving the abuse of a newly discovered GDI object abuse technique. A complete white-paper on the topic was released and can be found here: Whitepaper
Analysis Summary
# Research: Exploiting MS17-017 EoP Using Color Palettes (GDI Palette Object Abuse)
## Metadata
- Authors: Saif (SensePost)
- Institution: SensePost
- Publication: Accompanying post for Defcon 25 talk
- Date: July 29, 2017
## Abstract
This research details a novel technique for achieving arbitrary kernel memory read/write primitives on Windows systems (specifically demonstrated on Windows 7 SP1 x86) by abusing Graphical Device Interface (GDI) Palette objects. This technique, named "Palette Objects" abuse, involves manipulating specific fields within the kernel structure (`XEPALOBJ`) associated with GDI palettes, such as the entry count (`cEntries`) or the internal color array pointer (`*pFirstColor`), to cause operations intended for the legitimate palette data to read or write outside the allocated bounds, leading to corruption necessary for Privilege Escalation (EoP).
## Research Objective
The primary objective was to discover and fully disclose a new GDI object abuse technique that provides kernel read/write capabilities, aiming to create a functional Local Privilege Escalation (LPE) exploit, demonstrated against the vulnerability addressed in MS17-017. The research sought to move beyond related techniques (mentioned in prior research) by providing a complete methodology for arbitrary kernel read/write via palette manipulation.
## Methodology
### Approach
The methodology involved in-depth reversing of Windows kernel structures related to GDI objects, specifically the Palette object structure (`XEPALOBJ`) within `win32k.sys`. The researcher identified key internal fields and then systematically analyzed the behavior of standard GDI functions (`CreatePalette`, `DeleteObject`, `GetPaletteEntries`, `SetPaletteEntries`, `AnimatePalette`) when these internal fields were manipulated via user-controlled input. This manipulation was framed around the concept of a "Manager Palette" to control object properties necessary to pivot to a "Worker Palette" for arbitrary memory access.
### Dataset/Environment
The exploit demonstration and analysis focused on **Windows 7 SP1 x86**. The underlying structures were cross-referenced using documentation from ReactOS and community tools like GDIObjDump.
### Tools & Technologies
* **GDI Functions:** `CreatePalette`, `DeleteObject`, `GetPaletteEntries`, `SetPaletteEntries`, `Animate.'</palette/AnimatePalette`.
* **Kernel Structures Searched:** `XEPALOBJ` (Kernel Pool Tag Gh?8, Gla8).
* **Analysis Tools:** WinDbg extensions (e.g., GDIObjDump).
* **Exploitation Framework:** Custom exploit code targeting the GDI object manipulation prerequisites.
## Key Findings
### Primary Results
1. **Discovery of Palette Object Abuse:** A previously undisclosed method to control Palette object kernel structures (`XEPALOBJ`) exists through standard GDI APIs.
2. **Relative Memory Read/Write Primitive:** By overwriting the `cEntries` member of a palette object (the entry count), operations could be coerced into reading or writing adjacent kernel memory relative to the palette structure's allocated buffer.
3. **Arbitrary Kernel Memory Read/Write Primitive:** By manipulating the internal pointer `*pFirstColor` (pointing to the `apalColors` array), the attack can redirect GDI read/write operations to *any* address in kernel memory.
4. **Successful Privilege Escalation:** The arbitrary kernel read/write primitive was successfully used to elevate privileges from a standard user context to **SYSTEM** by locating the System EPROCESS structure and swapping the current process's Security Token with the System process's token.
### Supporting Evidence
* A complete whitepaper and proof-of-concept exploits (for MS17-017 and related issues) were released alongside the presentation.
* The functionality utilizes standard desktop APIs (`GetPaletteEntries`, `SetPaletteEntries`), making the attack stealthier initially than direct kernel object manipulation.
### Novel Contributions
* **Palette Objects as an Abuse Vector:** This technique pioneers the exploitation of Palette objects, adding them to the class of GDI objects (like Bitmaps) used for kernel exploitation via object abuse.
* **Full Arbitrary R/W Implementation:** While relative read/write via palette size was hinted at previously, this work is presented as the first full disclosure of using palette pointer manipulation (`*pFirstColor`) to achieve true **arbitrary kernel read/write**.
## Technical Details
The core mechanism relies on two key fields within the kernel `XEPALOBJ` structure:
1. **`cEntries`:** Dictates the number of color entries to process during read/write calls. Overwriting this value causes operations to overshoot the allocated buffer, facilitating relative memory corruption.
2. **`*pFirstColor`:** A pointer to the actual color data array (`apalColors`). By corrupting this pointer (e.g., by targeting it via a controlled relative write achieved through `cEntries` manipulation), the attacker redirects GDI functions like `SetPaletteEntries` to write arbitrary content into any kernel address they control.
The exploitation follows a two-object approach:
1. **Manager Palette:** Used to gain control over a critical internal field (e.g., `cEntries` or `*pFirstColor`) via an underlying heap corruption/overflow vulnerability (implied to be related to MS17-017).
2. **Worker Palette:** Once the Manager Palette redirects R/W operations, the Worker Palette's GDI functions are used to execute the arbitrary reads and writes against the kernel memory location of interest (such as the EPROCESS token).
## Practical Implications
### For Security Practitioners
This research demonstrates that even objects seemingly benign or less analyzed than Bitmaps (e.g., Palettes) in the GDI subsystem can serve as powerful primitives for kernel exploitation, potentially bypassing older mitigations focused solely on bitmap-related vulnerabilities.
### For Defenders
Defenders must ensure that vulnerabilities leading to UAF or heap overflows within the Win32k subsystem, especially those that allow user mode control over GDI object headers (like MS17-017), are prioritized for patching, as they directly enable high-impact kernel primitives. Monitoring for unusual usage patterns involving GDI Palette functions, although difficult, could be a secondary defense indicator.
### For Researchers
This work opens further avenues for researching other undocumented or underutilized GDI object structures within kernel memory (e.g., Brushes, Fonts) to discover similar primitive-building techniques. It reinforces the strategy of performing deep analysis on Win32k object management paths.
## Limitations
The specific exploit demonstrated relies on a known vulnerability (MS17-017) to achieve the initial heap control necessary to corrupt the Manager Palette structure. Additionally, the details provided focus heavily on the x86 architecture for the demonstration, though the structure analysis hints at x64 applicability.
## Comparison to Prior Work
This research builds upon previous GDI abuse techniques, notably those involving Bitmap objects. The paper explicitly references related work by the 360 Vulcan team concerning relative memory reads/writes using palettes, clarifying that this release extends that concept to provide a **full arbitrary read/write primitive** using the `*pFirstColor` pointer corruption, which was not fully disclosed previously.
## Real-world Applications
* Achieving **SYSTEM-level code execution** on vulnerable Windows systems via Local Privilege Escalation.
* The technique itself (arbitrary kernel R/W via structure corruption) is a reusable primitive applicable to exploiting other kernel vulnerabilities in the Win32k subsystem where arbitrary heap corruption is possible.
## Future Work
* Analyzing the stability and structure layout of `XEPALOBJ` on modern 64-bit Windows versions in the context of current kernel mitigations (like KASLR and SMEP/SMAP).
* Investigating whether similar pointer manipulation can be achieved through other palette functions or slightly different object corruption pathways.
## References
* ReactOS wiki: Win32k/PALETTE structure (x86 reference).
* GDIObjDump repository (CoreSecurity/GDIObjDump).
* Slides from 360Vulcan team talk on Dark Composition (CWE 2017).
* Related Proof-of-Concept for token stealing (referenced previously disclosed exploit technique, MS16-098).