微软Windows系统严重漏洞分析

近期，微软发布的安全补丁中修复了一个正被黑客在野利用的Windows内核提权漏洞。该漏洞主要影响早期Windows系统版本,无法在Windows 11上触发。这类漏洞由来已久,本文将探讨在当前安全防护不断加强的背景下,攻击者如何继续利用此类漏洞。

本次分析基于Windows Server 2016环境完成。

漏洞背景

这是一个零日漏洞,指尚未公开且未修复的系统漏洞。黑客可以在用户毫无察觉的情况下利用零日漏洞发动攻击,具有极大破坏性。

本次发现的零日漏洞存在于Windows系统内核层面,黑客可通过该漏洞获取Windows的完整控制权。这可能导致用户隐私泄露、系统崩溃、数据丢失、财务损失等严重后果。从Web3角度看,用户的私钥可能被盗取,数字资产面临被转移的风险。更大范围来说,这个漏洞甚至可能影响到基于Web2基础设施运行的整个Web3生态。

漏洞分析

分析补丁代码,我们发现问题出在一个对象的引用计数被多次处理。查看早期win32k源码注释,可以了解到以前的代码只锁定了窗口对象,而没有锁定窗口对象中的菜单对象,这可能导致菜单对象被错误引用。

进一步分析发现,传入xxxEnableMenuItem()函数的菜单通常已在上层函数中被锁定,那么这里究竟要保护哪个菜单对象?经研究,xxxEnableMenuItem中的MenuItemState函数返回的菜单有两种可能:窗口的主菜单,或菜单的子菜单(甚至子子菜单)。

漏洞利用

为验证漏洞,我们构造了一个特殊的四层菜单结构,并设置了一些特定条件:

1. 最底层菜单D的ID必须为系统菜单类型,如关闭菜单(0xf060)
2. 顶层菜单A也必须是系统菜单,但需删除其中的0xf060菜单项
3. 删除菜单C在菜单B中的引用
4. 菜单B的存在似乎对菜单C的释放有影响

触发漏洞时,在xxxRedrawTitle返回用户层时删除菜单C和B的关联,成功释放菜单C。当内核中xxxEnableMenuItem函数返回到xxxRedrawTitle时,即将引用的菜单C对象已失效。

漏洞利用分析

在设计漏洞利用方案时,我们主要考虑了两个方向:

1. 执行shellcode:参考早期CVE-2017-0263和CVE-2016-0167的方法。但在高版本Windows中,shellcode执行入口点和SMEP等安全机制可能存在障碍。

2. 利用读写原语修改token地址:这种方法具有较好的通用性。关键是分析如何在UAF内存重用时首次控制cbwndextra为特大值。

我们将漏洞利用分为两步:控制cbwndextra值,以及实现稳定的读写原语。

首次数据写入

系统错误使用被控制内存的窗口对象数据主要发生在xxxEnableMenuItem函数的MNGetPopupFromMenu()和xxxMNUpdateShownMenu()中。我们利用窗口类WNDClass的窗口名称对象占用释放的菜单对象内存。

关键是找到一个可被任意写入的地址结构,哪怕只有一个字节。我们最终选择了xxxRedrawWindow函数中的方案,通过AND 2操作写入HWNDClass的cb-extra。

内存布局

我们设计了连续三个0x250字节HWND对象的内存布局,释放中间对象并用0x250字节HWNDClass对象占用。前一HWND对象尾部数据用于通过xxxRedrawWindow检验,后一HWND对象的菜单和HWNDClass对象用于最终读写原语。

我们尽量使窗口对象和HWNDClass对象大小一致,并通过泄露的内核句柄地址精确判断对象排列是否符合预期。

读写原语

任意读原语使用GetMenuBarInfo(),任意写原语使用SetClassLongPtr()。除TOKEN写入外,其他写入都利用第一个窗口对象的class对象进行偏移写入。

总结

1. 微软正在用Rust重构win32k相关内核代码,未来此类漏洞可能在新系统中被杜绝。

2. 该漏洞利用过程相对简单,主要依赖桌面堆句柄地址泄露。如不彻底解决这个问题,老旧系统仍存在安全隐患。

3. 该漏洞的发现可能得益于更完善的代码覆盖率检测。

4. 对于漏洞利用检测,除关注漏洞触发函数关键点外,还应关注对内存布局和窗口类额外数据异常偏移读写的检测。