CVE-2014-4113分析

描述：

Microsoft Windows Kernel 'Win32k.sys' CVE-2014-4113 Local Privilege Escalation Vulnerability

漏洞简介说这个CVE是由于win32k.sys驱动模块漏洞，造成本地提权。

成因+分析

拿到一个crash的样本进行调试，直接运行crash如图

crash原因是访问违规，查看当前ESI=fffffffb

那么ESI+8 = 3，那么这里的ESI的值很奇怪，反向跟踪来源。

ESI来自于当前函数栈帧的参数1，根据堆栈上的图直接到 xxxHandleMenuMessages(x,x,x)函数这里进行跟踪，如下图

那么继续看ebx的来源，当前函数这块流程很复杂，分支很多，完全不知道从哪里过来的

先条件断点bp win32k!xxxTrackPopupMenuEx "j (poi(@esp+3*4)==0xFFFFD8F0);'gc'"，断在上层函数

用之前的脚本稍加修改，跑出来EBX的值是从bf8e85c7这里最终修改为fffffffb的。

继续看

虽然和分析整体过程没什么关系，不过还是记下来。这个函数的很奇怪，F5之后return 全为0，我在想出口就没有其他值了。然后出现一种从没见过的指令，类似下面这种

JUMPOUT(v6, 0, &loc_BF8CF612);

对照着流程视图，发现Jnz的没有线连出去，因为这个612这个地址并不在当前函数中。无疑我们的返回值就在这里。因为有好几个这种的指令出现，为了确定是哪个分支，我决定动态调试一发，最终确定了就是从BF8CF4EB这个分支出去的。那么接着向上找到xxxMNFindWindowFromPoint函数的返回值。

来到xxxMNFindWindowFromPoint函数，跟进去

发现是xxxSendMessage(x,x,x,x)的返回值，因为WINDOWS的消息机制，这个消息发出去之后，是交给RING3进行处理，这个返回值是用户层构造的。

到此，就分析完成了，前面所说的ESI的由来问题。然而在xxxSendMessage(x,x,x,x)函数返回后，返回值没有校验仅仅校验了ffffffff，却没有校验其他值，这样保证了fffffffb这样的数据能够进入到后续的流程，造成crash。

其实换做其他任意一个值应该都能被传递到最后的ESI位置，那么为什么不够造其他的消息，要构造fffffffb，应该是和漏洞的利用有关。