新宝6CVE-2019-0697:通过DHCP漏洞发现其余两个关键漏洞_HUC惠仲娱乐

新宝6

在前文中我们已经讨论过关于CVE-2019-0726的相关内容。我们知道,有时候在搜索某一个已知漏洞的时候便会偶然发现新的漏洞,有时这种漏洞还不止一个。

本文讨论了dhcpcore.dll的两个函数:在传递消息时使用的UpdateDomainSearchOption,,以及由第一个函数连续调用的DecodeDomainSearchListData。我们在寻找函数漏洞的时候总会发现,即使某种函数只拥有一两种功能但是也需要我们审计大量的代码。偶然间发现的一些无关紧要的小细节往往会在后面的分析中有其他意义,或者可能在以后变得有用。即使现在没有深入分析,但是由于注意到了这个地方,过了一段时间你会有机会回去检查你的猜测。

这正是这次发生的事情。在研究负责处理来自服务器的DHCP响应中的所有选项的DhcpExtractFullOptions函数时,特别是调用UpdateDomainSearchOption的选项时,我们注意到了堆栈上的两个数组,而每个数组包含256个元素:

没有任何检查限制这些数组的迭代器值的迹象。 当时我们正在分析一个不同的漏洞,因此这些信息无关紧要。 因此,我们所能做的就是记住这部分代码以供日后使用。

分析

几周后,我们回想起之前引起我们注意的DhcpExtractFullOptions函数。 我们把它放在一个反汇编程序中,计算出那些未完全解析的代码片段,并试图找出这两个静态数组的用途。

当函数执行开始时,数组及其迭代器被清零:

该函数解析从DHCP服务器接收数据包中的所有选项,从中收集信息并对其进行处理。 此外,根据解析结果,它会在ETW(Windows事件跟踪)服务中记录相应的事件。 记录事件正是我们查看的缓冲区位置。 除了大量数据外,还会将这些数据传递给EtwEventWriteTransfer。 准备所有数据以进行日志记录需要大量工作。然而与我们正在讨论的漏洞无关,因此我们将跳过这些示例。

这里我们看看这些缓冲区是如何填充的。 填充是选项解析周期的一部分。 首先,为接收进行处理的当前选项调用具有自解释名称ParseDhcpv4Option的函数。 它使用接收的数据填充dhcp_pointers对象中的字段,或者如果遇到没有处理程序的选项标识符,则记下未知选项。

从ParseDhcpv4Option返回后,当前选项option_tag的标识符值将写入all_tags数组的下一个元素,即我们正在查看的第一个数组。如果函数遇到未知选项,因此未设置is_known_option标志,则标识符的值也会写入第二个array-unknown_tags的下一个元素。当然,本文中提到的变量只有在代码分析后才能得到有意义的名称。

因此,all_tags数组存储来自接收消息选项的标记,而unknown_tags数组仅包含解析器未知的选项标记,除此之外,它根本没有检查数组的索引。因此,这些索引的值可能超过256,并导致在堆栈上为阵列分配的内存之外进行写入。要导致第一个阵列溢出,DHCP服务器发送超过256个选项的数据包就足够了。对于第二个阵列也是如此,唯一的区别是我们需要发送客户端的选项无法被处理。

攻击过程

现在让我们试着在实践中测试我们的理论结论。 首先,选项标记的大小为一个字节,而数组元素的类型为int,这意味着元素大小为四个字节。 因此,我们有一个溢出,我们控制每个第四个字节,其余的在覆盖时归零。

测试漏洞的最简单方法是覆盖存储在堆栈中的函数的安全cookie,这将导致安全检查相关的异常。 让我们模拟DHCP服务器并发送足够数量的选项以导致覆盖的情况。 假设有0x1a0选项,标识符为0xaa,大小为零。 因此每个选项的大小是两个字节,包含所有标头的数据包的总大小将是1100-1200字节。 此值在以太网的MTU限制范围内,因此我们有理由相信该消息不会被分散执行,这将有助于我们避免任何复杂情况。

我们发送以这种方式形成的数据包以响应来自DHCP客户端的请求,并且在客户端的计算机上,我们在相应的svchost.exe进程中捕获异常:

正如我们从堆栈跟踪中看到的那样,来自我们数据包的选项标识符覆盖了堆栈cookie和函数的返回地址。

当然,创建类似可用的漏洞需要攻击者付出巨大努力。在系统上由于所有现代保护机制,缓冲区堆栈溢出是一个复杂且难以利用的漏洞。另一方面,我们不要忘记所有这些机制都保护返回地址和异常处理程序不被覆盖,防止在未分配的内存位置中执行代码,或者阻止预测地址。但是,它们无法阻止在溢出缓冲区和返回地址之间覆盖存储在堆栈中的局部变量。 DhcpExtractFullOptions函数包含该范围内的几个潜在危险变量。

我们再次写信给微软,告知我们发现的错误。在一些通信之后,在分析了持续一周左右的请求后,我们得到了一个回复,说明正在准备此漏洞的CVE标识符,计划在3月发布补丁,并且该漏洞已经通过Microsoft报告其他人。

3月有一个修复故障的补丁,现在确定为CVE-2019-0697。 此前报告此漏洞的研究人员是Mitch Adair,同样是微软的员工,他发现了1月份修复的DHCP漏洞CVE-2019-0547

本文为翻译文章,来源:[http://blog.ptsecurity.com/2019/05/how-analyzing-one-critical-dhcp.html](http://blog.ptsecurity.com/2019/05/how-analyzing-one-critical-dhcp.html)