CVE-2021-1732 Microsoft Windows10 本地提权漏研究及Poc/Exploit开发

分析及开发涉及到的工具，Ida pro、Windbg、Visual studio 2019，使用环境Windows 10 Version 1809 x64.

漏洞发生在Windows 图形驱动win32kfull!NtUserCreateWindowEx函数中的一处内核回调用户态分配内存与tagWND->flag属性设置不同步导致的漏洞。使得可以伪造这个tagWND->offset值发生内存越界。

当驱动win32kfull.sys调用NtUserCreateWindowEx创建窗口时会判断tagWND->cbWndExtra(窗口实例额外分配内存数)，该值不为空时调用win32kfull!xxxClientAllocWindowClassExtraBytes函数回调用户层user32.dll!__xxxClientAllocWindowClassExtraBytes分配空间，分配后的地址使用NtCallbackReturn函数修正堆栈后重新返回内核层并保存并继续运行，而当tagWND->flag值包含0x800属性后该保存值变成了一个offset。

攻击者可以Hook user32.dll!_xxxClientAllocWindowClassExtraBytes函数调用NtUserConsoleControl修改tagWND->flag包含0x800属性值后使用NtCallbackReturn返回一个自定义的值到内核tagWND->offset。

Windows Server, version 20H2 (Server Core Installation)
Windows 10 Version 20H2 for ARM64-based Systems
Windows 10 Version 20H2 for 32-bit Systems
Windows 10 Version 20H2 for x64-based Systems
Windows Server, version 2004 (Server Core installation)
Windows 10 Version 2004 for x64-based Systems
Windows 10 Version 2004 for ARM64-based Systems
Windows 10 Version 2004 for 32-bit Systems
Windows Server, version 1909 (Server Core installation)
Windows 10 Version 1909 for ARM64-based Systems
Windows 10 Version 1909 for x64-based Systems
Windows 10 Version 1909 for 32-bit Systems
Windows Server 2019 (Server Core installation)
Windows Server 2019
Windows 10 Version 1809 for ARM64-based Systems
Windows 10 Version 1809 for x64-based Systems
Windows 10 Version 1809 for 32-bit Systems
Windows 10 Version 1803 for ARM64-based Systems
Windows 10 Version 1803 for x64-based Systems

Windows 10 Version 1809 for x64

漏洞发生在Windows 图形驱动win32kfull!NtUserCreateWindowEx中。

当驱动win32kfull.sys调用NtUserCreateWindowEx创建窗口时会判断tagWND->cbWndExtra(窗口实例额外分配内存数)，该值不为空时调用win32kfull!xxxClientAllocWindowClassExtraBytes函数回调用户层user32.dll!__xxxClientAllocWindowClassExtraBytes创建内存，分配后的地址使用NtCallbackReturn函数修正堆栈后重新返回内核层并保存并继续运行，而当tagWND->flag值包含0x800属性时候对该值采用offset 寻址。

使用NtUserConsoleControl修改flag包含0x800属性。

win32kfull!NtUserCreateWindowEx创建窗口时会判断tagWND->cbWndExtra(窗口实例额外分配内存数)，该值不为空时调用win32kfull!xxxClientAllocWindowClassExtraBytes函数分配内存返回分配地址。图中我们可以看见偏移0xC8为tagWND->cbWndExtra,偏移0x128为tagWND->offset保存分配内存地址。

KeUserModeCallback使用编号123回调用户层user32.dll中的KernelCallbackTable表中函数user32.dll!_xxxClientAllocWindowClassExtraBytes。

31行代码中返回信息第一个指针类型指向的就是用户层分配内存地址。驱动调用ProbeForRead函数进行验证，该函数判断地址+长度小于MmUserProbeAddress就行。

输入到用户层参数是需分配内存大小，长度4字节。

返回信息长度必须为0x18字节。

返回的地址+长度小于MmUserProbeAddress。

当win32kfull!xxxCreateWindowEx调用win32kfull!xxxClientAllocWindowClassExtraBytes后并没有重新设置这个flag,用户可以伪装一个小于MmUserProbeAddress任意值进行越界写入(一次性)。

图中我们可以看得出偏移0xE8是一个flag。

当flag值包含0x800属性时候偏移0x128保存得分配内存地址变成了offset 寻址。

当flag值不包含0x800属性则重新分配内存并设置偏移0x128改成offset 寻址。

