Abusing GDI for Ring0 exploit primitives

### Overview The presentation outlines a Windows Ring 0 exploitation technique discovered in the wild that leverages Graphics Device Interface (GDI) objects to build arbitrary kernel read and write primitives. According to the speaker, while kernel-mode exploitation in Windows has been widely studied, this specific approach has remained largely undocumented despite being viable across multiple Windows versions from Windows 2000 up to Windows 10. By exploiting a single write vulnerability to alter an internal GDI structure field, an attacker can achieve repeatable, high-reliability arbitrary memory read and write capabilities.

### Key Topics - **Historical and Related Research:** Mentions previous research regarding Ring 0 exploitation, such as work by Quintín on Windows kernel exploitation and research touching on shared session objects in the Windows subsystem between user and kernel space. - **GDI Shared Handle Table (`GdiSharedHandleTable`):** Examination of the user-accessible table holding entries for GDI handles. Knowledge of a handle allows direct calculation of the offset and discovery of the underlying kernel object address without kernel information disclosure. - **Bitmap Surface Structures:** Inspection of internal structures following the `BASEOBJECT`, specifically surface offsets and the pointer to the first pixel scanline (referred to phonetically in the transcript as `perez cancer` / `pvScan0`). - **Manager-Worker Bitmap Technique:** Leveraging two bitmap objects (a manager/master and a worker) where the manager controls the worker's data pointer, turning single-use vulnerabilities into repeatable read/write primitives. - **Privilege Escalation Mechanism:** Stealing the System token and assigning it to a low-integrity target process by traversing active process links.

### Technical Details 1. **Locating Kernel Objects:** In 64-bit systems, each entry in the shared GDI table has a fixed size (0x18 / 24 bytes). By taking the lower portion of an object handle, multiplying it by the structure size, and adding the table base address, the exact table entry is calculated. The entry reveals the kernel address of the corresponding object. 2. **The Target Pointer:** The kernel object contains header data followed by surface-specific data. Within the bitmap surface structure lies a pointer to the bitmap buffer (scanline 0). The GDI functions `GetBitmapBits` and `SetBitmapBits` directly read from and write to the location referenced by this pointer. 3. **Manager and Worker Setup:** - The attacker creates two bitmaps: a "manager" and a "worker". - Using a single Ring 0 write vulnerability, the manager's scanline pointer is overwritten with the address of the worker's scanline pointer. - The manager can now be used as an address register via `SetBitmapBits`, pointing the worker to any virtual memory address. - Calling `GetBitmapBits` or `SetBitmapBits` on the worker performs arbitrary reads or writes at that specified address, providing an ongoing primitive without triggering additional kernel vulnerabilities. 4. **Exploit Demonstration:** - The speaker demonstrates escalating a low-integrity demo application to `SYSTEM`. - The primitive locates the base of the initial system process, resolves active process links to locate the current demo process, reads the security token from the `SYSTEM` process via `GetBitmapBits`, and copies it into the demo process via `SetBitmapBits`.

### Takeaways - A single kernel write corruption can be converted into an arbitrary, stable read/write primitive using standard GDI bitmap manipulation. - Because user space can derive kernel object addresses from GDI handles via the shared handle table, attackers avoid needing separate kernel address leaks. - Care must be taken regarding bitmap dimensions and valid virtual memory addresses to avoid kernel crashes and system bugchecks.