作者：[email protected]高级攻防实验室
原文链接：http://noahblog.360.cn/cve-2022-21907-httpxie-yi-yuan-cheng-dai-ma-zhi-xing-lou-dong-fen-xi-zong-jie/

背景：

2021年最近的上一个http远程代码执行漏洞CVE-2021-31166中，由于其UAF的对象生命周期的有限性，似乎并不太可能在实际场景中实现利用。今年一月的安全更新中包含另一个http的远程代码执行漏洞CVE-2022-21907，根据官方更新说明这仍是一个非常严重的漏洞，我们有必要对他在实际环境中是否可能被利用进行进一步的判断。

开始准备分析之前的两点说明：

在开始分析之前，这里有两点分析过程中的思路提示需要提前说明。可以排除其他研究人员在理解这个漏洞可能产生的一些歧义。

A,最合适的补丁对比文件。

通常来说，我们在最开始选择对比的补丁文件时，尽量选择时间间隔最小的补丁文件。但是有时候，对于补丁文件的系统版本也非常重要。本例中，如果研究者使用server2019的http文件去分析，你会发现代码有太多改动是针对一些旧版代码的相对改动，并不是所有版本系统的某一模块都是一样的。

B，漏洞产生的方向。

这里我们说的方向主要指协议过程中，服务端和客户端的数据请求方向。通常来说一个可互联网蠕虫级别的漏洞，我们首先想到的触发方式可能是客户端向服务端发送请求，之后服务端在解析请求时发生的漏洞。如cve-2019-0708RDP代码执行漏洞以及永恒之蓝。但近年来随着这类漏洞发现的越来越困难，研究人员开始向将漏洞挖掘方向偏向于协议客户端的一些接收解析模块。但该漏洞似乎更加特殊，虽然它存在于服务端，却并不是解析处理客户端的具体数据内容模块，而是处于服务端接收客户端请求之后，进行的响应发送模块。

我们似乎并不能在最简单默认的http服务端系统配置中触发此漏洞，需要服务端包含一些特定的代码逻辑，该漏洞才会有比较大的威胁。具体来说，我们的poc代码是一个普通的http服务端代码，在其上加入有一些较小改动的特殊逻辑代码。只要客户端发起正常访问，即可触发服务端崩溃。

补丁分析：

我们使用最新的windows11的补丁文件进行分析。可以比较清晰的发现漏洞可能存在于这些代码中：ULpFastSendCompleteWorker,UlPFreeFastTracker,以及UlFastSendHttpResponse.中指针使用完之后清零的操作。另外有两处不太明显的代码即是申请FastTracker对象内存的函数：UlAllocateFastTracker和UlAllocateFastTrackerToLookaside.时，初始化部分头部内存。

通过梳理http快速响应包发送流程，我们可以发现这些补丁的作用都是针对FastTracker对象中的一些指针地址所进行的。

其中主要有以下三个对象指针。

FastTracker中的LogDatabuffer对象，UriCacheEntry对象以及一个FastTrackerMDL指针。

失败的尝试:

通常来说，根据此漏洞的官方描述严重性，我们通常会先考虑这些对象是否存在UAF的情况。

我们优先分析了LogDatabuffer对象，UriCacheEntry对象的生命周期，如果仅从这两个对象的申请和释放过程判断，我们并没有找到较容易发现的触发可能的UAF错误方式。

之后开始考虑第三个FastTracker的MDL指针。

剩下的可能：

通过前面的测试结果以及分析思路，我们有留意到FastTracker本身在申请释放过程中其内存的一些变化，大致上，FastTracker对象的申请有两种情况，首先查看http响应结构中一些数据长度是否满足最低需求，以及http Tailers长度是否为空，满足条件则直接使用http内部链表对象，否则申请新的内存。问题在这里开始出现，补丁之前的代码，如果申请新内存，有一些关键偏移是没有初始化内存的。其中就包括FastTracker的MDL几个相关判断标志以及MDL本身的地址指针。

