CVE-2021-40444-Microsoft MSHTML远程命令执行漏洞分析（四）- 完结篇（文末有彩蛋）

接上文：

第一部分：样本分析

QCyber，公众号：且听安全CVE-2021-40444-Microsoft MSHTML远程命令执行漏洞分析（一）

第二部分：漏洞复现

QCyber，公众号：且听安全CVE-2021-40444-Microsoft MSHTML远程命令执行漏洞分析（二）

第三部分：漏洞分析

QCyber，公众号：且听安全CVE-2021-40444-Microsoft MSHTML远程命令执行漏洞分析（三）

本系列最后一篇主要对CVE-2021-40444漏洞补丁进行对比分析，并在调试分析过程中发现了新的漏洞点。

补丁概述

微软不出意料在9月15日发布了月度补丁，修补了该漏洞。根据前面的分析，我们主要关注`urlmon.dll`、`cabinet.dll`、mshtml.dll、`jscript9.dll`等模块的补丁情况，实际上补丁后只有`urlmon.dll`和`mshtml.dll`发生了变化：

补丁点1-`mshtml!ShellExecURL`

打完补丁后，我们尝试再调试一遍整个流程，看看执行流程有什么不同，根据前面分析时的调用堆栈（如下图），我们尝试将断点下在`urlmon!SetInstallScopeFromFile`这个函数（如果能断下来，后面就是熟悉的分析流程，这样比较理想）。

令人难过的是居然没有断下来，说明根本就没有走到这。于是我们继续向前回溯，尝试直接断在`urlmon!CDL_PacketProcessProc`这个函，确实能够断下来，但是经过简单跟踪，发现这不是cab包的处理流程。没办法只能继续往前追溯，经过反复对比，我们发现补丁前后执行几乎一致的最后一个函数是`mshtml!ShellExecURL`，调用堆栈如下图：

在`ShellExecURL`中，会调用`iertutil!CUri::GetAbsoluteUri`来获取待执行文件的路径：

单步执行后发现，得到的路径确实是我们写在`side.html`中的路径`.cpl:123`（可以参考第一篇分析文章），因此基本可以断定补丁后整个处理流程到现在为止应该还是比较正常的。

再往后执行就不一样了，在补丁前，`ShellExecURL`后面就是直接调用`shell32!ShellExecuteW`了，但是补丁后对在执行`ShellExecuteW`前增加了一些的检查，使`.cpl`这类路径无法执行了，这个通过静态补丁对比看得比较清楚。`ShellExecURL`补丁前：

`ShellExecURL`补丁后：

也就是说补丁后通过会调用`GetSchemeName`来获取一个模式名称，根据调试结果该函数取得的名称是".cpl"，然后利用`IsValidSchemeName`来判断是否合法。`IsValidSchemeName`要求字符串第一个字节必须是英文字母，而".cpl"第一个字母不符合要求，因此验证失败，导致后面无法正常进入`ShellExecuteW`。

补丁小结：在调用`ShellExecuteW`前通过过滤执行路径中的模式名称（`SchemeName`），使".cpl"类型的路径无法正常执行。

补丁点2-`urlmon!catDirAndFile`

根据补丁对比，我们注意到`urlmon.dll`中的`catDirAndFile`函数也被修补了，因为可以看到该函数中增加了一个字符替换，其实就是将路径中"/"替换为""。`catDirAndFile`函数补丁前：

`catDirAndFile`函数补丁后：

做个实验看一下这个修补点，具体做法就是在打过补丁的机器上将`mshtml.dll` 替换为未打补丁的版本（这样可以绕过`mshtml!ShellExecURL`函数中的补丁，执行到`urlmon!catDirAndFile`），这样我们成功进入`catDirAndFile`的执行流程。执行替换"/"前，路径名如下：

执行替换"/"后，路径名如下：

后面的`PathCchCanonicalizeA`函数会将路径中的`.. `进行简化处理（**注意**：不会对`../`进行处理），也就是最后的路径会转化为`C:UsersuserAppDataLocalTempchampionship.inf`，最后还有一个判断函数`PathIsPrefixA`。

而这个`PathIsPrefixA`位于`kernelbase`模块中，主要功能是判断`pszPrefix`是不是`pszPath`的路径前缀，此时`pszPrefix`为`C:UsersuserAppDataLocalTempCab60A9`，而`pszPath`为`C:UsersuserAppDataLocalTempchampionship.inf`，因此`PathCommonPrefixA`返回的公共前缀长度为只有32字节，与`pszPrefix`的长度40字节不相等，因此最后返回`FALSE`，导致整个inf文件的创建过程中断。

补丁小结：通过将路径中的"/"字符替换为""，使`urlmon!PathCchCanonicalizeA`能够正常进行路径简化，导致在验证路径前缀的时候不匹配，因此inf文件无法正常创建。

补丁点3-在调试过中发现的新漏洞

`ieframe`模块本来不在我们的补丁分析计划中，但是在调试过程中，我们偶然发现9月补丁后在特定情况下会触发一个未公开的程序崩溃点，因此我们决定来分析一下这个补丁点，下面是这个崩溃点的现场：

在这个崩溃点，我们看到了一个熟悉的函数名`IsValidSchemeName`，这不就是补丁点1中增加的判断函数么。通过补丁分析，可以发现在IEFRAME!CProtocolWarnDlg::_SetProtocolHandlerInfo`函数也增加了一个类似的判断。

`_SetProtocolHandlerInfo`补丁前：

`_SetProtocolHandlerInfo`补丁后：

简单分析后我们得知，漏洞的根本成因是`IsValidSchemeName`需要的参数类型是`OLECHAR*`，该类型在字符串的前4字节存放了字符数量，但是`ieframe`模块在申请`schemeName`的地方调用的是`shcore!SHStrDupW`，其返回的参数类型是`LPWSTR*`，最终导致类型混淆。

在`IsValidShemeName`函数中调用`OLEAUT32!SysStringLen`的时候，将字符串前4个字节作为字符数量，导致取到非法的长度值：

总结一下：

• 针对【目录穿越漏洞】，微软有针对性的对"../"进行了替换，但依然依赖于`PathIsPrefixA`函数的判断；

• 在多个模块中增加`IsValidShemeName`函数，对路径类型进行了过滤，降低了安全风险

• 对于【文件驻留漏洞】，并没有给出相关的补丁

• 补丁虽然能够防止本漏洞被利用，但是也带来了非预期的安全风险（发现了新的崩溃点）

写在最后

针对`CVE-2021-40444`的分析基本就结束了，由于篇幅和时间原因，调试过程中的许多细节无法一一都记录下来，其实还有很多值得深入挖掘的地方，如果大家感兴趣，强烈建议自己动手去调试一遍，肯定会有更深刻的理解，也可能会有意外的收获。

由于传播、利用此文档提供的信息而造成任何直接或间接的后果及损害，均由使用本人负责，且听安全团队及文章作者不为此承担任何责任。

点关注，不迷路！

原文始发于微信公众号（且听安全）：CVE-2021-40444-Microsoft MSHTML远程命令执行漏洞分析（四）- 完结篇（文末有彩蛋）