Windows DHCP服务器远程代码执行漏洞分析及利用方法（CVE-2019-0725）

概述

在2019年5月14日，微软发布了月度安全补丁，其中包含一个Windows终端服务漏洞（CVE-2019-0708），这一漏洞可能将成为今年最令人担忧的漏洞之一。但是，在此次更新中，同时还存在一个难以忽略的远程代码执行（RCE）漏洞——Windows DHCP服务器中的远程代码执行漏洞（CVE-2019-0725）。值得注意的是，在今年的微软月度补丁中，与DHCP相关的漏洞引起了大家更为广泛的关注，一个比较典型的例子就是在今年2月在DHCP服务器上修复的另一个远程代码执行缺陷（CVE-2019-0626）。

要利用Windows DHCP服务器远程代码执行漏洞（CVE-2019-0725），不需要进行任何用户交互，并且此漏洞将影响所有版本的Windows Server。

那么，CVE-2019-0725究竟有多严重，它的利用方法又有多简单呢？我们将在本文进行具体阐述。

CVE-2019-0725的影响

Microsoft对CVE-2019-0725漏洞的CVSS 3.0评级为8.1（基本评分）。成功的攻击将允许系统级别的代码执行，同时会对系统的机密性、完整性和可用性都造成较高程度的影响。在所有版本的Windows Server中都存在该漏洞，并且漏洞严重程度都被评为“严重”。此外，攻击者无需特权，即可进行一次成功的攻击。

但是，该攻击的复杂度（Attack Complexity）评级很高，这意味着其中的一个主要因素可能是该漏洞没有完全受到攻击者的控制。基于这种情况，这样的评级，有一部分是因为该漏洞是由竞态条件（Race Condition）引起的Use-After-Free，也就是由影响其他操作事件的意外时间而引起的缺陷。

这种竞态条件如何实现呢？我们首先需要了解通常情况下通过DHCP分配地址的方式。

希望被分配IP地址的客户端，首先发送DISCOVER消息，通常会发送到广播地址（硬件层的FF:FF:FF:FF:FF:FF，IP层的255.255.255.255）。如果同一广播域中有DHCP服务器，并且它具有可分配的IP地址，那么它将会以OFFER消息进行响应。该消息中，包含客户端应使用的IP地址的详细信息，以及DNS服务器等其他信息。

然后，DHCP客户端发送REQUEST消息，其中包含有关客户端的其他信息，并确认客户端请求的IP地址（通常是服务器在OFFER消息中发送的地址）。如果服务器接受来自客户端的REQUEST消息，那么它将发送DHCP ACK，以通知客户端它当前可以使用分配的IP地址。我们需要记住上述这些原理，在此基础上，我们继续详细分析漏洞的本身。

触发竞态条件和Use-After-Free

DHCP服务器在dhcpssvc.dll中实现，并通过svchost.exe运行。传入的DHCP消息由ProcessMessage()函数处理。它首先调用一个函数，从传入的消息中提取DHCP选项。这是因为，DHCP选项包含请求的IP地址、主机名、DHCP消息类型等信息。其中的DHCP消息类型最为重要，例如DISCOVER或REQUEST。ProcessMessage()将根据DHCP消息类型调用处理函数。如果消息类型为DISCOVER，在这种情况下，调用的函数将会是ProcessDhcpDiscover()，这是与漏洞相关的问题函数。DHCP服务器在dhcpssvc.dll中实现，并且通过svchost.exe运行。

ProcessMessage()检查DHCP消息类型：

Windows DHCP服务器跟踪“待处理”（Pending）的IP地址租约。这意味着，IP地址已经在内部分配给客户端，但不一定会提供给客户端，也不一定被客户端所接受。为了跟踪这些待处理的租约，DHCP服务器使用PendingCtxt结构的引用列表。这些PendingCtxt结构包含在基于堆的缓冲区中，包括客户端硬件地址、租约（Lease）、续订和重新绑定时间（Renewal and Rebinding Time）、分配给客户端的IP地址、是否为此特定租约发送了OFFER标志等信息。在第一次调用ProcessDhcpDiscover()时，它会检查其是否具有现有的PendingCtxt。具体而言，是通过使用客户端硬件地址来实现此目的，客户端硬件地址位于DHCP头部中，作为函数DhcpFindPendingCtxt()的参数。