第152行代码设置flag值包含0x800属性。

NtConsoleControl 该函数为未公开函数，我们需要结合分析进行后续调用。

NtConsoleControl

输入参数1：功能序号，小于等于6

输入参数2：输入信息

输入参数3：输入信息长度小于等于0x18

xxxConsoleControl

第102行代码处nIndex == 6 编号是修改flag属性包含0x800功能地方。

第104行代码处判断输入信息长度必须为0x10。

第106行代码处获取输入信息第一个位置为HWND是窗口句柄。

第152行代码处用传入的HWND调用ValidateHwnd转换成内核tagWND结构后偏移0x28(内核tagWND映射到用户层地址)中修改flag值包含0x800属性。

@2 提到内核win32kfull!xxxClientAllocWindowClassExtraBytes会调用KeUserModeCallback进入用户模式回调。返回信息的长度必须为0x18字节。user32!_xxxClientAllocWindowClassExtraBytes函数分配后的地址使用NtCallbackReturn函数修正堆栈后重新返回内核层并保存并继续运行。

NtCallbackReturn的函数原型NTSTATUS __stdcall NtCallbackReturn(PVOID Result, ULONG ResultLength, NTSTATUS Status)
第8行代码我们可以看出NtCallbackReturn返回了长度0x18的数据，数据第一个8字节是分配后的地址。

漏洞Attack流程图我们可以看出只要Hook user32!_xxxClientAllocWindowClassExtraBytes中调用NtUserConsoleControl跟NtCallbackReturn就行。
@3 提到调用NtUserConsoleControl会重新设置tagWND->offset跟tagWND->flag值包含0x800属性， flag值包含0x800属性采用offset 寻址。我们在当前调用NtUserConsoleControl的目的就是修改tagWND->flag值包含0x800属性,  再调用NtCallbackReturn函数返回指定值目的是重新修改tagWND->offset, 因为win32kfull!xxxClientAllocWindowClassExtraBytes会把返回值放入到tagWND->offset。

系统创建一个窗口流程：
   1. 应用程序创建一个窗口会调用user32!CreateWindow/Ex函数。
   2. 使用user32u!ZwUserCreateWindowEx函数进入内核模式。
   3. 内核驱动win32kXX!NtUserCreateWindowEx从Desktop heap分配窗口对象tagWND, 并以窗口的句柄（HWND）类型返回给调用方。。。。
窗口管理简介：从Windows Vista开始，每个Session是隔离的，Session 0（是一个特殊session）运行着系统服务，应用程序运行在由用户登录系统后创建的一系列Session中。Session 1对应于第一个登陆的用户，Session 2对应于第二个登录系统的用户，以此类推；每个系统Desktop对象都有heap 与之对应，Desktop对象使用heap存储菜单、窗体等。  这里不多介绍。

难点： @4 提到win32kfull!NtUserConsoleControl需要传入窗口句柄，使用句柄调用ValidateHwnd转换成对象后修改tagWND->flag；可漏洞需要在调用CreateWindowEx过程里调用NtUserConsoleControl，此时CreateWindowEx并没有返回HWND！！！

分析win32kfull!NtCreateWindowEx的HWND的创建过程。
2.1  

2.2 分析win32kbase!HMAllocObject

第204行代码可以看出HMAllocObject调用Type类型为Window时所采用DesktopAlloc桌面堆进行分配。

2.3 User32!HMValidateHandle函数

HMAllocObject创建了桌面堆类型句柄后，会把tagWND对象放入到内核模式到用户模式内存映射地址里。 为了验证句柄的有效性，窗口管理器会调用User32!HMValidateHandle函数读取这个表。函数将句柄和句柄类型作为参数，并在句柄表中查找对应的项。如果查找到对象, 会返回tagWND只读映射的对象指针，通过tagWND这个对象我们可以获取到句柄等一系列窗口信息。

HMValidateHandle是个未公开函数，可以用IsMenu第一个call定位此函数。

第179行代码可以看出tagWnd + 0 保存着创建句柄。

第180行代码可以看出tagWnd + 8 位置保存着tagWND地址与桌面堆地址的偏移。

第526行代码我们可以看出系统使用HMAllocObject创建tagWND，其参数分别为pticurrent当前线程信息 ,Object为ptiCurrent->rpdesk，Type类型1为Window, 空间大小(此类型无意义，会使用用户句柄表获取类型大小)

第540行代码是一些对tagWND信息初始化。

