CVE-2021-40449|CVE-2021-40449 NtGdiResetDC UAF CVE-2021-40449NtGdiResetDCUAF

背景 ??CVE-2021-40449是一个存在于Win32k内核驱动中的UAF漏洞。该漏洞在2021年八月下旬九月上旬被Kaspersky发现用于野外攻击活动中。通过Hook win32k驱动执行NtGdiResetDC过程中发生的用户模式回调，完成对目标对象的释放和占用，最终实现指定内核函数的调用，以进行内核内存的读写操作，修改利用对象的Token权限，实现EOP。
分析 ??此次分析是在Windows 10 1809中进行。
??首先在用户模式调用CreateDC时，会执行至win32k内核调用win32kfull!NtGdiResetDC，再执行至win32kbase!hdcOpenDCW，调用堆栈如下：

......??win32kbase!PDEVOBJ::PDEVOBJ
......??win32kbase!hdcOpenDCW+0x240
......??win32kfull!GreResetDCInternal+0x11a
......??win32kfull!NtGdiResetDC+0xd6
......??nt!KiSystemServiceCopyEnd+0x25
......??win32u!NtGdiResetDC+0x14
......??gdi32full!ResetDCWInternal+0x16b
......??GDI32!ResetDCW+0x31
......??CVE_2021_40449!main

【CVE-2021-40449|CVE-2021-40449 NtGdiResetDC UAF】??执行的用户回调主要发生在win32kbase!PDEVOBJ::PDEVOBJ中，该函数应是一个PDEV对象的初始化函数，和win32kfull!NtGdiResetDC传入参数中的HDC有关联。初始化函数中有两个用户回调：PDEVOBJ::EnablePDEV、PDEVOBJ::CompletePDEV。这两个用户回调主要是对HDC中的PDEV对象进行操作，PDEV对象通过PDEV::Allocate分配内存。

文章图片

文章图片

??执行完初始化函数，回到hdcOpenDCW，继续执行至GreCreateDisplayDC，该函数初始化一个PDC对象，并将上面初始化的PDEV对象的内存地址放到PDC偏移+0x30处。

文章图片

??然后返回PDC 0偏移处的DC句柄值HDC，该值也作为win32kbase!hdcOpenDCW的返回值，返回值win32kfull!GreResetDCInternal。
??hdcOpenDCW返回的HDC传入DCOBJ::DCOBJ，返回hdcOpenDCW初始化的PDC对象的内存地址。

文章图片

??接着读取PDEV对象0xAB8偏移处的函数指针并执行，注意此处的PDEV并不是在上一步的hdcOpenDCW中初始化的，而是在用户态调用ResetDC前，调用CreateDC生成的。为进行区分，本文中将其称为HDC_user。
??GreResetDCInternal的函数参数HDC_user，同样通过DCOBJ::DCOBJ返回PDC_user对象，该对象偏移0x30处为PDEV_user对象的内存地址。
??取PDEV_user偏移0xAB8处函数指针，执行UMPDDrvResetPDEV，传入参数分别为PDEV_user和PDEV_kernel偏移0x708处的指针，指向各自的DEVMODE结构，这里同样会发生一次用户态函数回调，不过该回调不进行考虑，因为此漏洞利用范围内，被利用的主要是该指针。

文章图片

??完成UMPDDrvResetPDEV回调后，执行win32kbase!HmgSwapLockedHandleContents，该函数会将PDC_user和PDC_kernel首部的HDC值和PDC的引用计数值进行了互换，从而完成devmode修改的功能。

文章图片

??后面则是将两个PDC对象的引用计数值分别减1，并调用win32kbase!bDeleteDCInternal将HDC_kernel索引到的PDC对象偏移0x30处指针指向的PDEV对象引用计数值减1，值变为0。而又因为之前的HmgSwap操作，这里的PDC和PDEV实际都是用户传入的HDC原本指向的对象。
??根据MSDN所说，“当该计数器降至零，该对象就会被释放”、“一旦句柄计数减为零，对象的名称就会从对象管理器的命名空间中删除”。意味着该对象可以被占用，而hdcOpenDCW中又存在用户回调，在用户回调中再对相同的HDC执行一次ResetDC，那么该HDC对应PDEV对象引用值将减为0，占用该PDEV对象后结束回调，回到内核。
??至于漏洞的触发点，在原本的UMPDDrvResetPDEV调用处，该调用发生在hdcOpenDCW之后，调用函数的地址从PDEV_user中获取，通过占用，可以获取到修改器调用目标为一个内核读写函数。

文章图片

利用 ??该UAF漏洞的利用主要为以下几个步骤：

使用NtQuerySystemInformation获取利用进程Token.Privileges在内核中的位置；
泄露出一个可以用于内核写的内核函数，这里比较通用是nt!RtlSetAllBits；
构造一个Fake_RTL_BITMAP，作为nt!RtlSetAllBits函数参数，大多使用ThreadName的方式进行构造，不过同样也可以手动申请一片用户态内存进行构造；
HOOK用户回调DrvEnablePDEV（Hook DrvCompletePDEV虽然可以成功占用，但执行不到漏洞触发点），在Hook函数中对相同HDC再执行一次ResetDC，返回后使用构造的Fake Palette去占用被释放的PDEV对象，然后结束当前回调；
漏洞触发，当前进程权限位全部被启用，完成提权。

??在Hook函数中完成占用后的内存布局前后对比如下所示：

文章图片

??PDEV对象占用成功后，完成回调，返回GreResetDCInternal，可以看到成功地调用到nt!RtlSetAllBits。

文章图片

??nt!RtlSetAllBits中仅将rcx作为参数，而漏洞触发处的第一个参数rcx同样可以通过占用指定。
??nt!RtlSetAllBits中取rcx地址0x08偏移处的QWORD作为写入的目标地址，而rcx偏移0处的DWORD值整除0x40后作为计数值，每次向目标地址写入rax寄存器的值，rax固定为0xffffffffffffffff。

文章图片

文章图片

??POC代码。
总结 ??这次我分析这个漏洞时尝试尽量不看网上公开的POC，仅根据Kaspersky的文章寻找漏洞位置，结果花了很多时间，遇到挺多问题的。比如寻找漏洞点时，不会出现BSOD，并且!pool不能马上看到对象内存状态变成free，还是去瞄了一些公开的POC，确认自己方向没问题。
??emmm最后好歹自己完成了POC，虽然耗时长且代码拉胯，相比那些优秀的POC通用性低，但是收获也很多，起码漏洞前后附近的代码各个角落都翻了一遍，而且一些坑下次可以避免。
参考 [1] MysterySnail attacks with Windows zero-day
[2] CVE-2021-40449 Exploitation