新闻链接：bf1K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6h3k6J5k6h3g2T1N6h3k6Q4x3X3g2U0L8$3#2Q4x3V1k6$3N6h3I4K6i4K6u0r3y4U0b7I4z5e0g2Q4x3X3g2Z5N6r3#2D9
   新闻时间：2015-04-16
   新闻正文：前言

在4月的补丁日，微软通过标记为“高危”的MS15-034补丁，修复了HTTP.SYS中一处远程代码漏洞CVE-2015-1635。据微软公告（bd2K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6@1k6h3y4Z5L8X3g2@1i4K6u0W2L8h3W2U0M7X3!0K6L8$3k6@1i4K6u0W2j5$3!0E0i4K6u0r3k6h3&6Q4x3X3c8#2M7#2)9J5c8X3I4A6j5Y4u0S2M7Y4W2Q4x3V1k6K6k6h3y4#2M7X3W2@1P5g2)9J5c8V1#2e0x3e0g2Q4x3X3b7H3x3K6c8Q4c8f1k6Q4b7V1y4Q4z5o6W2Q4c8e0k6Q4z5o6W2Q4z5o6m8Q4c8e0N6Q4b7e0N6Q4b7U0m8Q4c8f1k6Q4b7V1y4Q4z5p5y4Q4c8e0g2Q4b7V1c8Q4z5e0y4Q4c8e0g2Q4b7f1c8Q4z5e0S2Q4c8e0g2Q4z5f1y4Q4b7e0S2Q4c8e0S2Q4b7f1k6Q4b7e0g2Q4c8e0k6Q4b7V1y4Q4z5p5k6Q4c8e0k6Q4b7U0c8Q4z5f1g2Q4c8e0N6Q4z5f1q4Q4z5o6c8t1g2q4c8b7i4@1f1$3i4K6W2o6i4K6S2p5i4@1f1#2i4K6S2m8i4@1p5I4i4@1f1#2i4K6V1&6i4@1p5^5i4@1f1$3i4K6S2q4i4@1p5#2i4@1f1$3i4K6V1@1i4@1t1$3i4@1f1#2i4K6R3^5i4@1t1H3i4@1f1%4i4@1t1J5i4@1u0q4i4@1f1#2i4@1u0r3i4K6R3K6i4@1f1$3i4K6W2q4i4K6R3@1i4@1f1&6i4K6R3H3i4@1p5H3i4@1f1%4i4K6W2m8i4K6R3@1d9q4c8f1f1q4!0q4z5q4!0m8c8W2!0n7y4#2!0q4y4W2!0n7x3g2)9^5x3W2!0q4y4W2)9&6y4#2!0n7y4W2!0q4c8W2!0n7b7#2)9^5b7#2!0q4y4g2)9^5c8W2!0m8c8W2!0q4z5q4)9^5x3#2!0n7c8q4!0q4z5q4!0m8y4#2!0m8y4W2!0q4y4g2)9^5c8W2)9&6x3g2!0q4z5q4!0n7c8W2)9&6b7#2!0q4y4#2!0m8z5q4)9^5b7W2!0q4y4q4!0n7b7W2!0m8x3#2!0q4y4#2!0m8x3q4)9^5x3g2!0q4y4g2)9&6b7#2!0m8z5q4!0q4y4#2)9&6b7W2!0m8c8g2!0q4y4W2!0m8x3q4)9^5y4#2!0q4y4#2!0n7x3#2!0n7b7W2!0q4y4#2!0n7b7W2)9&6c8W2!0q4y4q4!0n7b7W2!0m8y4g2!0q4y4#2!0n7x3#2!0n7b7W2!0q4y4#2!0n7b7W2)9&6c8W2!0q4y4W2)9&6c8q4)9^5x3#2!0q4z5g2)9&6z5g2)9&6x3q4!0q4y4W2)9^5z5g2!0m8y4#2!0q4z5q4!0m8x3g2)9^5b7#2!0q4x3#2)9^5x3q4)9^5x3R3`.`.

