#HITB2013AMS D1T2 Nikita Tarakanov - Exploiting Hardcore Pool Corruptions in MS Windows Kernel

### Overview At HITB2013AMS, independent security researcher Nikita Tarakanov presents research on exploiting Windows kernel pool corruptions that were previously considered unexploitable ("hardcore" pool corruptions). As modern operating systems and applications (such as Google Chrome and Internet Explorer) deploy sandboxes, attackers increasingly turn to kernel vulnerabilities for privilege escalation and sandbox escapes. While Microsoft has heavily hardened the kernel pool allocator across Windows 7 and Windows 8 against metadata-corruption attacks, Tarakanov demonstrates that attackers can bypass allocator defenses entirely by targeting Windows Object Manager structures.

### Key Topics - **Kernel Pool Basics & Hardening History**: Examination of paged, non-paged, and session pools, pool headers, lookaside lists, list heads, and coalescing behavior (`ExAllocatePoolWithTag` and `ExFreePoolWithTag`). - **Evolution of Public Pool Exploitation**: Review of prior research from Kostya Kortchinsky (fake entries and write-4 primitives) and Tarjei Mandt (attacks on allocator metadata, safe unlinking bypasses, pool index overwrite, and block size/split chunk attacks). - **The "Hardcore" Corruption Problem**: Public techniques require substantial control over overflowing data. When overflow data is fixed, null-filled (e.g., via `memset`), or cannot construct a fake pool header, traditional metadata attacks fail. - **Direct Kernel Object Manipulation (DKOM)**: Shifting focus from pool allocator metadata to kernel object headers and the Windows Object Manager. - **Exploitation via Object Type Index**: Abusing the global object types array and the `BADB0B0` constant to hijack control flow via syscalls like `NtQuerySecurityObject`.

### Technical Details Windows describes kernel objects using an `OBJECT_HEADER` placed immediately before the object body. The header contains a type index pointing to an internal array of pointers to `OBJECT_TYPE` structures, which in turn contain `OBJECT_TYPE_INITIALIZER` holding function pointers (such as open, close, and security procedures).

Tarakanov highlights key architectural weaknesses: 1. **The Object Types Array & `BADB0B0`**: The array holding object type pointers starts its valid elements at index 3. Element 0 is null, while element 1 holds the constant value `0xBADB0B0`. On 64-bit Windows, this constant is zero-extended, placing the address within userland address space where an attacker can allocate and forge an `OBJECT_TYPE` structure. Consequently, corrupting a single type index byte to `1` allows an attacker to hijack control flow when a method is invoked. 2. **Triggering Dispatch via `NtQuerySecurityObject`**: Calling `NtQuerySecurityObject` dereferences the object's security procedure from its initializer table. Following corruption of the object header, this leads directly to an indirect call (`call edx`), giving control of `EIP`/`RIP`. 3. **Pool Shaping**: To avoid triggering a Blue Screen of Death (BSOD), the pool is sprayed with objects matching the pool type (paged vs. non-paged) and massaged to place target allocations at the bottom of a page, where chunk metadata checks are skipped on free. 4. **Object Type Confusion**: In cases where overflowing data cannot be set to `1`, an attacker can modify the type index to another valid object type (e.g., changing a registry key to a file), forcing a type confusion where specialized dispatch methods execute against mismatched data.

### Takeaways Tarakanov argues that Microsoft focused security efforts almost entirely on pool allocator metadata while neglecting the Object Manager. Although mitigations like SMEP/SMAP or blocking null-page allocations limit userland dereferences on newer 64-bit systems, 32-bit systems and kernel-addressed structures remain vulnerable unless Microsoft implements integrity cookies in object headers and replaces magic constants like `BADB0B0` with high-kernel addresses.