今天给大家看一段神奇的代码。
利用这几行神奇的代码，居然能把网站打崩溃，这是怎么一回事呢？
就是下面这个函数，根据传进来的开始和结束位置，读取文件数据：
- 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位整数的转换等等。
在处理外界传入的参数处理时，要慎之又慎，一个小小的变量类型可能就会给服务器计算机造成毁灭性打击。
