nginx and Apache killer

[Venky Shankar]

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

Well, with apache; the problem is not really due to the compression module
(you can disable compression and still get DoS'ed)

It is with how it handles byte ranges (by ignoring overlapping ranges
etc...)

Currently with apache requests like

Range: bytes=0-1,0-2,0-3...................... <nnn-nnn>

OR

Range: bytes=0-0, 1-1, 2-2.................<nnn-nnn>

will not result in merging of the ranges and deliver data for each range.
With huge number of those ranges there is a lot of memory consumed.



>
> 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
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
>



-- 
Astalavista Baby!!!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20110828/929c91e6/attachment.html>