难点解决
好在回调user32!_xxxClientAllocWindowClassExtraBytes函数时候内核已经调用完了win32kbase!HMAllocObject，此时HWND已经存放在内存之中。我们可以创建足够多的窗口让其泄露tagWND映射的对象指针，然后再摧毁大多数窗口使得桌面堆能回收这些对象空间。目前我们已经获取了这些休闲的对象地址，当我们再创建一个窗口时候桌面堆会优先使用休闲空间，我们只需要在hook user32!_xxxClientAllocWindowClassExtraBytes时候搜索查找刚刚摧毁掉的窗口tagWND指针，根据一些特征识别指定窗口就能或者到HWND了！！！

POC开发关键代码

此时我们已经能复现漏洞POC，但是距离开发Exploit利用还有很长距离，因为我们还不能读写内核内存，也不知道内核内存位置。我们还需要内核地址泄露跟如何读写内核。
因为要根据HWND操作内核，所以我们重点应该分析相应以HWND为参数的设置型函数。

第114行代码可以看出调用User32!SetWindowLong函数时候输入的第二个参数nIndex必须小于偏移0xC8(tagWND->cbWndExtra),不然就返回错误代码0x585。**

第153行代码可以看出如果tagWND->flag值包含0x800属性使用offset寻址。

第154行代码可以看出是使用offset寻址。

第156行代码可以看出是使用内存地址。

第157/158行代码可以看出是替换设置的新值。

从代码看tagWND->flag值包含0x800属性情况下只要我们有办法把tagWND->cbWndExtra改成一个很大很大值(0xFFFFFFFF)就可以使用桌面堆加nIndex来写入指定堆地址（把这个值改成最大是为了更安全防止碰到偏移过大）。

前面@7 3.2.2提到tagWND->8地址里包含内核tagWND地址与桌面堆地址的偏移，漏洞可以一次性控制偏移0x128的tagWND->offset，这样只需要把一个正常窗口的(tagWND->8,内核tagWND地址与桌面堆地址的偏移) 放到漏洞窗口里，我们对漏洞窗口做nIndex(tagWND->cbWndExtra大小内)操作就能修改正常窗口里的tagWND->“nIndex”信息，解除tagWND->cbWndExtra长度过小限制后，我们用这个解除限制的窗口操作nIndex可以对其他窗口桌面堆实现越界写入。

@6.1 我们已经可以修改指定窗口tagWND信息，用内存越界方式写入一个tagWND->flag值不包含0x800属性窗口把偏移0x128(g_dwModifyOffset_offset)改成想要写入的地址，然后用nIndex==0操作这个tagWND->flag值不包含0x800属性窗口就能实现内核写入。
我们可以对tagWND进行修改后可以使用很多API进行读写，不局限于SetWindowLongPtr。

我们使用的是User32!GetMenuBarInfo函数进行内核读取，因为可以读取16个字节（我们使用其中8字节），使用User32!GetMenuBarInfo函数进行内核读取需要控制tagWND->spmenu, 所以我们替换了spmenu。

可以对tagWND进行修改后可以使用很多API进行读写，不局限于User32!GetMenuBarInfo。

第87行代码可以看出参数idObject需要传入一个-3。

第89代码处对tagWnd->Style做了判断不能包含WS_CHILD。

第91行代码处获取tagWND->spmenu信息。

第104行代码处参数idItem需要传入一个大于0值。

第109行代码处是一个tagWND->spmenu->rgItems指针。

第118/120/…行代码处是根据tagWND->spmenu->rgItems指针内容读取偏移信息。
满足上面条件后才能实现任意读取内存信息。

目前我们可以操作任意内核内存读写，但只能搞搞蓝屏，所有还需要一个内核地址泄露漏洞。

经过分析，窗口中菜单spmenu对象包含了内核结构地址。

第110行代码可以看出参数idObject需要传入一个-12。

第112代码处对tagWnd->Style做了判断包含WS_CHILD。

第114代码处对读取窗口tagWnd->spmenu对象。

第116代码处对修改窗口tagWnd->spmenu对象。

我们需要构造符合上面条件的代码。

根据@6.4 提到的pSPMenu对象泄露的内核地址，我们可以从中一步步定位到我的EProcess。

定位到自己EPROCESS后遍历EPROCESS->ActiveProcessLinks链表，获取进程ID为4的进程后复制该进程的Token到我的Token。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！