CVE-2015-0057 POC构造 & 利用分析

主要内容：

构造POC

利用思路

0x00 初探

从这篇文章可以获知：

1.问题出在 win32k!xxxEnableWndSBArrows 函数，其在触发 user-mode callback 后，执行完相应操作后从用户层返回到内核层，对接下来操作的对象未能验证其是否已经释放（更改），而继续对其进行操作，导致UAF。触发user-mode callback的调用流程为：

2.所涉及的敏感对象为 tagSBINFO,可以通过CreateWindows("SCROLLBAR"...)来创建。

3.关键利用代码也位于 win32k!xxxEnableWndSBArrows 函数内，位于第一次调用 xxxDrawScrollBar 函数后。

所以要构造POC，思路就很明确了：

在 win32k!xxxEnableWndSBArrows 函数执行到关键代码之前，找到一条能够触发 user-mode callback 的调用路径，hook 掉对应的应用层函数，在其中 destroy tagSBINFO 对象。

Aaron Adams给出了触发上面 user-mode callback 流程的部分代码，为其添加一个最基本的窗口，然后在WM_CREATE消息中创建scrollbar、Show scrollbar 和 Enable scrollbar，将其编译成程序。

0x01 跟踪

对该程序的执行过程跟踪，查看其是否按照预期的 user-mode callback 流程执行。发现在其 xxxGetColorObjects 函数中，流程走向了另一条流程 --> 调用 xxxGetControlBrush 函数。相关代码段：

经查阅ReactOS，得知tagWnd.fnid=0x29A 含义：

此时的 tagWnd 就是我们所创建的 SCROLLBAR 的，而SCROLLBAR的fnid的值一直都为0x29A。

所以此时有两个选择：

1.想办法更改 fnid 的值

2.寻找另一条触发user-mode callback的路径

我选择了2：寻找 xxxGetControlBrush 函数内触发user-mode callback的调用路径。

关于怎么判断 user-mode callback 是否可以触发，内核小王子Tajei Mandt很早就纰漏了相关知识：

任何的user-mode callback流程最终内核到用户层的入口点都会是 nt!KeUserModeCallback

函数名带有"xxx"和"zzz"前缀的一般都可以触发。

。。。

有趣的是，在寻找的过程中，结合动态调试发现 xxxGetControlBrush 又去调用 xxxDefWindowProc 函数了。那么是否可以回到上面的user-mode callback继续执行，但是在对 xxxLoadUserApiHook 函数跟踪之后，发现其并不能调用 xxxLoadHmodIndex。

同样的，两个选择，仍然选择2：放弃这条路径，返回到 xxxDefWindowProc 函数中寻找另一条路径。

在 xxxDefWindowProc 调用 xxxLoadUserApiHook 附近有这样一段代码：

虽然call ds:rva gapfnScSendMessage[r11+r10*8]看起来是动态确定，但在测试过程中，在xxxEnableWndSBArrows的调用流程中，其都是调用的 SfnDWORD 函数。

这就是寻找的user-mode callback的调用流程了。

0x02 确定

目前确定的 user-mode callback 流程内核部分：

NtUserEnableScrollBar--> xxxEnableScrollBar--> xxxEnableWndSBArrows--> xxxDrawScrollBar(第一次) -->xxxDrawSB2 -->xxxGetColorObjects -->xxxGetControlBrush -->xxxGetControlColor -->xxxDefWindowProc -->SfnDWORD(call ds:rva gapfnScSendMessage[r11+r10*8])--> KeUserModeCallback

关于该流程对应的用户层函数,这个对应关系可以通过使用 Windbg 查看 peb.KernelCallbackTable 来确定：

也可以直接利用IDA查看：

Index为调用KeUserModeCallback 最后一个push的值：

所以 win32k!SfnDWORD 对应的用户层函数为 user32!fnDWORD。

到此，整个user-mode callback流程便清晰了。

0x03 行动

接下来需要利用这次user-mode callback，hook 掉其流程中用户层函数 user32!fnDWORD，然后在 MyfnDWORD 中 destroy scrollbar。

由于user32!fnDWORD调用频繁，所以要进行区分，为了把干扰和不确定因素降低，在 WM_CREATE消息中，hook 掉 user32!fnDWORD 便立即调用 EnableScrollBar 。

测试过程中，在目标 user-mode callback 流程触发的 user32!fnDWORD 调用之前，没有一次 user32!fnDWORD 的调用，所以第一次的 MyfnDWORD 调用就是目标流程所触发的，此时 destroy scrollbar 就好了。

0x04 效果

调用 win32k!xxxDrawScrollBar 函数之前：

之后：

可以看到其已经从tagWnd中移除了。

0x05 利用分析

流程：

[1] 创建大量的 tagPROPLIST 对象，为下一步挖坑做前提条件。

[2] 释放掉一些 tagPROPLIST 对象，为 tagSBINFO 对象准备一些坑

[3] CreateWindow(SCROLLBAR....)创建 tagSBINFO 对象，入坑

[4] xxxEnableWndSBArrows 触发 user-mode callback 机制，在流程中用户层函数 USER32!_fnDWORD 中释放掉SCROLLBAR,再利用 user32!NtUserSetProp 来让 tagPROPLIST 占据刚释放掉的 SCROLLBAR 对象内存空间.

[5]user-mode callback 流程返回到内核，来到关键代码段，利用其增加 tagPROPLIST.cEntries 大小。此时利用 SetProp() 可以获得对 tagPROPLIST 相邻内存进行越界写的能力。

[6]利用这个越界写的能力，对事先布置在tagPROPLIST对象相邻 tagWnd.strName 进行操作，利用tagWnd.strName相关的函数 InternalGetWindowText() 和 NtUserDefSetText() 可以分别获得任意地址读和任意地址写的能力。

[7] Write-What-Where 完成，将 HalDispatchTable+4 修改为 shellcode 地址。到此剩下的工作和其他内核漏洞利用一样了。