nginx security advisory (CVE-2017-7529)

[Shuxin Yang]

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
>
>