cve-2015-1635漏洞分析

上周（2015.4.15）爆出的cve-2015-1635漏洞，遂分析一番，留作记录。使用poc如下。

wget 192.168.16.168/welcome.png --debug --header='Range:bytes=10-18446744073709551615'

从之前的各种报告可知该漏洞起始于UlpParseRange函数，对该函数下断，发送poc之后断下。查看HTTP!UlpParseRange的堆栈情况，从堆栈可以清晰的发现，此时的内核正在对用户发送的http包头进行解析。

单步进入该函数，在这个位置会对poc中Range域的数值进行校验，首先校验lower的数值是否大于0xFFFFFFFFFFFFFFFFFF,此处我们的输入为a。

对比upper的数值是否大于lower。

计算length的数值，公式为length = upper – lower + 1。

实例中length为0xFFFFFFFFFFFFFFFF-a+1 =0xFFFFFFFFFFFFFFF6

总的校验图

在该函数中的校验伪代码

因此在HTTP!UlpParseRange中实现了对lower，upper的简单校验，同时生成了length（注意，此处并没有对生成的length的值做任何校验）。

然后函数会继续运行，直到UlAdjustRangesToContentSize，在该函数中同样会对包括upper，lower，length在内的多项数值进行校验，以下为该函数调用时的堆栈。

首先在该函数中同样会检测lower的值是否大于0xFFFFFFFFFFFFFFFF（同于之前HTTP!UlpParseRange）。

校验lower是否小于请求的内容的大小0x2d272（该值为发送请求中的资源的大小）。

通过计算（0x2d272 = 184946）确实与我们请求的图片的大小一致.

取之前函数HTTP!UlpParseRange中生成的length，校验length的值是否大于0xFFFFFFFFFFFFFFFF。

计算Legtncheck = length + setoff（实际就是lower的数值）。

并校验该值是否大于请求内容的大小0x2d272，此处lengthcheck = upper-lower+1 +lower ==0

因此此处一定绕过（当upper设置为0xFFFFFFFFFFFFFFFF），该安全校验（而此处也是唯一针对length的校验）。

在函数的结束处，该问题length会被返回，并继续向下传递。

该函数中的主要校验步骤。

该函数的主要校验伪代码

之后该参数会传递到UlBuildFastRangeCacheMdlChain函数中

UlBuildFastRangeCacheMdlChain,该函数的调用栈

在该函数中会对传入的length进行截断，致使0xFFFFFFFFFFFFFFF6->0xFFFFFFF6。

之后会在该函数中连续调用三次IoBuildPartialMdl，此处可以看看msdn中对于该函数的解释。可以使用IoBuildPartialMdl来把一个IRP请求分解成多个IRP请求。

在第四次时会触发真正的漏洞。此处为传入的第四个参数SourceMdl。

第三个参数length（该值前面生成），也是造成最后蓝屏的原因。

此处为第二个参数TargetMdl。

最后是第一个参数VirtualAddress

此处为函数调用前的两个Mdl结构，其中sourceMdl的大小只有2d316大小，TargetMdl的大小为ffffff6，因此理论上通过targetMdl能都有足够的空间存储来自TargetMdl的值。

跟进该函数nt! IoBuildPartialMdl，最后会完成由SourceMdlàTargetMdl的赋值，赋值循环之前两个Mdl结构的内存状态。

从SourceMdl+30出按8比特取值，并赋值到TargetMdl+30处

此处计算之后即为Target+30出的地址，复制前两个结构

一次赋值之后

整个赋值的循环很简单如下，但是为啥会蓝屏了？仔细看下汇编指令就会发现一个可疑的值rsd，整个过程的循环由该寄存器控制，我们来看看他是如何生成的。

通过ida的分析可知r8d的生成过程如下，总结起来是:r8d=target.cout&fff+target.offset+fff+1

此处我们生成的结果即为100000；

次数通过r8d = r8d + ffffffff，当r8d为零时，停止循环赋值，通过编程可知该处会循环1048576次，每次赋值8位，即为1048576*8  = 8388608 = 0x800000，即需要从sourceMdl中赋值出0x800000长度的内容，当通过之前source.count的值即可知count为0x2d316<<0x800000,因此此处循环赋值的结果就是越界读取内存，而此时的操作位于内核中，所以duan蓝屏了

此处sourceMdl的起始位fffffa800287e930，count为2d316，所以sourceMdl的结束应该为

fffffa800287e930+2d316=FFFFFA80028ABC46（此处计算方式存在疑问，对内核其实不是很了解），此处发现FFFFFA80028ABC46是不能下断，退而求其次，对FFFFFA80028ABC40内存度断点，运行。

断下之后，在进行两次循环，此时FFFFFA80028ABC50依然可读。

但是在FFFFFA80028ABC58读取是，发生pagefault错误，从而导致蓝屏。

duan蓝屏了。。。。

下图为总的函数触发流程

一些其他问题

蓝屏的问题

关于蓝屏的限制问题，通过之前的分析出发时需要如下限制

lower<0xffffffffffffffffff

lower<upper

lower<contenlength

length+lower<contenlength

通过上面的总结发现要稳定的触发蓝屏upper的值必须恒定为0xFFFFFFFFFFFFFFFF，lower的值必须小于contenlength。满足以上调节即可稳定触发蓝屏。

contenlength问题

触发蓝屏时需要poc中必须有请求资源，即如果只是一个简单的根目录，则不会蓝屏。原因如下图所示，漏洞触发前在韩式UlSendHttpResponseIoctl中会有一个判断，请求资源为空进入上一个分支，不为空则进入漏洞触发的分支。

如下图，影响源头来源于其中的rsp+3C8h+var_333中的值（该处没有做详细分析）。

32位触发的问题

之前漏洞刚爆出来的时候，部门有小伙伴提到18446744073709551615这个数32为操作系统不识别，32为系统应该不收影响，但是实际结果是32位体统也不能幸免，揪其原因是该大数在32位系统中被截断了，如下图所示，对于存储远内存中length，在传入函数HTTP!UlAdjustRangesToContentSize之前，是按32为进行的取值，所以该整数溢出绕过在32为依然可行。

最后感谢某人晚上陪我聊微信，否则一晚上的蓝屏真的会疯的，感谢。。。。