Hello! On Thu, Jul 20, 2017 at 10:32:15PM -0700, Shuxin Yang wrote:
> 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. No comments on this, sorry. We generally avoid providing exploitation details to minimize impact on not-yet-updated systems. [...] > 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. This looks like a separate bug, which can result in incorrect Content-Length being returned if a file larger than 4G is requested using multiple ranges on a 32-bit system. Thanks for reporting this. The following patch should fix this: # HG changeset patch # User Maxim Dounin <mdou...@mdounin.ru> # Date 1502291117 -10800 # Wed Aug 09 18:05:17 2017 +0300 # Node ID fc89eec543ee3e41b74347ffa0c59554188dc3f5 # Parent 2f48ab272052d9b2ca00f8192c589b872ee3bc86 Range filter: changed type for total length to off_t. Total length of a response with multiple ranges can be larger than a size_t variable can hold, so type changed to off_t. Previously, an incorrect Content-Length was returned when requesting more than 4G of ranges from a large enough file on a 32-bit system. Reported by Shuxin Yang, http://mailman.nginx.org/pipermail/nginx/2017-July/054384.html. diff --git a/src/http/modules/ngx_http_range_filter_module.c b/src/http/modules/ngx_http_range_filter_module.c --- a/src/http/modules/ngx_http_range_filter_module.c +++ b/src/http/modules/ngx_http_range_filter_module.c @@ -463,7 +463,7 @@ static ngx_int_t ngx_http_range_multipart_header(ngx_http_request_t *r, ngx_http_range_filter_ctx_t *ctx) { - size_t len; + off_t len; ngx_uint_t i; ngx_http_range_t *range; ngx_atomic_uint_t boundary; @@ -569,7 +569,7 @@ ngx_http_range_multipart_header(ngx_http - range[i].content_range.data; len += ctx->boundary_header.len + range[i].content_range.len - + (size_t) (range[i].end - range[i].start); + + (range[i].end - range[i].start); } r->headers_out.content_length_n = len; -- Maxim Dounin http://nginx.org/ _______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
