CVE-2014-4115漏洞分析
一、简介
该漏洞是由于Windows的Fastfat.sys组件在处理FAT32格式的硬盘分区存在问题。攻击者利用成功可导致权限提升。
影响的系统包括：
Windows Server 2003
Windows Vista
Windows Server 2008
Windows XP 不提供补丁更新，但是漏洞仍在存在。
测试环境：
WinXP SP3
下面对漏洞成因做简单分析。
二、漏洞分析
1. "POC"
触发漏洞需要一个FAT32格式（一般都是这个格式）的U盘，然后用010工具将U盘偏移+10h位置的02改为大于2的数值如:77
这个偏移官网上的解释：
2.First Crash
然后用虚拟机连接该U盘，实验中打开U盘中的文件不会触发，只有当删除U盘内文件或者在U盘中创建新文件才会触发。触发后的BSOD：
显示的信息为BAD_POOL_HEADER。
3.Second Crash
内核中使用的pool类似于用户态的heap，调试时需要对fastfat.sys开启Special Pool,就像调试IE漏洞时候开启调试堆一样。下面两条命令都可以：
verifier /volatile /flags 0x1 /adddriver MyDriver.sys //无需重启立即生效,重启后失效
verifier /flags 0x1 /driver MyDriver.sys //重启后生效
触发漏洞后windbg显示的信息：
相关寄存器：
相关堆栈：
根据这些信息，目前知道了问题函数为FatCommonWrite，问题寄存器为eax。
4.回溯
对崩溃时的eax寄存器进行回溯，发现其可能和ExAllocatePoolWithTag函数的返回值有关：
可以看到如果cl大于2，会调用ExAllocatePoolWithTag。为了确定程序是否走了这个流程，需要动态调试一下。设置下面这两个断点：
第一个断点是为了过滤掉除了explorer.exe进程以外的进程去FatCommonWrite函数调用。（利用的是进程的EPROCESS结构找到name,再和"explorer.exe"字符串比较。）
第二个断点就是上图IDA截图的"cmp cl,2"指令的位置。
同样开启Special Pool断下来的情况：
此时cl=0x77，所以会去调用ExAllocatePoolWithTag分配pool。此时cl的值恰好等于我们修改U盘+10h位置的值，也就是Number of FATs，这可以通过多次修改U盘该位置的值来确定。
所以崩溃时的eax和分配的pool有关，回溯完毕。
5.Anaysis on vulnerability cause
调用ExAllocatePoolWithTag分配了一个77h字节的pool之后，程序会进入到一个循环：
经过动态调试，红框中的edi等于0x77也就是Number of FATs。所以该循环的框架：
for(i=0;i<Number of FATs;i++){…}
接着再来看看"mov [eax-4],edi"这条造成崩溃的指令，在崩溃之前都操作了什么。得到的结果是这个样子的，eax-4的地址依次为：
0x87700f90 0x87700fa8 0x87700fc0 0x87700fe8 0x87700ff0 0x87701008（crash）
而分配的pool的起始地址为0x87700f88，大小为0x77字节：
所以可以确定这段循环是在对刚调用ExAllocatePoolWithTag分配的0x77字节的pool进行操作。所以可以将这个循环更具体一点了：
这样一来，漏洞的成因就很明显了：调用ExAllocatePoolWithTag分配pool时，应该分配Number of FATs * 18h 大小的pool，而不是Number of FATs大小的。
三、参考
http://www.icewall.pl/?p=680&lang=en
http://blog.vulnhunt.com/index.php/2014/12/03/cve-2014-4115_analysis/
http://msdn.microsoft.com/en-us/library/windows/hardware/ff551832(v=vs.85).aspx
https://technet.microsoft.com/en-us/library/security/ms14-063.aspx