微软Windows系统零日漏洞分析:可能造成Web3生态重大影响

上个月微软的安全更新中修复了一个正在被恶意利用的Windows内核提权漏洞。该漏洞主要影响较早版本的Windows系统,Windows 11似乎不受影响。本文将分析在当前安全防护措施不断加强的背景下,攻击者可能如何继续利用这类漏洞。

我们在Windows Server 2016环境下完成了全部分析工作。

零日漏洞是指尚未被发现和修复的系统漏洞,类似于金融市场中的T+0交易概念。零日漏洞一旦被恶意利用,通常会造成极大危害。本次发现的Windows系统零日漏洞可让攻击者获得系统的完全控制权。

被攻击者控制系统后果严重,包括但不限于个人隐私泄露、系统崩溃数据丢失、财产损失、恶意软件植入等。对于个人用户而言,可能导致加密货币私钥被盗、数字资产被转移;从更大范围看,该漏洞甚至可能影响整个基于Web2基础设施的Web3生态。

补丁分析

对补丁进行分析,我们发现问题似乎只是一个对象的引用计数被多处理了一次。由于win32k是较早期的代码,我们可以找到一些早期的源码注释,这些注释表明之前的代码只锁定了窗口对象,没有锁定窗口对象中的菜单对象,这可能导致菜单对象被错误引用。

漏洞利用概念验证(PoC)实现

分析漏洞函数上下文,我们发现传入xxxEnableMenuItem()的菜单通常已在上层函数中被锁定,那么这里究竟是要保护哪个菜单对象?

进一步分析xxxEnableMenuItem中对菜单对象的处理过程,我们发现MenuItemState函数返回的菜单有两种可能:窗口的主菜单,或菜单的子菜单(甚至子子菜单)。

在PoC中,我们构造了一个特殊的四层菜单结构,相邻菜单之间是父子关系。这些菜单有一些特定特征,以通过xxxEnableMenuItem函数中的检测和判断。

在xxxRedrawTitle返回用户层时,我们删除了菜单C和菜单B的引用关系,成功释放菜单C。最终,当内核中xxxEnableMenuItem函数返回到xxxRedrawTitle函数时,即将引用的菜单C对象已经无效。

漏洞利用(Exploit)实现

在确定利用思路前,我们通常会进行一些理论上的前期判断,以避免在不可行的方案上浪费时间。本次漏洞利用主要考虑了两个方向:

1. 执行shellcode代码:参考早期的CVE-2017-0263和CVE-2016-0167。但在高版本Windows中,这种方式可能面临一些难以解决的问题。

2. 利用读写原语修改token地址:近年来已有公开的利用方式可供参考。桌面堆内存布局和读写原语具有长期通用性。我们主要需要分析如何在UAF内存被重用时首次控制cbwndextra为特大值。

我们将整个利用过程分为两个问题:如何利用UAF漏洞控制cbwndextra值,以及控制cbwndextra值后如何实现稳定的读写原语。

最终我们选择了在xxxRedrawWindow函数中通过标志位的AND 2操作来写入HWNDClass的cb-extra。这是因为HWNDClass的cb-extra偏移较小,我们可以通过布局内存来控制前一个对象的内存数据,从而通过xxxRedrawWindow函数中对对象标志的判断。

为实现稳定的内存布局,我们设计了至少连续三个0x250字节的HWND对象。释放中间对象后,用0x250字节的HWNDClass对象占用该位置。前一个HWND对象的尾部数据用于通过xxxRedrawWindow的标志检验,后一个HWND对象的菜单对象和HWNDClass对象用作最终读写原语的媒介。

我们尽量保持窗口对象和HWNDClass对象大小一致,并确保窗口对象的扩展数据足够大。通过堆内存中泄露的内核句柄地址,我们可以精确判断申请的窗口对象是否按预期顺序排列。

在读写原语方面,我们使用GetMenuBarInfo()实现任意读,使用SetClassLongPtr()实现任意写。除了替换TOKEN的写入操作依赖第二个窗口的class对象外,其他写入都利用第一个窗口对象的class对象通过偏移来实现。

总结

1. win32k现状:微软正在尝试使用Rust重构Windows 11预览版中的相关内核代码,未来新系统可能杜绝此类漏洞。

2. 漏洞利用过程相对简单:除了如何控制第一次写入需要细心尝试外,基本不需要使用新的利用技术。该类漏洞严重依赖桌面堆句柄地址的泄露。

3. 漏洞发现:推测可能依赖于更完善的代码覆盖率检测。一旦系统API能在目标函数执行路径中到达最深处的漏洞点,且窗口对象处于多重嵌套引用状态,该漏洞就可能被模糊测试发现。

4. 其他发现途径:除了对漏洞触发函数关键点的检测,针对不常见的内存布局和窗口或窗口类额外数据异常偏移读写的检测也可能是发现同类漏洞的途径之一。