Bug in ngx_http_slice_filter_module ngx_http_slice_parse_content_range function

[Maxim Dounin]

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/