该漏洞的成因及利用基本上和CVE-2021-1732一样，可以认为该漏洞是在对CVE-2021-1732漏洞进行补丁之后，绕过该补丁达成漏洞利用。在对CVE-2021-1732补丁后，在xxxCreateWindowEx函数调用过程中，会在调用xxxClientAllocWindowClassExtraBytes申请扩展内存后，会对窗口对象的偏移0x128处的pExtraBytes进行验证，以此来验证是否在执行用户层函数时被修改。然而，该补丁仅针对xxxCreateWindowEx函数，在后面的Windows版本中，出现了新的函数会调用xxxClientAllocWindowClassExtraBytes函数，而这些函数没有对pExtraBytes进行验证，导致可以通过这些新函数来实现对窗口对象偏移0xE8的Flags以及0x128的pExtraBytes进行修改。

操作系统：Win10 x64 21H2 专业版

编译器：Visual Studio 2017

调试器：IDA Pro, WinDbg

在对CVE-2021-1732进行补丁之后，xxxCreateWindowEx函数会在申请扩展内存之后，会调用tagWND::RedirectedFieldpExtraBytes::operator函数来对窗口对象进行验证，如果该函数返回1，则函数接下来就会释放窗口对象，然后直接退出函数，而不执行下面的对pExtraBytes成员的赋值：

xxxCreateWindowEx调用tagWND::RedirectedFieldpExtraBytes::operator验证函数的时候，传入的是tagWND + 0x140和值为0的zero这两个参数，而验证函数代码则如下，所以该函数就是在验证*(*(tagWND + 0x140 - 0x118) + 0x128) = *(*(tagWND + 0x28) + 0x128)是否不等于NULL，就是在验证pExtraBytes是否已经被写入，因为在xxxCreateWindowEx函数会在验证通过之后才为pExtraBytes成员赋值，如果验证时候该值已经不为NULL，就说明在用户层函数被劫持了：

然而，该补丁是打在xxxCreateWindowEx函数中，函数xxxClientAllocWindowClassExtraBytes并没有任何变化，该补丁可以在原来的系统中起到保护作用。可是在之后的系统中，增加了不同的函数可以调用xxxClientAllocWindowClassExtraBytes，其中就包括了xxxSwitchWndProc。因此可以通过该函数来实现对窗口对象的Flags和pExtraBytes成员进行修改，最终达成利用：

在xxxSwitchWndProc函数中，会判断窗口对象是否存在扩展内存，如果存在扩展内存，则会调用xxxClientAllocWindowClassExtraBytes函数来申请内存。随后，函数会重新为pExtraBytes成员进行赋值，并调用xxxClientFreeWindowClassExtraBytes函数将原来pExtraBytes指向的内存释放掉。因此，可以通过xxxSwitchWndProc函数来实现xxxClientAllocWindowClassExtraBytes函数的调用，并通过劫持相应的用户层函数，可以实现对pExtraBytes的修改：

通过交叉引用可以看到，xxxSwitchWndProc函数由xxxWrapSwitchWndProc函数调用的。

xxxSwitchWndProc函数则由NtUserMessageCall函数开始一步步调用到，该函数的定义如下：

当msg小于0x400的时候，将会根据msg，从MessageTable数组中取出相应的下标，在使用该下标从gapfnMessageCall数组中找到要执行的函数：

当msg为WM_CREATE(0x1)的时候，从MessageTable中取出的下标将为4：

gapfnMessageCall数组中，下标为4对应的函数为NtUserfnOUTSTRING：

NtUserfnOUTSTRING函数会将(dwType + 6) & 0x1F得到的下标从mpFnidPfn数组中取出要执行的函数：

mpFnidPfn数组在InitFunctionTables函数中被初始化，其中下标为6的元素就被初始化为xxxWrapSwitchWndProc函数。因此，当参数dwType为0的时候，NtUserfnOutSTRING函数就会调用xxxWrapSwitchWndProc函数：

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