一个HTTP请求，把网站打裂开了！

今天给大家看一段神奇的代码。

利用这几行神奇的代码，居然能把网站打崩溃，这是怎么一回事呢？

就是下面这个函数，根据传进来的开始和结束位置，读取文件数据：

char* Read(int fd, int start, int end) {
    unsigned int length = end - start + 1;
    if (length > 1024)
        return NULL;

    return ReadFile(fd, start, end);
}

函数中最大只支持一次读取1024个字节，所以增加了一个判断逻辑。

现在请大家思考一下，这个函数有没有什么问题？

---思---

---考---

---5---

---秒---

---钟---

来思考一下，假设我像这样来调用这个函数：

Read(0, 0, 4294967295);

会发生什么事呢？

你可能已经注意到了，这里传了一个很特殊的参数过去，这个数乍一看很大，远远超过了1024，按理说会通不过函数内部的检查对吧？

但事情不是这么简单，这个特殊的数字——4294967295，是32位无符号整数所能表示的最大范围。

但是请注意Read这个函数的参数，start和end都是int型变量，把4294967295传递给end的时候，会被当作有符号的整数解析，也就是 -1 ！

现在来看Read函数中计算长度的这行代码：

unsigned int length = end - start + 1;

计算结果就是-1 - 0 + 1 = 0！

length的结果会是0！

很自然逃过了下面对长度的检查：

if (length > 1024)
    return NULL;

上面这段代码不只是一个假想的模型，实际上，它曾经真实存在过！

它的漏洞编号是：CVE-2015-1635。

这是一个微软的互联网服务器IIS中的一个漏洞，更要命的是，这个漏洞位于IIS处理HTTP请求的HTTP.sys驱动程序中。

你知道的，驱动程序是运行在操作系统内核之中，一旦内核驱动执行出现异常，那后果，轻则蓝屏崩溃，重则直接被攻击者远程执行代码，控制服务器！

在HTTP 1.1版本的协议中，可以通过请求头中的Range字段，请求或上传指定资源的部分内容，比如像这样：

GET /bg-upper.png HTTP/1.1
User-Agent: curl/7.35.0
Host: 127.0.0.1:8180
Accept: */*
Range: bytes=0-10

其中的Range字段格式如下：

Range: bytes=start-end

微软的IIS为了提高性能，将HTTP协议的解析放在了内核驱动HTTP.sys中实现。

而其中对range字段的处理，就存在我们文章开头的那个逻辑错误，不同的是，我们上面的那个示例是一个32位整数的版本，而IIS这个真实的漏洞是64位整数产生的问题，但原理是一样的。

通过向存在漏洞的IIS服务器发送对应的HTTP请求，即可将目标服务器打蓝屏，实现DOS——拒绝服务攻击。

这种攻击方式就是——整数溢出攻击。

接下来，咱们在搭建一个环境来验证一下。

在虚拟机中搭建一个IIS7的Web服务器：

64位无符号整数能表示的最大数是：18446744073709551615，通过向服务器发送包含range参数的请求，有很大可能会导致服务器蓝屏。

使用神器metasploit来利用这个漏洞发起攻击：

现在来看，服务器已经挂了：

为什么是很大可能，而不是一定蓝屏呢，如何实现稳定把服务器打蓝屏呢？这就需要进一步了解这个漏洞更详细的情况。

实际上这个漏洞原理比文章开头的那个逻辑要更复杂一些，这里只是做了一个简单入门介绍，关于这个漏洞的更详细情况，大家可以看一下360大神MJ0011当年写的一篇技术分析（PS：有点硬核，想要看懂得反复多看几次）：

《MS15-034/CVE-2015-1635 HTTP远程代码执行漏洞分析》

https://blogs.360.cn/post/cve_2015_6135_http_rce_analysis.html

我们平时在编程的时候，一定要注意变量的数据类型，特别是涉及到数据类型转换的地方要格外留神。比如符号数与无符号数的互转，32位整数和64位整数的转换等等。

在处理外界传入的参数处理时，要慎之又慎，一个小小的变量类型可能就会给服务器计算机造成毁灭性打击。