这是对于服务器系统影响不小的安全漏洞，任何安装了微软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网站上贴出的信息（7a6K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4m8S2M7%4c8W2j5X3W2F1i4K6u0W2j5$3!0E0i4K6u0r3P5i4m8g2f1V1c8b7j5K6c8Q4c8f1k6Q4b7V1y4Q4z5o6W2Q4c8e0g2Q4z5e0u0Q4z5p5y4Q4c8e0g2Q4b7V1g2Q4b7f1g2Q4c8e0S2Q4b7V1c8Q4b7f1k6Q4c8e0g2Q4z5o6g2Q4b7f1y4Q4c8e0g2Q4z5e0q4Q4z5p5q4Q4c8f1k6Q4b7V1y4Q4z5p5y4Q4c8e0k6Q4z5o6S2Q4z5e0q4Q4c8e0c8Q4b7V1u0Q4b7f1y4Q4c8e0N6Q4z5f1k6Q4b7e0g2Q4c8e0W2Q4z5o6q4Q4z5e0y4Q4c8e0S2Q4b7V1k6Q4z5e0W2Q4c8e0k6Q4z5e0S2Q4b7f1k6Q4c8e0c8Q4b7U0S2Q4z5o6m8Q4c8e0c8Q4b7U0S2Q4b7f1q4Q4c8e0c8Q4b7V1c8Q4z5p5c8Q4c8e0c8Q4b7V1q4Q4z5p5g2t1g2q4c8b7i4K6u0W2f1#2W2e0i4@1f1@1i4@1t1^5i4@1q4p5i4@1f1%4i4K6W2m8i4K6R3@1i4@1f1$3i4K6V1#2i4@1t1@1i4@1f1$3i4K6V1#2i4@1t1H3i4@1f1$3i4@1u0m8i4@1p5J5i4@1f1#2i4K6R3%4i4@1u0m8i4@1f1$3i4@1u0o6i4K6S2r3i4@1f1$3i4@1t1@1i4K6W2q4i4@1g2r3i4@1u0o6i4K6S2o6i4@1f1$3i4@1p5H3i4@1t1&6i4@1f1$3i4K6S2p5i4@1q4q4f1r3q4K6N6r3g2T1K9h3&6Q4c8e0N6Q4b7V1c8Q4z5e0q4Q4c8e0N6Q4b7f1u0Q4z5e0W2Q4c8e0N6Q4z5f1q4Q4z5o6c8H3P5i4c8Z5L8$3&6Q4c8e0c8Q4b7V1u0Q4b7e0y4Q4c8e0N6Q4b7e0m8Q4z5o6q4Q4c8f1k6Q4b7V1y4Q4z5p5y4Q4c8e0k6Q4z5o6S2Q4z5e0q4Q4c8e0c8Q4b7V1u0Q4b7f1y4Q4c8e0N6Q4z5f1k6Q4b7e0g2Q4c8e0W2Q4z5o6q4Q4z5e0y4Q4c8e0W2Q4z5o6m8Q4z5f1q4Q4c8e0S2Q4b7V1k6Q4z5o6N6Q4c8e0N6Q4b7V1u0Q4z5e0W2u0d9g2y4Q4c8e0k6Q4z5f1y4Q4z5p5c8Q4c8e0g2Q4z5p5q4Q4b7e0q4Q4c8e0g2Q4z5e0W2Q4b7e0S2Q4c8e0g2Q4z5p5k6Q4z5e0q4Q4c8e0W2Q4z5o6m8Q4z5o6q4Q4c8e0S2Q4b7V1k6Q4z5e0W2Q4c8e0k6Q4b7e0m8Q4b7U0N6Q4c8e0k6Q4b7e0m8Q4b7V1y4Q4c8e0g2Q4b7V1y4Q4z5p5k6Q4c8e0N6Q4z5f1q4Q4z5o6c8t1g2q4c8b7i4@1f1^5i4@1q4r3i4@1t1%4i4@1f1$3i4@1t1I4i4K6R3J5i4@1g2r3i4@1u0o6i4K6S2o6i4@1f1#2i4@1t1H3i4@1t1I4i4@1f1#2i4K6S2r3i4@1q4r3i4@1f1@1i4@1u0n7i4@1p5#2i4@1f1^5i4@1p5%4i4@1p5$3i4@1f1#2i4K6S2r3i4K6V1I4i4@1g2r3i4@1u0o6i4K6R3^5i4@1f1$3i4@1p5K6i4K6R3H3i4@1f1$3i4@1t1#2i4K6S2n7i4@1g2r3i4@1u0o6i4K6R3&6i4@1f1^5i4@1u0r3i4K6V1&6i4@1f1@1i4@1t1^5i4@1q4m8i4@1f1$3i4@1u0o6i4K6S2r3i4@1f1$3i4@1t1@1i4K6W2q4i4@1g2r3i4@1u0o6i4K6W2m8

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”一章（b8bK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6@1k6h3y4Z5L8X3g2@1i4K6u0W2L8h3W2U0M7X3!0K6L8$3k6@1i4K6u0W2j5$3!0E0i4K6u0r3k6h3&6Q4x3X3c8#2M7#2)9J5c8X3I4A6j5Y4u0S2M7Y4W2Q4x3V1k6U0j5K6M7K6z5e0b7H3x3q4)9J5z5s2k6Q4x3@1c8%4M7#2)9J5k6e0p5H3i4K6t1&6i4K6u0W2j5i4y4H3P5q4)9J5z5g2!0q4x3#2)9^5x3q4)9^5x3R3`.`. 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”(70eK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6i4u0X3j5#2)9J5k6r3g2V1K9i4c8G2M7W2)9J5k6h3!0J5k6#2)9J5c8Y4u0X3j5#2)9J5c8Y4u0X3j5K6M7J5x3K6y4Q4x3X3g2@1P5s2c8Q4x3U0W2Q4c8e0y4Q4z5o6m8Q4z5o6t1`.

