一般来说，range作为原始文件的一部分，其长度应该是小于content-length的。所以一旦计算得到的size比content-length还大，那就直接将原始文件返回了，不再进行range处理。为了绕过这一限制，我们就需要利用到第一处修复所处理的情形。
具体而言，检查用到的size是将multipart的全部range长度相加得到的：
因此，一个range是不够的，我们至少需要两个range，其长度之和溢出为负数，就可以绕过总长度的检查了。
要得到一个很大长度的range，同样可以采用-end这种后缀型，将end设置为一个非常大的数即可。此处的start, end, size均为64位有符号整形，所以只需要最终相加得到的size为0×8000000000000000即可。
5 、漏洞利用本次复现利用使用Nginx-1.12.0作为缓存服务器，缓存配置同上文，访问的目标文件仍然是upload/2017_07/1707191437950121.png。
首先，我们不指定range，得到该图片文件的长度为7877:
设置第一段range为-8500，此时的start为7877-8500=-623，即图片在Cache文件偏移之前的623 bytes也会被返回，而这623 bytes中就包含了Cache文件头部。
下一步，按照上文所说，第二段range的长度需要将总长度溢出。我们的目标总和size为0×8000000000000000，第一段range长度为8500，故第二段range长度为0×8000000000000000-8500=9223372036854767308。
于是，使用curl命令，配合-r参数指定bytes range：
可以看到返回内容中，第一段即为-8500的range，而这一段中我们就看到了Cache文件头部，例如cache key以及后端服务器返回的HTTP头。
6、漏洞修复综合来看，这个漏洞就是整数溢出漏洞的利用，能够从Cache文件中获取Cache头的信息。在某些配置的情况下Cache头中会存在IP地址信息，造成信息泄露。
就Nginx模块以及常用的第三方模块本身来说，无法通过这个整数溢出来对内存进行操作或者远程执行。
建议升级到1.13.3和1.12.1版本；如果不能升级，可以在Nginx配置文件中添加max_ranges 1，从而禁用multipart range。