Bug in ngx_http_slice_filter_module ngx_http_slice_parse_content_range function

[Carey Gister]

Hi Maxim,

Thank you for your reply.  My use case is as follows:

After the slice header filter calls ngx_http_next_header_filter the contents of the request headers_out fields will be modified if an If-Range header is valid.  The production version of the slice header filter already relies on the modified headers_out fields set by the range filter.

My extension needs to know the bounds of the new range IF the If-Range header is valid. So I parse the new content_range value using the ngx_http_slice_parse_content_range function to return the stored values.

If this is incorrect, then please tell me how I can know if the If-Range header is valid, preferably without duplicating the code in the range filter, and if it is valid, what the correct range values will be.

Parenthetically, the behavior I observe is that the computer headers_out.content_range value IS null terminated EXCEPT when the request is read from a disk cache. In this case, the string IS NOT null terminated and instead, has an 'L' (ASCII decimal value 77) after the length of bytes indicated in the ngx_str_t. The existing ngx_http_slice_parse_content_range function fails with an NGX_ERROR return when the string IS NOT null terminated.

Carey Gister



________________________________
From: nginx-devel <nginx-devel-bounces at nginx.org> on behalf of Maxim Dounin <mdounin at mdounin.ru>
Sent: Saturday, June 29, 2019 03:32
To: nginx-devel at nginx.org
Subject: Re: Bug in ngx_http_slice_filter_module ngx_http_slice_parse_content_range function

Hello!

On Thu, Jun 27, 2019 at 02:01:27AM +0000, Carey Gister wrote:

> The ngx_http_slice_parse_content_range function assumes that the
> parsed buffer is null terminated. Since the buffer is an
> ngx_str_t, that assumption is false. If, by chance, the buffer
> is null terminated it is simply a matter of luck, and not
> design.

In many cases ngx_str_t is used for null-terminated strings.
Most simple example is directive arguments during configuration
parsing - while arguments are using ngx_str_t type, they are
guaranteed to be null-terminated.  Other examples are input
headers, and upstream input headers.  The latter implies that
response Content-Range header will be null-terminated as seen by
the slice module - unless you are producing it with some custom
module.

> In particular, if the headers_out.content_range ngx_str_t was
> allocated in the ngx_http_range_filter_module then the buffer
> was allocated as a non-zero terminated buffer by ngx_pnalloc.

The range filter works after the slice module, hence whatever is
set in the headers_out.content_range field by the range filter
cannot affect slice module.  Further, if slice module ever uses
Content-Range header set by the range filter, this would indicate
a severe bug, as it is expected to use Content-Range header from a
backend response, not Content-Range header from the resulting
response to the client.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-devel mailing list
nginx-devel at nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20190701/db7ceca2/attachment-0001.html>