Windows内核漏洞分析:CVE-2018-0744
在今年年初谷歌的安全人员公布了一个由于DCE属性导致的uaf,其公布的poc如下:
从谷歌安全研究员给出调试信息我们可以了解到这是一个tagwnd对象导致的uaf。
在分析漏洞之前我们先了解一下本次漏洞相关的两个属性:CS_CLASSDC和CS_OWNDC,当windows对象被设置了CS_CLASSDC属性并且所属窗口类没有被设置dce对象时,在调用CreateWindow创建窗口的过程中,内核会调用CreateCacheDc,创建DCE对象(下图节选自wrk):
同样通过上图可以看出被设置了CS_OWNDC属性时,内核也会创建DCE对象,不同的在于设置CS_CLASSDC属性时,创建的DCE是被赋值给窗口所属的窗口类对象:
而若是设置的CS_OWNDC属性,创建的DCE对象会被直接赋值给窗口对象:
也就是说一个dce对象的所有权有两种情况:一是属于某一个窗口对象,另一中情况就是属于某一类窗口,即挂靠在tagcls对象中。我们再看看一直在关注的dce对象结构(节选自wrk):
结构体中的pwndorg便是本次uaf的对象
接下来了解一下在关闭释放窗口对象时,对于dce对象内核是如何处理的(以下截图源自该漏洞修补之前的win32kfull.sys):
第一个if的意思是,当pdce是属于窗口类对象的,那么便调用InvalidateDCE,清空dce中的pwnd相关字段,第二个if的意思是,如果pdce是属于该窗口的,那么不仅要清空dce中的内容,还要释放该dce,咋看似乎逻辑上并没有什么问题,但对照poc我们便能发现问题所在:
在调用CreateWindowEx创建WindowA时,由于并未设置CS_OWNDC或者是CS_CLASSDC属性,内核并不会创建dce对象,接下来调用SetClassLong函数修改WindowA的类属性,添加上CS_CLASSDC属性,那么在调用CreateWindowEx创建WindowB时,内核会创建一个dce对象(我们称其为dce_a),其所有权归窗口类pcls所有,并且此时dce对象中的pwndOrg对应于WindowB的窗口对象,接下来调用GetDc(WindowA),由于其窗口类具有CLASSDC,那此时GetDc便会返回dce_a对应的句柄hdc_a,并且此时dce_a中的pwndorg变为windowa对应的窗口对象,紧接着调用SetClassLong函数添加了CS_OWNDC属性,那么这时候再调用CreateWindowEx创建WindowC,由于窗口同时具有CLASSDC属性 和CS_OWNDC属性,内核不仅会新创建一个属于窗口WindowC的dce对象(dce_b),同时窗口类拥有的dce对象也会从dce_a,变为dce_b.总结一下此时内核中对象的状态,dce_a对象中的pwndorg对应于windowA,窗口类pcls拥有的对象为dce_b,那么当我们释放windowA时,再看看上面提到的逻辑(此时pdce对应与dce_a,pwndorg对应于windowA):
无论是上面的if还是下面的if,两个条件都不满足,也就是说当windowA被释放时,dce_a中的pwndorg并不会清0,仍然保存着一个被释放的窗口对象,
最后我们调试poc,来验证我们的分析推测,在poc中加入断点以方便调试:
设置如下断点:
bp win32kbase+0x39b0a “r @eax;r @$t1=poi(@ebp+0x8);r @$t1”
bpCVE_2018_0744!main+0xf7———-代表在GetDC(WindowA);处中断
其中eax代表新创建的dce对象,t1代表与之关联的窗口对象,
运行到第一个int3,并没有发生任何中断,g继续运行,输出如下:
查看windowb的值:
对上号了,也就是创建完窗口windowb后,新建了一个pce对象901fa198,它存储的pwndorg为窗口b–95e148a0:
在执行完GetDC(WindowA)后内存发生如下变化:
也就是说pdce对象的pwndorg变为窗口a–95e14220,我们看看窗口a所属的窗口类对象pcls中包括pdce对象是什么:
这会儿是901fa198
一直运行到最后一个int 3:
创建了一个新的dce对象–901b01b8 ,我们继续看看窗口a所属的窗口类对象pcls中包括pdce对象是什么:
可以看到已经变成新生成的901b01b8,也就是这时能绕过xxxfreewindow中的两个if判断。
最后我们看看在窗口A释放后,dce对象901fa198中的pwndorg是否认为窗口A:
Gu等释放完成后看看pdce901fa198中的pwndorg:
可以看到依旧是窗口a–95e14220
这样pdce中便保存了一个被释放的窗口对象,但再次引用时便出现了uaf。
最后看看微软的修补方案:
补丁前:
补丁后:
也就是把poc中绕过两个if条件的情况也包括进去清空dce中的窗口对象了,这样也就避免uaf了。
从这个案例可以总结出在win32k模块中uaf出现的场景不少是设计架构时的逻辑错误导致的,作为安全研究人员,咱们更多的从宏观思考或许能有更大的收获。
原文:https://www.anquanke.com/post/id/107385
相关文章
- 3条评论
- 南殷卮留2022-05-31 16:04:22
- 乎逻辑上并没有什么问题,但对照poc我们便能发现问题所在:在调用CreateWindowEx创建WindowA时,由于并未设置CS_OWNDC或者是CS_CLASSDC属性,内核并不
- 绿邪痴魂2022-05-31 09:48:43
- 下来调用GetDc(WindowA),由于其窗口类具有CLASSDC,那此时GetDc便会返回dce_a对应的句柄hdc_a,并且此时dce_a中的pwndorg变为windowa对应的窗口对象,紧
- 丑味甜吻2022-05-31 16:43:18
- ce是属于该窗口的,那么不仅要清空dce中的内容,还要释放该dce,咋看似乎逻辑上并没有什么问题,但对照poc我们便能发现问题所在:在调用CreateWindowEx创建WindowA时,由于并未设置CS_OWNDC或者是CS_CLASSDC属性,内核并不会创建dce对象,接下来调用SetClass