这里先简单介绍一下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

我们看看未修补前的代码是怎么样写的

通过汇编代码我们可知，这里是将upper先减去lower，再加1，得到两者之间的长度差距（例如 bytes=20-50, 则50-20+1 , 两者之间有31个字节）

按照例子里的写法，就是0xFFFFFFFFFFFFFFFF – 0 + 1 ， 确实发生了整数溢出，64位无符号整数上溢为0。

我们来看修改后的版本：

这里的代码是将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裁剪为适合的长度，防止读取超出的数据，见如下代码：

这里我们看到是一处可利用的整数溢出，Length + offset 如果发生溢出，就会小于contentsize，这里就会跳过这个”adjust”的过程，Length没有得到任何处理和修正，我们成功控制了Length。

以例子中的数值为例， length + offset = (0xFFFFFFFFFFFFFFFF + 1 ) + 0 (这个+ 1是前面UlpParseRange添加的） = 0 ，小于contentsize

而假设lower不为0，则结果 = lower ,只要结果小于contentsize，也是不会被adjust的。

也就是说，UlpParseRange处发生了整数溢出，而在此处导致了安全检查的绕过，同时，如果lower != 0 ，UlpParseRange时不会被触发整数溢出，而是应该在这里得以触发。

到这里我们就弄清楚了这个漏洞的触发流程和原理：

1.upper(range结束的offset) = 0xFFFFFFFFFFFFFFFF时，UlpParseRange或UlAdjustRangesToContentSize会触发整数溢出,导致绕过UlAdjustRangesToContentSize的Length检查
2. Length 可控，但是Length = 0xFFFFFFFFFFFFFFFF – lower（range开始的offset） ， 且lower必须要小于要获取目标文件的数据长度contentlength。
BSOD的重现和原理

看到很多测试攻击程

[培训]科锐逆向工程师培训第53期2025年7月8日开班！