HI, There:
I try to exploit this bug in an attempt to do something nasty :-).
However, the more I dig into it, the more I get confused.
As far as I know, one necessary conditional to trigger the problem
is that range-filter kicks in, and range-filter is called if and *ONLY*
if (FIXME):
1) Nginx serves static file.
2) Nginx serves as a reverse-proxy *with* cache capability, and the
resource being accessed is *cache-able*. In this case, the proxy will
fetch the entire file from origin, cache it, then send the ranges down
to downstream via range-filter. (If content is not cache-able, range
range in reverse proxy will not be enabled, instead, the range request
is directly forwarded to upstream. Also, in proxy without cache, rang
filter will not be invoked)
Questions:
======
a). Does this bug have any negative impact to 1)?
b). Where exactly does buffer overflow take place? How does this
patch resolve the problem. As far as I can understand, the patch only
check if total size of the ranges exceeds 4G (assuming 32-bit system for
simplicity). The start/end pointer of each range is guaranteed in the
range of "[0, content-length]" regardless the patched condition.
c) Could following statement have overflow problem as well when the
start/end point is very close 4G?
850 if (ngx_buf_in_memory(buf)) {
851 b->pos = buf->pos + (size_t) range[i].start;
852 b->last = buf->pos + (size_t) range[i].end;
853 }
d) the patch guarantees the total size of ranges is smaller than 4G
(again, assume 32bit system). But what if it ends up very close to 4G,
making the "len" variable in function variable
ngx_http_range_multipart_header() overflow. The "len" is to calculate
the content-length the resulting response, it is the total size of
multi-part overhead plus ranges.
Is there any simple example to reproduce the problem?
Thanks a lot!
Shuxin
On 07/11/2017 08:47 AM, Maxim Dounin wrote:
> Hello!
>
> A security issue was identified in 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).
>
> When using nginx with standard modules this allows an attacker to
> obtain a cache file header if a response was returned from cache.
> In some configurations a cache file header may contain IP address
> of the backend server or other sensitive information.
>
> Besides, with 3rd party modules it is potentially possible that
> the issue may lead to a denial of service or a disclosure of
> a worker process memory. No such modules are currently known though.
>
> The issue affects nginx 0.5.6 - 1.13.2.
> The issue is fixed in nginx 1.13.3, 1.12.1.
>
> For older versions, the following configuration can be used
> as a temporary workaround:
>
> max_ranges 1;
>
> Patch for the issue can be found here:
>
> http://nginx.org/download/patch.2017.ranges.txt
>
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
