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