freeBuf
主站

分类

漏洞 工具 极客 Web安全 系统安全 网络安全 无线安全 设备/客户端安全 数据安全 安全管理 企业安全 工控安全

特色

头条 人物志 活动 视频 观点 招聘 报告 资讯 区块链安全 标准与合规 容器安全 公开课

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

小议Win32子系统中”对象归属权”导致的uaf漏洞
2021-01-04 10:53:51

概要

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

相关知识

Win32k 中 gdi 对象通常有如下几种所属关系:

#define OBJECT_OWNER_ERROR   ( 0x80000022)

#define OBJECT_OWNER_PUBLIC   ( 0x00000000)

#define OBJECT_OWNER_CURRENT ( 0x80000002)

#define OBJECT_OWNER_NONE    ( 0x80000012)


其中最值得关注的是 OBJECT_OWNER_CURRENT 和 OBJECT_OWNER_PUBLIC,OBJECT_OWNER_PUBLIC 代表的该 gdi 对象并不从属于某个进程,而 OBJECT_OWNER_CURRENT 则代表该 gdi 对象属于当前进程(在 setowner 时 OBJECT_OWNER_CURRENT 会转换为当前进程 id),当 win32 进程结束退出时会调用 NtGdiCloseProcess,该函数主要作用便是清理各类属于本进程的 gdi 对象,释放它们所占据的系统资源:



上图中 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 分析

如下是 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 场景。

仔细思考一下我们最初提炼的漏洞模型,最关键的因素有两点:(1) 系统在修改 gdi 对象的 owner 时并没有考虑该对象是否存在被其他代码引用的情况;(2)  win32 进程退出时调用 NtGdiCloseProcess 清理 gdi 对象时太过粗暴,没有考虑到由于 (1) 导致的 uaf 的问题,在 CVE-2019-0803 漏洞之前,微软对于这个模式的漏洞的 patch 都是处于头痛医头,脚痛医脚的状态,简单的删除/修改了会调用 setowner 相关的函数,那么攻击者找到新的 setowner 方法后,patch 便无效了,直到 CVE-2019-0803 的 path 出现,对于 bitmap 对象的该漏洞模型场景进行了完整的校验,整个 patch 分为两部分,setowner 部分增加了对引用计数的校验:



在引用计数不为 0 时,增加了一个特殊的标志位 0x4000,另一部分是在 NtGdiCloseProcess 处:

对于存在 0x4000 标志位的对象,做了特殊的处理。


思考

随着攻防对抗的不断深入,浅层次的漏洞资源已经是消耗殆尽,在这种情况下更需要从开发者和一个更宏观的角度思考问题:为什么开发者这么设计这个机制?这个机制的利弊是什么?安全边界是什么?什么场景容易出问题?在我们对目标的运行机制有了深入的研究,能够回答上面的问题后,是不是能提炼出一个适应于目标的漏洞场景模型,然后依照这个模型去进行漏洞挖掘,这样是否效率能更高一些呢?就像是早年的 usercallback 和 2019/2020 年大火的服务类提权漏洞。希望本文能给读者带来一些这方面的启发和帮助,也欢迎各位看官拍砖吐槽交流。

# 微步在线 # UAF 漏洞
本文为 独立观点,未经允许不得转载,授权请联系FreeBuf客服小蜜蜂,微信:freebee2022
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
相关推荐
  • 0 文章数
  • 0 关注者