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