在4月的补丁日,微软通过标记为“高危”的MS15-034补丁,修复了HTTP.SYS中一处远程代码漏洞CVE-2015-1635。据微软公告(https://technet.microsoft.com/en-us/library/security/MS15-034)所称,当存在该漏洞的HTTP服务器接收到精心构造的HTTP请求时,可能触发远程代码在目标系统以系统权限执行。具体介绍参见安全脉搏《MS15-034 HTTP.sys 远程执行代码(CVE-2015-1635)》
这是对于服务器系统影响不小的安全漏洞,任何安装了微软IIS 6.0以上的的Windows Server 2008 R2/Server 2012/Server 2012 R2以及Windows 7/8/8.1操作系统都受到这个漏洞的影响。
从微软的公告致谢来看,这个漏洞是由“Citrix Security Response Team”(美国思杰公司的安全响应团队)发现,从网上公开的信息来看,Citrix公司是一家从事云计算虚拟化、虚拟桌面和远程接入技术领域的高科技企业。这也引发了Twitter上很多关于该漏洞是否是由针对Citrix公司的APT攻击中发现的疑问,而就在微软发布补丁的不到12个小时内,便有匿名用户在Pastebin网站上贴出了针对这个漏洞可用的概念验证攻击代码,似乎也印证了这一点。
笔者和360Vulcan的小伙伴们获得该信息后,就开始针对其进行深入的分析,并在12小时内初步分析清楚了漏洞的原理和利用相关信息,下面就将我们分析的一些结果分享给大家,以便更好地促进安全社区理解和防御这一高危安全漏洞。
结合Pastebin网站上贴出的信息(http://pastebin.com/ypURDPc4)和微软公告,我们知道这是一个位于HTTP.SYS中的整数溢出漏洞,根据Pastebin网站的python代码,我们知道通过给IIS服务器发送这样格式的HTTP请求,就可以触发(检测)这个漏洞:
GET / HTTP/1.1
Host: stuff
Range: bytes=0-18446744073709551615
我们直接使用wget或curl工具,也可以直接测试这个漏洞,例如使用如下命令行:
wget 127.0.0.1 –debug –header=”Range: bytes=0-18446744073709551615″
此处18446744073709551615转为十六进制即是 0xFFFFFFFFFFFFFFFF(16个F),是64位无符号整形所能表达的最大整数,那么我们很容易可以想到,这个“整数溢出”必然同这个异常的超大整数有关。
Pastebin上POC的作者提供的检测工具代码认为,如上请求包,若IIS服务器返回“Requested Range Not Satisfiable”,则是存在漏洞,否则如果返回”The request has an invalid header name“,则说明漏洞已经修补。
在实测中可能很多人也会发现并非如此,针对不同的服务器,这个测试程序很可能导致服务器直接BSOD甚至直接引发VM进程Crash(对于虚拟主机),这是为什么呢?这究竟是发生在何处的什么原因的整数一处呢?在下面的小节中我们将会进一步讲到。
HTTP.SYS是微软从IIS6.0开始,为了在Windows平台上优化IIS服务器性能而引入的一个内核模式驱动程序。它为IIS及其他需要运用HTTP协议的微软服务器功能提供HTTP请求的接收与响应、快速缓存、提高性能、日志等功能服务。
更多关于HTTP.SYS的信息,可以参考微软Technet Library中”IIS 6.0 Architecture”中的“HTTP Protocol Stack”一章(https://technet.microsoft.com/en-us/library/cc739400(v=ws.10).aspx)。 HTTP.SYS提供了两个最重要的功能是Kernel-mode caching 和Kernel mode request queuing,而本次的安全漏洞就出在Kernel mode caching(内核模式缓存)中。
这里笔者以Windows 8.1 X86平台上安装的IIS 8.5为例进行分析讲解,这里我们分析的存在漏洞的HTTP.SYS版本号为6.3.9600.16520,修补后的http.sys版本为6.3.9600.17712
Pastebin上POC代码的匿名作者提到,补丁修补了http!UlpParseRange函数,通过RtlUlonglongAdd函数实现了修补/拦截。
从测试代码和函数名上,我们都可以看出这个漏洞同HTTP头中的”Range“域有直接的关系, Range请求是HTTP协议中HTTP客户端用于只获取服务器上文件的某一部分数据的请求域,更多关于Range请求的细节和规范,可以参考RFC 7233 “Hypertext Transfer Protocol (HTTP/1.1): Range Requests”(http://www.rfc-editor.org/rfc/rfc7233.txt)。
这里先简单介绍一下http.sys缓存工作的原理,IIS进程w3wp.exe接收到HTTP请求后,将数据缓存到内核中,并整合HTTP回应头,最后由http.sys组织数据包经由网络内核组件发送出去。请求中包括Ranges对象的指定范围,而缓存中则包含了http文件和大小信息等。
我们接下来先来看看这个UlpParseRange函数,看他是否是这个漏洞的根本原因。
UlpParseRange的整个代码比较长,这里就不全部贴出了,函数的逻辑很简单,就是从Range bytes=lower-upper(也可以是lower-或-upper形式)中,解析出lower(即读取范围的开始offset)和upper(即读取范围的结束offset)),然后计算要读取的长度,在正常的情况下,upper大于lower,因此长度=upper-lower +1
这里如果是测试代码中的例子,lower=0 ,upper=0xFFFFFFFFFFFFFFFF
我们看看未修补前的代码是怎么样写的
PAGE:0009AD2C sub eax, edx PAGE:0009AD2E sbb ecx, edi PAGE:0009AD30 add eax, 1 PAGE:0009AD33 mov [esi], eax PAGE:0009AD35 adc ecx, ebx PAGE:0009AD37 mov [esi+4], ecx
通过汇编代码我们可知,这里是将upper先减去lower,再加1,得到两者之间的长度差距(例如 bytes=20-50, 则50-20+1 , 两者之间有31个字节)
按照例子里的写法,就是0xFFFFFFFFFFFFFFFF – 0 + 1 , 确实发生了整数溢出,64位无符号整数上溢为0。
我们来看修改后的版本:
PAGE:0009B501 push ebx PAGE:0009B502 sub eax, edx PAGE:0009B504 push 1 PAGE:0009B506 sbb ecx, edi PAGE:0009B508 push ecx PAGE:0009B509 push eax PAGE:0009B50A mov ecx, esi PAGE:0009B50C call _RtlULongLongAdd@20
这里的代码是将upper 先减去 lower,然后再用RtlUlonglongAdd 将结果同1相加,这里RtlUlonglongAdd会做安全性检查,如果相加结果溢出,则会返回STATUS_INTEGER_OVERFLOW.
由于测试代码中lower传入的是0,所以这里也发生了溢出并被捕获、阻止,但如果lower != 0,这里压根就不会捕获到整数溢出,这是怎么回事呢?真正出现问题的地方是这里吗?
实际上,这可能是POC编写者故意隐藏了一点关键细节: UlpParseRange通过操纵Range参数可以引发整数溢出,也确实被进行了修补,但是并非这个Range数据真正出现问题的地方。
我们进一步推测和分析,发现本次漏洞真正利用的地方,而是UlAdjustRangesToContentSize,这个函数用于最终修正Ranges中指定的StartingOffset和Length的合法性。
首先UrlpParseRange解析了Range参数并获得StartingOffset和Length后,会将其保存在http请求的对象中,而在解析到对应的缓存后,对比Offset + Length的大小,是否超过要请求的缓存文件数据长度,如果超出了,就要把length裁剪为适合的长度,防止读取超出的数据,见如下代码:
PAGE:0007FD09 mov eax, [ebp+length_low] PAGE:0007FD0C add eax, dword ptr [ebp+offset_low] PAGE:0007FD0F mov dword ptr [ebp+offset_low], eax PAGE:0007FD12 mov eax, [ebp+length_high] PAGE:0007FD15 adc eax, dword ptr [ebp+offset_high] ;将Length + Offset PAGE:0007FD18 cmp eax, esi ;esi = content length ,缓存的实际数据长度,进行对比 PAGE:0007FD1A jb short loc_7FD30 PAGE:0007FD1C ja short loc_7FD23 PAGE:0007FD1E cmp dword ptr [ebp+offset_low], ecx PAGE:0007FD21 jb short loc_7FD30 PAGE:0007FD23 PAGE:0007FD23 loc_7FD23: PAGE:0007FD23 PAGE:0007FD23 sub ecx, [ebp+length_low] ;length = contentlength-offset PAGE:0007FD26 mov eax, esi PAGE:0007FD28 sbb eax, [ebp+length_high] PAGE:0007FD2B mov [edx+4], eax
这里我们看到是一处可利用的整数溢出,由于length + offset 实际等于(upper_offset – lower_offset + 1) + lower_offset,当length = -1(0xffffffffffffffff)时,此处结果永远=0,那么显然会小于contentsize,这里就会跳过这个”adjust”的过程,Length没有得到任何处理和修正,我们成功控制了Length。
在这里UlAdjustRangesToContentSize对于offset(lower_offset)还有一处检查(在整数溢出点前面)
else if ( offset_low > HIDWORD(contentlength) || (v12 = contentlength, offset_high >= (unsigned int)contentlength) ) { LABEL_9: if ( v4 < v3 ) { qmemcpy((void *)(ranges – 8), (const void *)(ranges + 8), 4 * (4 * (v3 – v44) & 0x3FFFFFFC)); v4 = v44; }
我们可以看到这个会检查offset是否大于content length,如果大于的话,则会删除这个range,导致这个range失效。
也就是说,UlpParseRange处发生了整数溢出,而在此处导致了安全检查的绕过,同时,如果lower != 0 ,UlpParseRange时不会被触发整数溢出,而是应该在这里得以触发。
到这里我们就弄清楚了这个漏洞的触发流程和原理:
1.upper(range结束的offset) = 0xFFFFFFFFFFFFFFFF时,UlpParseRange或UlAdjustRangesToContentSize会触发整数溢出,导致绕过UlAdjustRangesToContentSize的Length检查
2. Length 可控,但是Length = 0xFFFFFFFFFFFFFFFF – lower(range开始的offset)+1 , lower必须要小于要获取目标文件的数据长度contentlength。
看到很多测试攻击程序的研究人员都无法稳定重现BSOD,看Github上的讨论,通过调整lower的数值,有些人可以打蓝Server 2012 R2,有些人就不行,或者换个文件就不行。
实际上,我们分析了这个漏洞的原理就可以很清楚的了解其中的规律了,首先一条原则是上面已经说到的lower不能大于请求的content length,例如假设请求iisstart.htm(648Bytes),lower就必须小于647。
同时,HTTP请求的处理实际是先通过w3wp发起的进程上下文内http先解析HTTP请求包,组合成紧凑的http回应包后,通过UlSendData->UxTpTransmitPacket->UxpTpEnqueueTransmitPacket排入队列,然后再由工作线程UlSendCacheEntryWorker将其发送出去。
在这个过程中,如果range指定的数据开始offset小于紧凑的数据包头部的总长度,那么这里在计算最后的发包读取数据时,还会触发一个整数溢出,即0xffffffff(-1,已经被变为32位数)- lower + 1 + header size,如果lower < header size,那么将会导致最后32位整数溢出计算出一个较小的数值,这样导致不会BSOD(如果精确控制响应包大小和文件大小,即使这样还是有可能触发BSOD)
因此这里我们让lower 大于 回应包大小,就比较容易可以控制BSOD了
这里我使用wget添加头部的方式测试,回应包的长度应该是(针对Windows 8.1 X86)310个字节,也就是说,lower要大于等于310个字节。
所以,针对wget得到的响应包大小(309),对iisstart.htm文件(648) 的情况下, lower >= 310 且 <= 647 就可以稳定触发BSOD了,其他的情况需要重新计算这个数值。
这个漏洞难道只能BSOD吗?说好的远程代码执行呢?再深入看下漏洞触发的细节,看上去似乎不能远程代码执行,但是远程读取服务器内核内存数据是有可能的。
在UlpSendCacheEntry->UlBuildFastRangeCacheMdlChain中,http.sys会为HTTP回应头和缓存来源buffer/length(我们可控)创建MDL,那么,对于我们的超长length,就会创造一个巨大的mdl,接着放入UxTpTransmitPacket的数据包对象中,通过tcpip->netio,最后解析MDL,将数据最终发出去。
此时是可以超过缓存的空间,读取缓存内存往后的数据,如果缓存内存后面是连续的0xffffffffffffffff – lower(4GB?)左右内核内存(通常是X64),就有可能实现信息泄露。
不过首先是很难有连续的4G内存,同时通过IIS也很难一下获得如此多的数据,那么只能设法降低这个内存要求:length = 0xFFFFFFFFFFFFFFFF – lower ,且lower < contetnlength才行,我们可以想办法提高content length,达到降低Length的目的,例如在服务器上寻找一个接近4GB大小的文件。
还有一个产生较小的Length实现信息泄露的方法,在上一节BSOD里有讲到,就是扩大回应包的数据长度+减小文件大小,利用32位的整数溢出,构造一个比文件大小要大的复制长度,泄露cache buffer后面的内核数据。这需要进一步研究和控制了。
分析时间仓促,有任何进一步的利用和错误之处,欢迎讨论指正。
Update: 2015-4-16 20:15:
更新BSOD/信息泄露部分整数溢出细节。Thanks to pgboy.
Update: 2015-4-19 13:12
更新修正UlAdjustRangesToContentSize中lower不能大于content length的原因细节, Thanks to 张小岑
【原文:MS15-034/CVE-2015-1635 HTTP远程代码执行漏洞分析】
本文作者:SP胖编
本文为安全脉搏专栏作者发布,转载请注明:https://www.secpulse.com/archives/6058.html