之后，思路就比较清晰了，我们需要做的就是构造这样的一个逻辑：当FastTracker申请内存成功之后，并在完全初始化MDL指针之前，故意触发一个HTTP快速响应流程中的任意一个错误，使http提前释放FastTracker对象。而这时，如果FastTracker对象中，未初始化的MDL相关指针位置包含申请内存时包含的一些随机数据，则可能导致这些随机数据被当作MDL指针进行引用。

说明：

这里需要提出一个特别注意的地方。即该漏洞与http Tailers的联系。

从表面上看，该漏洞的直接原因是新FastTracker对象重新从系统内存申请时，未初始化导致的。这样，Tailers长度是否为空作为FastTracker从系统内存申请的判断条件之一，则直接影响该漏洞是否能触发。但是如果继续分析，会发现，即使没有http Tailers的判断条件，该漏洞仍然是可以被触发的。

具体存在以下逻辑：如FastTracker对象申请流程图中，如果发现该http响应结构中不包含http Tailers，会先查询http内部链表，如有空闲对象，则使用空闲对象。这种情况下，这里仍有可能存在一种特殊情况，即内部链表被耗尽，仍需继续通过另一个UlAllocateFastTrackerToLookaside申请新的内存。不过微软已经注意到这里，同样修补了这里的FastTracker的初始化工作。但这意味着，即使http服务端没有开启支持 Tailers特性，该漏洞仍然是可能被触发的。测试之一，仅仅是增加对服务端的访问频率即可做到这一点。

poc:

如该漏洞开始分析之前的描述，该漏洞poc主要为我们自己编写的一个http服务端。该服务端唯一不同的地方，是在http响应包发送流程中，在申请FastTracker之后，在FastTracker中的UriCacheEntry对象初始化之前，使http响应流程失败，并开始销毁FastTracker对象即可。（作为示例，其中一种方式，我们在服务端代码的响应包中，加入了一个超过http限制长度的固定头字符数据使得系统认为该固定头数据无效而丢弃）。

当然，要达到这个目的还有很多方式，还有另外的判断可以选择，。只要在这些响应包结构生成流程中（即UlFastSendHttpResponse），在如：UlGenerateMultipleKnownHeaders，UlGenerateFixedHeaders相应包结构生成的流程中出现判断失败，则该服务器代码就可能触发该漏洞。

然后触发该漏洞的方式只需要在客户端访问该端口并进入到我们服务端对应流程即可。因为我们没有刻意进行内存布局，并不是每次访问都能导致崩溃，这需要未初始化内存刚好符合FastTracker的MDL指针的一个标志判断。如下，满足v118+10的标志位为1.

漏洞触发堆栈如下：

总结：

最后，该http远程代码执行漏洞虽然在类型上仍属于UAF（use after free）,但该漏洞实现exp有两个比较重要的前提条件待解决。1是该漏洞的触发原理，需要服务端的http代码中，包含一个流程错误的构造操作使HTTP FastTracker因为意外而提前释放，这需要http服务端开发人员在他的代码中刚好包含这样的一个逻辑。2另外则是该漏洞的利用实现方式，即通过布局HTTP FastTracker的未初始化的内存，通过漏洞触发去操作我们自己伪造的MDL指针结构。为了要执行代码，除了我们可能需要继续分析一种可能的信息泄露方式（如构造读写源语或者利用MDL本身的一些机制），但我们仍有大量的后续代码执行方式上的尝试工作要做。所以，就目前短时间来说，该漏洞被利用的困难程度可能较大。

但是对于那些未启用http Tailers支持的服务器，也需要尽快更新此补丁。

参考：

https://piffd0s.medium.com/patch-diffing-cve-2022-21907-b739f4108eee

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-21907

本文由 Seebug Paper 发布，如需转载请注明来源。本文地址：https://paper.seebug.org/1899/