在研究 win32k 模块的 uaf 漏洞时，最重要的一点就是，了解目标对象整个生命周期的状态转换过程，尤其是哪些行为会触发 ref 的增加，哪些行为会导致 ref 的减少，甚至部分场景会使得内核不考虑 ref 值直接 free 目标对象。本文旨在探讨这样一种场景导致的 uaf 漏洞：内核没有正确处理 gdi 对象的所有权问题，使得 gdi 对象在被引用的状态下仍然被 free，从而导致 uaf（本文分析调试的目标系统为 win7x86）。

上图中 v2 代表的是触发资源清理操作的原因，1-进程结束；2-会话结束，我们可以看到当进程退出时，会先调用 ultiUserGreCleanupHmgOwnRemoveAllLocks 函数清理相应类型对象的锁，然后调用 vCleanup* 清理相应的 gdi 对象，MultiUserGreCleanupHmgOwnRemoveAllLocks 函数的参数则代表相应的 gdi 对象类型，如 5 对应于 bitmap 对象，4 对应于 regions 对象，我们进一步看看 MultiUserGreCleanupHmgOwnRemoveAllLocks 函数做了什么：

可以看到系统在遍历 gdi 对象的句柄表，对于属于当前进程的 gdi 对象，主动清零它们的引用计数和锁计数，那么我们可以抽象出这样一种漏洞模型，存在 gdi 对象 A，先通过某些操作使得系统中的其他对象保持着对 gdi 对象 A 的引用，接着关键点在于设法使得对象 A 的所有者属性变为 OBJECT_OWNER_CURRENT  从属于进程 P1（并且引用对象 A 的对象在对象 A 释放前不受进程 P1 退出的影响），那么当 P1 进程退出时，便会释放对象 A，而内核中依旧保存着对象 A 的引用，这样便构造了一个典型的 uaf 场景，CVE-2015-1722、CVE-2015-1724 CVE-2015-6173、CVE-2016-0094、CVE-2019-0803 等漏洞基本都是这个抽象场景的实例化体现，后文中我们将以 CVE-2015-1722 为示例对这种场景进行分析。

如下是 CVE-2015-1722 的 POC：

POC 中 hbmp1 则是前面漏洞模型中的关键的 gdi 对象 A，此时它的 owner 是 POC 进程，“先通过某些操作使得系统中的其他对象保持着对 gdi 对象的引用”，这一步是通过 NtGdiSelectBitmap 来实现的，使得 hdc2 代表的 dc 对象维持了对 hbmp1 代表的 bitmap 对象的引用，“接着关键点在于设法使得对象 A 的所有者属性变为 OBJECT_OWNER_CURRENT 从属于进程 P1”，这一步是先通过 InsertMenu 将 bitmap 和对应的 item 关联，接着通过 SetClipboardData 将 bitmap 的 owner 变为 public 即(0)，最后 postmessage 将 notepad 关闭触发 FreeItemBitmap 操作，在 FreeItemBitmap 中 bitmap的owner 变为 notepad 进程，那么 notepad 在执行完 FreeItemBitmap 便会将 hbmp1 对应的 bitmap 对象释放掉。但是，此时 hdc2 对应的 dc 对象仍然维持了对 hbmp1 的引用，这便是一个典型的 uaf 场景。

微步在线

研究响应中心

-长按二维码关注我们-

本文始发于微信公众号（微步在线研究响应中心）：小议Win32子系统中”对象归属权”导致的uaf漏洞