补丁分析

补丁比较明显，限制了DHCP中某一种消息结构的个数小于等于0x20。

PoC

A. 到底是授权还是非授权无条件代码执行？

官方已经将漏洞触发条件修改为无需授权。

参考补丁函数的代码执行路径（该函数是作为DHCPv6的一个分支进行处理的），这说明在安装了DHCP服务以后，至少该漏洞还需要一个前提。服务器必须启用了静态IPV6的地址.

参考官方部分DHCP协议相关的示例代码，发现我们以客户端的DHCP API函数（如：DhcpV6GetFreeIPAddress等）向服务端发送请求（先由135端口通过身份验证，之后才能直接与DHCP自己的端口通讯），都会返回需要DHCP服务管理权限的错误。但测试期间偶然会有一些我设置的关键断点被触发。这些断点用来监控DHCPv6协议上层的数据接收入口DhcpV6ProcessPacket（至少此时是这样认为的）。这表明可能存在其他的方式向DHCPv6协议发送数据。然后通过Wireshark对所有在调试断点触发前后一段时间内捕获的DHCPv6协议数据过滤分析。发现了DHCPv6中的另一种数据处理形式：DHCPV6广播。

借助GPT给出的DHCPv6相关标志，特征，以及示例代码，快速构造一个DHCPv6广播发送的示例，参考Wireshark来纠正我们DHCP数据包内容，尝试使其到达漏洞函数ProcessRelayForwardMessage。

这里需要注意，其他类型的DHCPv6广播都能直接被DhcpV6ProcessPacket 最上层的处理函数接收，但是我们关注的最关键的DHCP标志为0x0c的中继转发消息却并不被接收。

梳理DHCP的消息循环机制，我们发现DhcpV6ProcessPacket这里并不是消息最初被接收的地方。我们构造的DHCP中继转发消息在DhcpV6MessageLoop就被丢弃了。这样我们构造的DHCPv6中继转发消息不仅需要符合漏洞函数本身的验证需求，在此之前我们还需要保证DHCPv6中继转发消息在DhcpV6MessageLoop验证正确（这里绝大部分数据验证，构造过程，主要依赖Wireshark对DHCP数据报的识别）。

一系列错误尝试之后，我们得到了一个可以触发到补丁所在变量的代码路径方式。

然后一切都好了吗？

B. 如何触发漏洞？

引用我们最开始对补丁的描述，并经过前一步对DHCPv6相关协议的了解我们已经知道补丁修补是限制DHCPv6中的hopcount（本文的分析中，我们将hopcount侠义的理解为中继转发消息个数）个数不能大于等于0x20。 Hopcount的实际意义在这里并不重要，但想要了解可以参考下面的解释。

在ProcessRelayForwardMessage全局，hopcount是一个循环累加的过程。然而通过这种方式，我们无论如何也不能把hopcount累加到一个超过0x20的值。

并且补丁中已经存在2处可以限制hopcount个数的判断。如下：

一是函数入口时对延迟消息包中第一个中继转发结构中声明的中继转发消息个数的判断。

二是每次判断完一个中继转发消息的类型标志后，都会验证已经保存的中继转发消息头个数是否和下一个中继转发消息头中的个数匹配。这里似乎完全不能出现因为中继转发消息累加或者个数判断出错的情形。

那到底这个漏洞到底是如何触发，补丁的意义有是什么呢？

C. 重新收集信息

参考赛博昆仑给出的崩溃堆栈截图，对照函数偏移，很明显他们也是使用的server2022的系统版本，我们能比较准确的确定最后崩溃的地址，然后倒推原因。

根据崩溃地址，这是一个越界读。我们能确信的一点，就是全局变量中的那个数组计数变量绝对是一个远大于0x20的变量。而这个变量又是如何被错误的修改过呢？

我们已经排除通过构造中继转发消息头里面的个数，以及本身累加过程中出现错误的可能，

我们现在就需要寻找该变量可能被修改的地方。

通过在调试时观察中继转发消息数据复制的过程以及我们关注的目标变量在DHCPv6内存中的位置偏移，终于我们意识到一种可能。漏洞并不是依靠构造消息头的标志或者DHCPv6协议本身的流程控制关键的hopcount值，而是通过第33个中继转发消息的数据去直接覆盖掉hopcount这个值的内存。

到这里，PoC的构造就基本没有太多问题了。分析我们之前的DHCPv6广播数据包，我们发现当我们声明一个最多的中继转发结构个数时时，实际可以携带了0x21个。而代码中只预留了0x20个缓冲区地址。所以。补丁的最主要作用是限制DHCP服务不去拷贝第0x21个中继转发结构。

D. PoC

PoC链接：https://github.com/numencyber/Vulnerability_PoC/tree/main/CVE-2023-28231

我们的PoC崩溃堆栈如下：

总结

分析这类网络协议漏洞，很大一部分帮助来源于Wireshark对数据包的自动分析。它帮助我们理解协议结构以及基本的数据包错误原因和位置。虽然各个系统平台对于同一种协议都有自己的实现方式和处理逻辑，但他们在传输过程中，都遵循同样的标准。

另一方面，另一个分析该漏洞的关键在于偶然获取的DHCP服务器对恶意DHCP服务其检查功能。它提供了最原始的参照数据包以及DHCPv6服务可以接收广播消息的事实。这也提示我们该漏洞的确可以以非授权无交互的条件去触发。

再次，GPT帮助我们解释了大量的陌生变量以及标志的具体含义，以及初始DHCPV6广播数据发包代码。至少省去了大量查询时间和协议阅读理解过程。

最后，分析漏洞后续的流程：该漏洞能够利用的可能似乎比较小。一方面是该漏洞能导致的结果就是我们构造的第0x21个中继转发结构可以溢出覆盖这个全局数组计数变量。但限制于协议初期对DHCPv6延迟消息的结构检查以及漏洞函数中本身的标志验证，我们似乎只能覆盖这个计数为一个过大的值，这使我们想在后续构造可控的读写过程显得比较困难。