如果没有为特定客户端找到当前的PendingCtxt，则会从可用地址池中分配地址，或者直接将先前分配给该客户端的地址再次分配给它。随后，将调用函数DhcpProcessDiscoverForValidatedAddress()，以执行构造，响应DISCOVER发送的OFFER消息所需的其他任务。

DhcpProcessDiscoverForValidatedAddress()会检索配置的租约信息，例如服务器上配置的租约、续订和重新绑定时间。然后，这一函数将检索到的上述信息以及提供的IP地址和子网掩码传递给函数DhcpAddPendingCtxt()。DhcpAddPendingCtxt()函数为新的PendingCtxt结构分配了一个基于堆的缓冲区，该结构中包含待处理的租约信息，随后会添加到所有待处理租约的列表中。

DhcpAddPendingCtxt()中PendingCtxt结构的分配与填充：

在添加PendingCtxt结构后，将会在函数DhcpRespondToDiscover()中构造OFFER消息，并将其发送到客户端。

因为PendingCtxt结构理论上可以在任何时间点，由多个服务器线程访问，所以对结构的访问通常包含在DhcpGlobalInprogressCritSect的关键部分（Critical Section）之中。这样的实现方式，是为了通过仅允许一个线程或进程在任何特定时间运行在关键部分中，从而防止由于共享访问相同资源而导致的意外行为。在ProcessDhcpDiscover()中，在调用DhcpFindPendingCtxt()之前会进入到DhcpGlobalInprogressCritSect的关键部分。如果没有PendingCtxt，或者在现有PendingCtxt结构中的某些信息被验证之后，线程将会离开关键部分。

在现有PendingCtxt结构中，进入关键部分的初始操作：

但是，在线程离开这个初始关键部分之后，还存在一个由位于RBX寄存器中地址引用的PendingCtxt结构的直接访问。该访问将会检查“OFFER标志”的值，从而确认是否已经将OFFER发送到客户端上。尽管这种直接访问受到另一个关键部分的保护，但是在离开上一个关键部分之后和进入到下一个关键部分之前，有一个很小的窗口期（如下图中重点标记部分所示）。

PendingCtxt结构中关键部分之间保护的说明：

由于线程调度的不可预测性，不能保证PendingCtxt结构仍然会存在。删除PendingCtxt结构的线程可以选择在ProcessDhcpDiscover()离开第一个关键部分之后、进入到下一个关键部分之前进行。当再次访问PendingCtxt结构时，该竞态条件可以导致在空闲后使用。

目前，有几种情况可能会导致PendingCtxt结构被释放，这是由DhcpDeletePendingCtxt()函数执行的一个任务。PendingCtxt可能会过期并被清理，导致攻击者无法控制。但是，如果发送带有服务器无法分配的请求IP地址的REQUEST消息或RELEASE消息，将导致调用DhcpDeletePendingCtxt()，并释放先前分配的堆缓冲区。

DhcpProcessRelease()查找现有的PendingCtxt，一旦发现存在，则会立即删除：

漏洞利用

攻击者可以通过发送至少两个DISCOVER消息来触发Use-After-Free。其中，一个用于创建初始PendingCtxt，另一个用于查找和访问创建的PendingCtxt。攻击者还必须发送具有完美定时的RELEASE或精心制作的REQUEST消息。

实际上，在第一次尝试时，不太可能触发这样的竞态条件。攻击者可能必须同时发送大量DISCOVER和RELEASE或REQUEST消息。我们的测试显示，需要10秒到几分钟不等的时间才能触发静态条件。实际上，我们的客户端也持续发送了非常不常见的DHCP消息。

尽管触发漏洞看起来非常容易，但实际上，在Use-After-Free之后获得代码执行是非常具有挑战性的，必须要保证所有的前提都成为现实。攻击者需要在网络上产生大量流量，这样才能具有一定的机会。但是，由于触发漏洞可能会导致DHCP服务器的服务崩溃，攻击者可能会使用此拒绝服务功能来运行恶意DHCP服务器，并执行DNS缓存中毒等攻击。与任何高危漏洞一样，我们强烈建议组织及时对漏洞进行修复，并及时更新Microsoft DHCP服务器，以进一步减少其攻击面。