atom feed14 messages in ru.sysoev.nginxnginx and Apache killer
FromSent OnAttachments
Igor SysoevAug 27, 2011 1:10 am.ranges
Juan Angulo MorenoAug 27, 2011 7:03 pm 
Maxim DouninAug 28, 2011 1:45 am 
Venky ShankarAug 28, 2011 2:41 am 
Gena MakhomedAug 28, 2011 7:18 am 
Maxim DouninAug 28, 2011 7:24 am 
Maxim DouninAug 28, 2011 9:35 am 
Venky ShankarAug 28, 2011 9:48 am 
Maxim DouninAug 28, 2011 1:21 pm 
Gena MakhomedAug 28, 2011 1:38 pm 
Maxim DouninAug 28, 2011 5:14 pm 
Gena MakhomedAug 29, 2011 11:30 am 
Igor SysoevAug 29, 2011 11:45 am 
Jim OhlsteinSep 1, 2011 4:59 am 
Subject:nginx and Apache killer
From:Igor Sysoev (ig@sysoev.ru)
Date:Aug 27, 2011 1:10:23 am
List:ru.sysoev.nginx
Attachments:
patch.ranges - 2k

Following "Apache Killer" discussions and the advisory from 2011-08-24 (Advisory: Range header DoS vulnerability Apache HTTPD 2.x CVE-2011-3192) we'd like to clarify a couple of things in regards to nginx behavior either in standalone or "combo" (nginx+apache) modes.

First of all, nginx doesn't favor HEAD requests with compression, so the exact mentioned attack doesn't work against a standalone nginx installation.

If you're using nginx in combination with proxying to apache backend, please check your configuration to see if nginx actually passes range requests to the backend:

1) If you're using proxying WITH caching then range requests are not sent to backend and your apache should be safe.

2) If you're NOT using caching then you might be vulnerable to the attack.

In order to mitigate this attack when your installation includes apache behind nginx we recommend you the following:

1. Refer to the above mentioned security advisory CVE-2011-3192 for apache and implement described measures accordingly.

2. Consider using nginx configuration below (in server{} section of configuration). This particular example filters 5 and more ranges in the request:

if ($http_range ~ "(?:\d*\s*-\s*\d*\s*,\s*){5,}") { return 416; }

We'd also like to notify you that for standalone nginx installations we've produced the attached patch. This patch prevents handling malicious range requests at all, instead outputting just the entire file if the total size of all ranges is greater than the expected response.

-- Igor Sysoev

Index: src/http/modules/ngx_http_range_filter_module.c =================================================================== --- src/http/modules/ngx_http_range_filter_module.c (revision 4034) +++ src/http/modules/ngx_http_range_filter_module.c (working copy) @@ -146,7 +146,6 @@ ngx_http_range_header_filter(ngx_http_request_t *r) { time_t if_range; - ngx_int_t rc; ngx_http_range_filter_ctx_t *ctx;

if (r->http_version < NGX_HTTP_VERSION_10 @@ -192,10 +191,9 @@ return NGX_ERROR; }

- rc = ngx_http_range_parse(r, ctx); + switch (ngx_http_range_parse(r, ctx)) {

- if (rc == NGX_OK) { - + case NGX_OK: ngx_http_set_ctx(r, ctx, ngx_http_range_body_filter_module);

r->headers_out.status = NGX_HTTP_PARTIAL_CONTENT; @@ -206,15 +204,16 @@ }

return ngx_http_range_multipart_header(r, ctx); - }

- if (rc == NGX_HTTP_RANGE_NOT_SATISFIABLE) { + case NGX_HTTP_RANGE_NOT_SATISFIABLE: return ngx_http_range_not_satisfiable(r); - }

- /* rc == NGX_ERROR */ + case NGX_ERROR: + return NGX_ERROR;

- return rc; + default: /* NGX_DECLINED */ + break; + }

next_filter:

@@ -235,11 +234,12 @@ ngx_http_range_parse(ngx_http_request_t *r, ngx_http_range_filter_ctx_t *ctx) { u_char *p; - off_t start, end; + off_t start, end, size; ngx_uint_t suffix; ngx_http_range_t *range;

p = r->headers_in.range->value.data + 6; + size = 0;

for ( ;; ) { start = 0; @@ -277,9 +277,10 @@

range->start = start; range->end = r->headers_out.content_length_n; + size += range->end - start;

if (*p++ != ',') { - return NGX_OK; + break; }

continue; @@ -331,10 +332,18 @@ range->end = end + 1; }

+ size += range->end - start; + if (*p++ != ',') { - return NGX_OK; + break; } } + + if (size > r->headers_out.content_length_n) { + return NGX_DECLINED; + } + + return NGX_OK; }