The Nginx range filter plastic overflow vulnerability (CVE–2017–7529)early warning analysis-vulnerability warning-the black bar safety net

I. background description
A security issue was identified in the nginx range filter. A specially crafted request might result in an integer overflow and incorrect processing of ranges, potentially resulting in sensitive information leak (CVE-2017-7529).
-- http://mailman.nginx.org/pipermail/nginx-announce/2017/000200.html
In 2017 7 on 11 May, Nginx in the official announcement that found a range filter in the security issues. Through a carefully constructed malicious requests could cause an integer overflow, the scope of improper processing will result in sensitive information leakage. And assigned CVE-2017-7529 in.
II. Vulnerability overview
When using the nginx standard module, the attacker can send a malicious construct a range field of the header of the request to obtain the response in the cache file header information. In some configurations, the cache file header may contain the back-end server’s IP address or other sensitive information, resulting in information disclosure.
III. Vulnerability impact
Affect
The vulnerability affects all 0. 5. 6 - 1.13.2 version within the default configuration of the modules of Nginx only need to open the cache the attacker can send a malicious request to a remote attack causing information leak.
When the Nginx server is using a proxy cache in the case the attacker by exploiting the vulnerability can get to the server after the end of the real IP or other sensitive information.
Through our analysis of the determination of the exploitability of the vulnerability of low difficulty can be attributed to the low-hanging-fruit vulnerabilities in real network attack also has a certain use value.
Impact version
Nginx version 0.5.6 - 1.13.2
Fix version
Nginx version 1.13.3, 1.12.1
IV. Repair recommendations
The official patch is already in 7 on 11 December release
http://mailman.nginx.org/pipermail/nginx-announce/2017/000200.html
http://nginx.org/download/patch.2017.ranges.txt
Recommends that affected users upgrade as soon as possible to 1. 13. 3, 1.12.1 or timely patch
V. vulnerability details
Brief Technical details
By looking at the patch to determine the problem is due to the http header in the range domain processing caused by improper, the focus in ngx_http_range_parse function in a loop:
! [](/Article/UploadPic/2017-7/201771491247594. png? www. myhack58. com)
! [](/Article/UploadPic/2017-7/201771491248708. png? www. myhack58. com)
HTTP header range domain the content is about Range: bytes=4096-8192
bytes=-string pointer p is“bytes=”behind the content
This code is to put“-”on both sides of the numbers removed were assigned to the start and end variable markers to read the file offset and the end position.
For the General page of the file these two values are how to play are okay. But for the Extra the head of the cache file if the start value is a negative right negative value then it means that the cache file header will be read.
A cache file of the examples:
! [](/Article/UploadPic/2017-7/201771491248622. png? www. myhack58. com)
So we look at how to construct the Range to the start of the design is negative.
The first code in the cutoff and cutlim valve the amount of the guarantee each time directly from the string when reading does not make the start or end to a negative value. Then can make start is negative, the chance is only in the suffix tag is a really small branch.
Therefore we need to make the suffix = 1 thus can be extrapolated to the Range of content is bound to Range:bytes=-xxx that is, omit the initial start value of the form.
Then we can through the Range, set the end value is greater than content_length（true the length of the file, so the start will automatically be corrected to a negative value.
But in the written use of the process found a problem if the end value is large then the start of the absolute value will also be the General Assembly more than the cache file starting the head to cause the read to fail. If the end value is not large enough then in terms of down size = end – 1 >= content_length （end > content_length see previously described is not circulating through the outside of the detection:
! [](/Article/UploadPic/2017-7/201771491248302. png? www. myhack58. com)
So it seems no matter set end why the values are not reached. Continue to follow the code found in this loop is an unconditional loop:
! [](/Article/UploadPic/2017-7/201771491248191. png? www. myhack58. com)
Tail:
! [](/Article/UploadPic/2017-7/201771491248988. png? www. myhack58. com)
That is if the Range of the domain-such as Range: bytes=start-end,start1-end1,…will also have the opportunity to continue to complete the exploit.
We can construct a Range: bytes=-X, -Y
One large and one small two end values only need to control the front with one end a small value and then an end value is large in order to achieve the start value and the size value are all negative, the control start value is a negative to a suitable location, then you can be successful using the read to the cache file header.
VI. Exploit verification
By default, Nginx module configuration to open the cache:
! [](/Article/UploadPic/2017-7/201771491248384. png? www. myhack58. com)
Cache file contents are as follows:
! [](/Article/UploadPic/2017-7/201771491248619. png? www. myhack58. com)
To exploit the vulnerability successfully read the reverse of cross-border read 491 bytes:
! [](/Article/UploadPic/2017-7/201771491248489. png? www. myhack58. com)
VII. Timeline
2017-7-11 Nginx official released a security announcement and patch
2017-7-12 360CERT( https://cert.360.cn )to complete the vulnerability analysis and use case analysis
2017-7-13 the release of the early warning analysis advertisement
VIII. Reference source
http://mailman.nginx.org/pipermail/nginx-announce/2017/000200.html
http://nginx.org/download/patch.2017.ranges.txt