Windows内核漏洞分析:CVE-2018-0744

Windows内核漏洞分析:CVE-2018-0744

黑客资讯访客2021-10-11 18:15:0010893A+A-

在今年年初谷歌的安全人员公布了一个由于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

支持Ctrl+Enter提交

黑资讯 © All Rights Reserved.  
Copyright Copyright 2015-2020 黑资讯
滇ICP备19002590号-1
Powered by 黑客资讯 Themes by 如有不合适之处联系我们
网站地图| 发展历程| 留言建议| 网站管理