Re: DoS with mod_deflate range requests
On Wednesday 24 August 2011, Roy T. Fielding wrote: My suggestion is to reject any request with overlapping ranges or more than five ranges with a 416, and to send 200 for any request with 4-5 ranges. There is simply no need to support random access in HTTP. Even with WebDAV? BTW, I think Adobe reader does range requests to download single pages from a pdf. It would be interesting to see what kind of requests it does, but I don't have it installed right now.
RE: DoS with mod_deflate range requests
-Original Message- From: Stefan Fritsch Sent: Mittwoch, 24. August 2011 00:28 To: dev@httpd.apache.org Subject: Re: DoS with mod_deflate range requests On Tuesday 23 August 2011, William A. Rowe Jr. wrote: On 8/23/2011 4:00 PM, Greg Ames wrote: On Tue, Aug 23, 2011 at 3:32 PM, William A. Rowe Jr. wrote: I suggest we should be parsing and reassembling the list before we start the bucket logic. I propose we satisfy range requests in the only sensible manner, returning the ranges in sequence, yeah, overlapping ranges should be merged up front. That ought to completely fix the issue. So the only remaining question; are we free to reorder them into sequence? Good point. I haven't seen anything in the RFC about that. I guess that there are at least some clients that will be broken by that. Nevertheless, I have done a first try at a patch. The necessary modification to only merge and not reorder should be small. I have done only limited testing, so there are probably some bugs. There are no tests with multiple ranges in the test-framework, yet. Even in the most pedantic case, I believe that the total array shouldn't ever exceed 1024, because in those cases a large number of the acceptable expected ranges should be in the nnn-nnn, format, or 8 characters long, out of our MAX_LINE_LENGTH of some 8190. If we argue that asking for single bytes is simply wrong, we should probably allocate some 16 ranges and grow the list by a power of four, resulting in a max of some 4 allocs and maximum memory consumption of less than 64k per request. Just counting the commas in the header line seems acceptable to me. In any case, single byte ranges are explicitly mentioned in the RFC as example, so we probably should not disallow those. Patch looks good, but some comments: As far as I can see the following range request would not get merged: Range: bytes=0-0,1-1,2-2 into a 0-2 range as need_sort would remain 0. OTOH Range: bytes=0-0,0-1,1-2 would get get merged into a 0-2 range. Using boundary and !boundary in the later if statements to decide whether a request is multi range or single range is IMHO bad as boundary is set based on the old number ranges and not based on the number of merged ranges. So multiple ranges in the beginning might get merged to a single range in the end. Regards Rüdiger
CT oops?
G/E, httpd-trunk\modules\ssl\ssl_engine_config.c (164): mctx-pkp-cert_file = NULL; mctx-pkp-cert_path = NULL; mctx-pkp-ca_cert_file = NULL mctx-pkp-certs = NULL; mctx-pkp-ca_certs = NULL; Seems like there is a need of punctuation... This one is trickier: httpd-trunk\modules\ssl\mod_ssl.c (175): ### mwccnlm Compiler: #File: mod_ssl.c # -- # 175: ProxyMachineCertificateChainFile, ssl_cmd_SSLProxyMachineCertificateChainFile, ((void *) 0), 128, TAKE1, SSL Proxy: file # Error: ^ # undefined identifier 'ssl_cmd_SSLProxyMachineCertificateChainFile' an extern perhaps? N.
CVE (Was: DoS with mod_deflate range requests)
Folks,
Have we done (or who is doing a CVE) on this ? So we get immediate 'fixes' out
like a tiny patch to count the comma's, a caveated LimitRequestFieldSize 100 or
a clever Regex on %{HTTP_Range}.
Or am I totally asleep and missed the CVE (as my google foo only nets me
CVE-2005-2728 right now - which is from 2005!).
Dw.
RE: CT oops?
-Original Message- From: NormW [mailto:no...@gknw.net] Sent: Mittwoch, 24. August 2011 10:12 To: dev@httpd.apache.org Subject: CT oops? G/E, httpd-trunk\modules\ssl\ssl_engine_config.c (164): mctx-pkp-cert_file = NULL; mctx-pkp-cert_path = NULL; mctx-pkp-ca_cert_file = NULL mctx-pkp-certs = NULL; mctx-pkp-ca_certs = NULL; Seems like there is a need of punctuation... Fixed in r1161002. This one is trickier: httpd-trunk\modules\ssl\mod_ssl.c (175): ### mwccnlm Compiler: #File: mod_ssl.c # -- # 175: ProxyMachineCertificateChainFile, ssl_cmd_SSLProxyMachineCertificateChainFile, ((void *) 0), 128, TAKE1, SSL Proxy: file # Error: ^ # undefined identifier 'ssl_cmd_SSLProxyMachineCertificateChainFile' an extern perhaps? Fixed in r1161005 Regards Rüdiger
Re: CT oops?
On 24/08/2011 6:42 PM, Plüm, Rüdiger, VF-Group wrote: Fixed in r1161002. Fixed in r1161005 Regards Rüdiger Confirm httpd-trunk now builds for NetWare without issue. Thx. Norm
Mitigation Range header (Was: DoS with mod_deflate range requests)
Folks, This issue is now active in the wild. So some unified/simple comms is needed. What is the wisdom on mitigation advise/briefing until a proper fix it out - in order of ease: - Where possible - disable mod_deflate = we sure this covers all cases - or this is a good stopgap ? - Where possible - set LimitRequestFieldSize to a small value - Suggesting of 128 fine ? - Where this is not possible (e.g. long cookies, auth headers of serious size) consider using mod_rewrite to not accept more than a few commas = anyone a config snipped for this ? - Perhaps a stop gap module http://people.apache.org/~dirkx/mod_rangecnt.c (is this kosher??) - Apply patch XXX from the mailing list Any thoughts ? Followed by a - upgrade as soon as a release is made Thanks, Dw
CVE-2011-3192 (Was: CVE (Was: DoS with mod_deflate range requests))
The new Range: header has been given the CVE of
CVE-2011-3192
Please use that in subjects, commits and what not.
Thanks,
Dw.
On 24 Aug 2011, at 09:28, Dirk-Willem van Gulik wrote:
Folks,
Have we done (or who is doing a CVE) on this ? So we get immediate 'fixes'
out like a tiny patch to count the comma's, a caveated LimitRequestFieldSize
100 or a clever Regex on %{HTTP_Range}.
Or am I totally asleep and missed the CVE (as my google foo only nets me
CVE-2005-2728 right now - which is from 2005!).
Dw.
RE: Mitigation Range header (Was: DoS with mod_deflate range requests)
-Original Message-
From: Dirk-Willem van Gulik
Sent: Mittwoch, 24. August 2011 13:33
To: dev@httpd.apache.org
Subject: Mitigation Range header (Was: DoS with mod_deflate
range requests)
Folks,
This issue is now active in the wild. So some unified/simple
comms is needed.
What is the wisdom on mitigation advise/briefing until a
proper fix it out - in order of ease:
-Where possible - disable mod_deflate
= we sure this covers all cases - or this is a good stopgap ?
As said this has *nothing* to do with mod_deflate. This was IMHO just
a guess by the original author of the tool.
-Where possible - set LimitRequestFieldSize to a small value
- Suggesting of 128 fine ?
-Where this is not possible (e.g. long cookies, auth
headers of serious size) consider using
mod_rewrite to not accept more than a few commas
= anyone a config snipped for this ?
How about the following (untested) rewrite rule. It should only allow 5
ranges at max.
RewriteCond %{HTTP:range} ^bytes=[^,]+(,[^,]+){0,4}$
RewriteRule .* - [F]
Regards
Rüdiger
Re: Mitigation Range header (Was: DoS with mod_deflate range requests)
On Wed, Aug 24, 2011 at 7:57 AM, Plüm, Rüdiger, VF-Group
ruediger.pl...@vodafone.com wrote:
-Original Message-
From: Dirk-Willem van Gulik
Sent: Mittwoch, 24. August 2011 13:33
To: dev@httpd.apache.org
Subject: Mitigation Range header (Was: DoS with mod_deflate
range requests)
Folks,
This issue is now active in the wild. So some unified/simple
comms is needed.
What is the wisdom on mitigation advise/briefing until a
proper fix it out - in order of ease:
- Where possible - disable mod_deflate
= we sure this covers all cases - or this is a good stopgap ?
As said this has *nothing* to do with mod_deflate. This was IMHO just
a guess by the original author of the tool.
- Where possible - set LimitRequestFieldSize to a small value
- Suggesting of 128 fine ?
- Where this is not possible (e.g. long cookies, auth
headers of serious size) consider using
mod_rewrite to not accept more than a few commas
= anyone a config snipped for this ?
How about the following (untested) rewrite rule. It should only allow 5
ranges at max.
RewriteCond %{HTTP:range} ^bytes=[^,]+(,[^,]+){0,4}$
RewriteRule .* - [F]
Is [E=no-gzip] enough to avoid the downward spiral, for the sake of
false positives?
But your regex matches when there's just a couple of ranges -- maybe
{4} and no $?
CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 (DRAFT)dev
Comments please. Esp. on the quality and realisticness of the mitigtions. Title: CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 Date: 20110824 1600Z # Last Updated: 20110824 1600Z Product: Apache Web Server Versions: Apache 1.3 all versions, Apache 2 all versions Description: A denial of service vulnerability has been found in the way the multiple overlapping ranges are handled by apache (http://seclists.org/fulldisclosure/2011/Aug/175). It most commonly manifests itself when static content is made available with compression on the fly through mod_deflate. This is a very common (the default right!?) configuration. The attack can be done remotely and with a modest number of requests leads to very significant memory and CPU usage. Active use of this tools has been observed in the wild. There is currently no patch/new version of apache which fixes this vulnerability. This advisory will be updated when a long term fix is available. A fix is expected in the next 96 hours. Mitigation: However are several immediate options to mitigate this issue until that time: 1) Disable compression-on-the-fly by: 1) removing mod_deflate as a loaded module and/or by removing any AddOutputFilterByType/SetOutputFilter DEFLATE entries. 2) Disable it with BrowserMatch .* no-gzip See:http://httpd.apache.org/docs/2.0/mod/mod_deflate.html http://httpd.apache.org/docs/2.2/mod/mod_deflate.html 2) Use mod_headers to dis-allow the use of Range headers: RequestHeader unset Range Note that this may break certain clients - such as those used for e-Readers and progressive/http-streaming video. 2) Limit the size of the request field to a few hundred bytes. Note that while this keeps the offending Range header short - it may break other headers; such as sizable cookies or security fields. LimitRequestFieldSize 200 Note that as the attack evolves in the field you are likely to have to further limit this and/or impose other LimitRequestFields limits. See: http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize 3) Deploy a Range header count module as a temporary stopgap measure: http://people.apache.org/~dirkx/mod_rangecnt.c 4) Apply any of the current patches under discussion - such as: http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3ccaapsnn2po-d-c4nqt_tes2rrwizr7urefhtkpwbc1b+k1dq...@mail.gmail.com%3e Actions: Apache HTTPD users are advised to investigate wether they are vulnerable (e.g. allow Range headers and use mod_deflate) and consider implementing any of the above mitigations. Planning: This advisory will be updated when a fix/patch or new release is available. A patch or new apache release for Apache 2.0 and 2.2 is expected in the next 96 hours. Note that, while popular, Apache 1.3 is deprecated.
Re: Mitigation Range header (Was: DoS with mod_deflate range requests)
On 24 Aug 2011, at 12:57, Plüm, Rüdiger, VF-Group wrote:
- Where possible - disable mod_deflate
= we sure this covers all cases - or this is a good stopgap ?
As said this has *nothing* to do with mod_deflate. This was IMHO just
a guess by the original author of the tool.
Ok - but when I try it on my servers (with the check of the tool removed) - it
seems quite impotent unless mod_deflate is in the wire.
And it seems a bit more potent when there is other 'keep in the air' modules
around.
So I guess mod_deflate is right now the largest 'plug' we have in the server
which can cause this backup ?
Or is that totally wrong. Happy to stand correctede !
- Where possible - set LimitRequestFieldSize to a small value
- Suggesting of 128 fine ?
- Where this is not possible (e.g. long cookies, auth
headers of serious size) consider using
mod_rewrite to not accept more than a few commas
= anyone a config snipped for this ?
How about the following (untested) rewrite rule. It should only allow 5
ranges at max.
RewriteCond %{HTTP:range} ^bytes=[^,]+(,[^,]+){0,4}$
RewriteRule .* - [F]
Sounds like a plan ! This mail crossed one I just sent out - lemme update that
too.
Dw.
Re: CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 (DRAFT-2)
* Updated with Rudigers comments.
* Do we have consensus that the deflate stuff needs to go out - is not
relevant ?
* More Comments please. Esp. on the quality and realisticness of the
mitigtions.
Thanks,
Title: CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and
Apache 2
Date: 20110824 1600Z
# Last Updated: 20110824 1600Z
Product: Apache Web Server
Versions: Apache 1.3 all versions, Apache 2 all versions
Description:
A denial of service vulnerability has been found in the way the multiple
overlapping ranges are handled by apache
(http://seclists.org/fulldisclosure/2011/Aug/175). It most commonly manifests
itself when static content is made available with compression on the fly
through mod_deflate - but other modules which buffer and/or generate content
in-memory are likely to be affected as well.
This is a very common (the default right!?) configuration.
The attack can be done remotely and with a modest number of requests leads to
very significant memory and CPU usage.
Active use of this tools has been observed in the wild.
There is currently no patch/new version of apache which fixes this
vulnerability. This advisory will be updated when a long term fix is available.
A fix is expected in the next 96 hours.
Mitigation:
However are several immediate options to mitigate this issue until that time:
1) Use mod_headers to dis-allow the use of Range headers:
RequestHeader unset Range
Note that this may break certain clients - such as those used for
e-Readers and progressive/http-streaming video.
2) Use mod_rewrite to limit the number of ranges:
RewriteCond %{HTTP:range} ^bytes=[^,]+(,[^,]+){0,4}$
RewriteRule .* - [F]
3) Limit the size of the request field to a few hundred bytes. Note that
while this
keeps the offending Range header short - it may break other headers;
such as sizable
cookies or security fields.
LimitRequestFieldSize 200
Note that as the attack evolves in the field you are likely to have
to further limit this and/or impose other LimitRequestFields limits.
See:
http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize
3) Deploy a Range header count module as a temporary stopgap measure:
http://people.apache.org/~dirkx/mod_rangecnt.c
4) If your server (only) server static content then disable
compression-on-the-fly by:
1) removing mod_deflate as a loaded module and/or by removing any
AddOutputFilterByType/SetOutputFilter DEFLATE entries.
2) Disable it with BrowserMatch .* no-gzip
See:http://httpd.apache.org/docs/2.0/mod/mod_deflate.html
http://httpd.apache.org/docs/2.2/mod/mod_deflate.html
5) Apply any of the current patches under discussion - such as:
http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3ccaapsnn2po-d-c4nqt_tes2rrwizr7urefhtkpwbc1b+k1dq...@mail.gmail.com%3e
Actions:
Apache HTTPD users are advised to investigate wether they are vulnerable (e.g.
allow Range headers and use mod_deflate) and consider implementing any of the
above mitigations.
Planning:
This advisory will be updated when a fix/patch or new release is available. A
patch or new apache release for Apache 2.0 and 2.2 is expected in the next 96
hours. Note that, while popular, Apache 1.3 is deprecated.
Re: Mitigation Range header
* Plüm, Rüdiger, VF-Group: As said this has *nothing* to do with mod_deflate. This was IMHO just a guess by the original author of the tool. This matches my testing, too. I see a significant peak in RAM usage on a server where apachectl -M does not print anything with the string deflate (so I assume that mod_deflate is not enabled). This is with 2.2.9-10+lenny9 on Debian. If it is more difficult to check if mod_deflate is enabled, the advisory should tell how to check your server. If the method I used is the correct one, I don't think it's reasonable to suggest disabling mod_deflate as a mitigation because it does not seem to make much of a difference. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
RE: Mitigation Range header (Was: DoS with mod_deflate range requests)
-Original Message-
From: Eric Covener [mailto:cove...@gmail.com]
Sent: Mittwoch, 24. August 2011 14:05
To: dev@httpd.apache.org
Subject: Re: Mitigation Range header (Was: DoS with
mod_deflate range requests)
On Wed, Aug 24, 2011 at 7:57 AM, Plüm, Rüdiger, VF-Group
ruediger.pl...@vodafone.com wrote:
-Original Message-
From: Dirk-Willem van Gulik
Sent: Mittwoch, 24. August 2011 13:33
To: dev@httpd.apache.org
Subject: Mitigation Range header (Was: DoS with mod_deflate
range requests)
Folks,
This issue is now active in the wild. So some unified/simple
comms is needed.
What is the wisdom on mitigation advise/briefing until a
proper fix it out - in order of ease:
- Where possible - disable mod_deflate
= we sure this covers all cases - or this is a good
stopgap ?
As said this has *nothing* to do with mod_deflate. This was
IMHO just
a guess by the original author of the tool.
- Where possible - set LimitRequestFieldSize to a small value
- Suggesting of 128 fine ?
- Where this is not possible (e.g. long cookies, auth
headers of serious size) consider using
mod_rewrite to not accept more than a few commas
= anyone a config snipped for this ?
How about the following (untested) rewrite rule. It should
only allow 5
ranges at max.
RewriteCond %{HTTP:range} ^bytes=[^,]+(,[^,]+){0,4}$
RewriteRule .* - [F]
Is [E=no-gzip] enough to avoid the downward spiral, for the sake of
false positives?
As said it has IMHO nothing to do with mod_deflate. It is an issue of the byte
range filter.
But your regex matches when there's just a couple of ranges -- maybe
{4} and no $?
Of course it should have been:
RewriteCond %{HTTP:range} !^bytes=[^,]+(,[^,]+){0,4}$
RewriteRule .* - [F]
As said untested. Thanks for remote eyes.
Regards
Rüdiger
Re: Mitigation Range header
On 24 Aug 2011, at 13:22, Florian Weimer wrote: * Plüm, Rüdiger, VF-Group: As said this has *nothing* to do with mod_deflate. This was IMHO just a guess by the original author of the tool. This matches my testing, too. I see a significant peak in RAM usage on a server where apachectl -M does not print anything with the string deflate (so I assume that mod_deflate is not enabled). This is with 2.2.9-10+lenny9 on Debian. If it is more difficult to check if mod_deflate is enabled, the advisory should tell how to check your server. If the method I used is the correct one, I don't think it's reasonable to suggest disabling mod_deflate as a mitigation because it does not seem to make much of a difference. Hmm - when I remove mod_deflate (i.e. explicitly as it is the default in all our installs) and test on a / entry which is a static file which is large (100k)* - then I cannot get apache on its knees on a freebsd machine - saturating the 1Gbit connection it has (Note: the attack machines *are* getting saturated). The moment i put in mod_deflate, mod_external filter, etc - it is much easier to get deplete enough resources to notice. Dw. *: as I cannot reproduce the issue with very small index.html files.
Re: Mitigation Range header
* Dirk-WIllem van Gulik: Hmm - when I remove mod_deflate (i.e. explicitly as it is the default in all our installs) and test on a / entry which is a static file which is large (100k)* - then I cannot get apache on its knees on a freebsd machine - saturating the 1Gbit connection it has (Note: the attack machines *are* getting saturated). The moment i put in mod_deflate, mod_external filter, etc - it is much easier to get deplete enough resources to notice. Oh. Have you checked memory usage on the server? -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
RE: Mitigation Range header (Was: DoS with mod_deflate range requests)
-Original Message-
From: Dirk-Willem van Gulik [mailto:di...@webweaving.org]
Sent: Mittwoch, 24. August 2011 14:14
To: dev@httpd.apache.org
Subject: Re: Mitigation Range header (Was: DoS with
mod_deflate range requests)
On 24 Aug 2011, at 12:57, Plüm, Rüdiger, VF-Group wrote:
- Where possible - disable mod_deflate
= we sure this covers all cases - or this is a good stopgap ?
As said this has *nothing* to do with mod_deflate. This was
IMHO just
a guess by the original author of the tool.
Ok - but when I try it on my servers (with the check of the
tool removed) - it seems quite impotent unless mod_deflate
is in the wire.
Hm, weird. I would guess that mod_deflate could even mitigate this attack as
the byterange
filter only does something if it sees the whole response in the brigade the
first time it
is called. Having mod_deflate compressing larger chunks of data causes the
byterange filter
to be called multiple times with only parts of the response in the brigade.
So the byte range filter should only be applied with responses whose compressed
response
fits into the zlibs output filter.
Depending on the size of the input and the number of parallel requests it might
be possible
that a lot of memory is consumed by mod_deflate anyway. But I would expect the
same behviour
without range requests as well.
And it seems a bit more potent when there is other 'keep in
the air' modules around.
So I guess mod_deflate is right now the largest 'plug' we
have in the server which can cause this backup ?
Or is that totally wrong. Happy to stand correctede !
- Where possible - set LimitRequestFieldSize to a small value
- Suggesting of 128 fine ?
- Where this is not possible (e.g. long cookies, auth
headers of serious size) consider using
mod_rewrite to not accept more than a few commas
= anyone a config snipped for this ?
How about the following (untested) rewrite rule. It should
only allow 5
ranges at max.
RewriteCond %{HTTP:range} ^bytes=[^,]+(,[^,]+){0,4}$
RewriteRule .* - [F]
Sounds like a plan ! This mail crossed one I just sent out -
lemme update that too.
Please see my response to Eric. He detected an error in the above.
Regards
Rüdiger
Re: Mitigation Range header (Was: DoS with mod_deflate range requests)
Of course it should have been:
RewriteCond %{HTTP:range} !^bytes=[^,]+(,[^,]+){0,4}$
RewriteRule .* - [F]
The problem with the negation is you need an addl rule to handle an
empty range header, this would forbid normal non-range requests.
--
Eric Covener
cove...@gmail.com
Re: Mitigation Range header
On 24 Aug 2011, at 13:43, Florian Weimer wrote: * Dirk-WIllem van Gulik: Hmm - when I remove mod_deflate (i.e. explicitly as it is the default in all our installs) and test on a / entry which is a static file which is large (100k)* - then I cannot get apache on its knees on a freebsd machine - saturating the 1Gbit connection it has (Note: the attack machines *are* getting saturated). The moment i put in mod_deflate, mod_external filter, etc - it is much easier to get deplete enough resources to notice. Oh. Have you checked memory usage on the server? I had not - and you are right - quite high. I also tried it on a Ubuntu machine - and that one dies right out of the gate - regardless as to wether deflate is on- or off. So I guess this is somewhat OS specific - but indeed - not overly deflate specific. Deflate just does something. Ok - let me rewrite advisory draft ! Dw
RE: Mitigation Range header
-Original Message- From: Dirk-WIllem van Gulik [mailto:di...@webweaving.org] Sent: Mittwoch, 24. August 2011 14:40 To: dev@httpd.apache.org Cc: Plüm, Rüdiger, VF-Group Subject: Re: Mitigation Range header On 24 Aug 2011, at 13:22, Florian Weimer wrote: * Plüm, Rüdiger, VF-Group: As said this has *nothing* to do with mod_deflate. This was IMHO just a guess by the original author of the tool. This matches my testing, too. I see a significant peak in RAM usage on a server where apachectl -M does not print anything with the string deflate (so I assume that mod_deflate is not enabled). This is with 2.2.9-10+lenny9 on Debian. If it is more difficult to check if mod_deflate is enabled, the advisory should tell how to check your server. If the method I used is the correct one, I don't think it's reasonable to suggest disabling mod_deflate as a mitigation because it does not seem to make much of a difference. Hmm - when I remove mod_deflate (i.e. explicitly as it is the default in all our installs) and test on a / entry which is a static file which is large (100k)* - then I cannot get apache on its knees on a freebsd machine - saturating the 1Gbit connection it has (Note: the attack machines *are* getting saturated). The moment i put in mod_deflate, mod_external filter, etc - it is much easier to get deplete enough resources to notice. Dw. *: as I cannot reproduce the issue with very small index.html files. Have you tried if the same happens with mod_deflate, but with one of the the proposed mitigations in place? As said my guess is that this might be an issue with mod_deflate that is unrelated to the Range request issue. Regards Rüdiger
Re: CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 (DRAFT-3)
* Folks - do we also need to add Request-Range ?
* Updated with Rudigers comments., Eric, Florians
* Consensus that the deflate stuff needs to go out reflected.
* More Comments please. Esp. on the quality and realisticness of the
mitigtions.
* Is this the right list (and order) of the mitigations - or should
ReWrite be first ?
* Timeline mentioning fine (we've never done that before) -- or best
avoided ?
My plan is to wait for the US to fully wake up - and then call for a few quick
+1's to get this out - ideally before 1600 zulu.
Thanks,
Dw.
Title: CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and
Apache 2
Date: 20110824 1600Z
# Last Updated: 20110824 1600Z
Product: Apache Web Server
Versions: Apache 1.3 all versions, Apache 2 all versions
Description:
A denial of service vulnerability has been found in the way the multiple
overlapping ranges are handled by apache
(http://seclists.org/fulldisclosure/2011/Aug/175). An attack tool is
circulating in the wild. Active use of this tools has been observed.
The attack can be done remotely and with a modest number of requests leads to
very significant memory and CPU usage.
The default apache installation is vulnerable.
There is currently no patch/new version of apache which fixes this
vulnerability. This advisory will be updated when a long term fix is available.
A fix is expected in the next 96 hours.
Mitigation:
However are several immediate options to mitigate this issue until that time:
1) Use mod_headers to dis-allow the use of Range headers:
RequestHeader unset Range
Note that this may break certain clients - such as those used for
e-Readers and progressive/http-streaming video.
2) Use mod_rewrite to limit the number of ranges:
RewriteCond %{HTTP:range} !^bytes=[^,]+(,[^,]+){0,4}$
RewriteRule .* - [F]
3) Limit the size of the request field to a few hundred bytes. Note that
while this
keeps the offending Range header short - it may break other headers;
such as sizable
cookies or security fields.
LimitRequestFieldSize 200
Note that as the attack evolves in the field you are likely to have
to further limit this and/or impose other LimitRequestFields limits.
See:
http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize
3) Deploy a Range header count module as a temporary stopgap measure:
http://people.apache.org/~dirkx/mod_rangecnt.c
5) Apply any of the current patches under discussion - such as:
http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3ccaapsnn2po-d-c4nqt_tes2rrwizr7urefhtkpwbc1b+k1dq...@mail.gmail.com%3e
Actions:
---
Apache HTTPD users are advised to investigate wether they are vulnerable (e.g.
allow use of the Range header )and consider implementing any of the above
mitigations immediately.
When using a third party attack tool to verify vulnerability - know that most
of the versions in the wild currently check for the presence of mod_deflate;
and will (mis)report that your server is not vulnerable if this module is not
present. This vulnerability is not dependent on presence or absence of that
module.
Planning:
-
This advisory will be updated when a fix/patch or new release is available. A
patch or new apache release for Apache 2.0 and 2.2 is expected in the next 96
hours. Note that, while popular, Apache 1.3 is deprecated.
Re: Mitigation Range header
* Dirk-WIllem van Gulik: On 24 Aug 2011, at 13:43, Florian Weimer wrote: * Dirk-WIllem van Gulik: Hmm - when I remove mod_deflate (i.e. explicitly as it is the default in all our installs) and test on a / entry which is a static file which is large (100k)* - then I cannot get apache on its knees on a freebsd machine - saturating the 1Gbit connection it has (Note: the attack machines *are* getting saturated). The moment i put in mod_deflate, mod_external filter, etc - it is much easier to get deplete enough resources to notice. Oh. Have you checked memory usage on the server? I had not - and you are right - quite high. I also tried it on a Ubuntu machine - and that one dies right out of the gate - regardless as to wether deflate is on- or off. It seems that this reflects different approaches to memory overcommitment. I didn't see any crashes with vm.overcommit_memory=2 on Linux, either. I wouldn't mention this in the advisory, though, because even if no critical process is terminated due to the out-of-memory condition, thrashing could still push the system beyond the point of recovery. Including the increased memory usage in the adviosry, as a potential attack indicator, would make sense, IMHO. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Re: Mitigation Range header
On 24 Aug 2011, at 14:01, Plüm, Rüdiger, VF-Group wrote: Have you tried if the same happens with mod_deflate, but with one of the the proposed mitigations in place? As soon as I reject/block on the range header - all is fine again. As said my guess is that this might be an issue with mod_deflate that is unrelated to the Range request issue. Good point. Dw
Re: CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 (DRAFT-3)
* Is this the right list (and order) of the mitigations - or should ReWrite be first ? FWIW I don't like rewrite first because it's so unruly with being defined once per vhost + main server + RewriteEngine on. I like RequestHeader simplicity, and could be combined with SetEnvIf to only zap long malicious looking headers.
Re: CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 (NEAR FINAL DRAFT-4)
On 24 Aug 2011, at 14:07, Dirk-WIllem van Gulik wrote:
* Folks - do we also need to add Request-Range ?
* Updated with Rudigers comments., Eric, Florians, Marks.
* Consensus that the deflate stuff needs to go out reflected.
* More Comments please. Esp. on the quality and realisticness of the
mitigtions.
* Timeline mentioning fine (we've never done that before) -- or best
avoided ?
My plan is to wait for the US to fully wake up - and then call around 1500Z for
a few quick +1's to get this out - ideally before 1600 zulu.
Thanks,
Dw.
Title: CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and
Apache 2
Date: 20110824 1600Z
# Last Updated: 20110824 1600Z
Product: Apache Web Server
Versions: Apache 1.3 all versions, Apache 2 all versions
Description:
A denial of service vulnerability has been found in the way the multiple
overlapping ranges are handled by the Apache HTTPD server
(http://seclists.org/fulldisclosure/2011/Aug/175).
An attack tool is circulating in the wild. Active use of this tools has been
observed.
The attack can be done remotely and with a modest number of requests leads to
very significant memory and CPU usage.
The default Apache HTTPD installation is vulnerable.
There is currently no patch/new version of Apache HTTPD which fixes this
vulnerability. This advisory will be updated when a long term fix is available.
A full fix is expected in the next 48 hours.
Mitigation:
However there are several immediate options to mitigate this issue until that
time:
1) Use mod_headers to dis-allow the use of Range headers:
RequestHeader unset Range
Note that this may break certain clients - such as those used for
e-Readers and progressive/http-streaming video.
2) Use mod_rewrite to limit the number of ranges:
RewriteCond %{HTTP:range} !^bytes=[^,]+(,[^,]+){0,4}$
RewriteRule .* - [F]
3) Limit the size of the request field to a few hundred bytes. Note that
while this
keeps the offending Range header short - it may break other headers;
such as sizable
cookies or security fields.
LimitRequestFieldSize 200
Note that as the attack evolves in the field you are likely to have
to further limit this and/or impose other LimitRequestFields limits.
See:
http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize
4) Deploy a Range header count module as a temporary stopgap measure:
http://people.apache.org/~dirkx/mod_rangecnt.c
5) Apply any of the current patches under discussion - such as:
http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3ccaapsnn2po-d-c4nqt_tes2rrwizr7urefhtkpwbc1b+k1dq...@mail.gmail.com%3e
Actions:
---
Apache HTTPD users who are concerned about a DoS attack against their server
should consider implementing any of the above mitigations immediately.
When using a third party attack tool to verify vulnerability - know that most
of the versions in the wild currently check for the presence of mod_deflate;
and will (mis)report that your server is not vulnerable if this module is not
present. This vulnerability is not dependent on presence or absence of that
module.
Planning:
-
This advisory will be updated when a fix/patch or new release is available. A
patch or new apache release for Apache 2.0 and 2.2 is expected in the next 48
hours. Note that, while popular, Apache 1.3 is deprecated.
Re: CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 (DRAFT-3)
On Wed, Aug 24, 2011 at 9:17 AM, Eric Covener cove...@gmail.com wrote:
* Is this the right list (and order) of the mitigations - or should
ReWrite be first ?
FWIW I don't like rewrite first because it's so unruly with being
defined once per vhost + main server + RewriteEngine on.
I like RequestHeader simplicity, and could be combined with SetEnvIf
to only zap long malicious looking headers.
e.g.
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
CustomLog logs/range.log %r %{Range}i %{bad-range}e
printf GET / HTTP/1.1\r\nHost:
localhost\r\nRange:bytes=0-1,2-3,4-5,5-6,7-9,10-12,11-99,44\r\n\r\n |
nc localhost 80
GET / HTTP/1.1 - 1
printf GET / HTTP/1.1\r\nHost:
localhost\r\nRange:bytes=0-1,2-3,4-5\r\n\r\n | nc localhost 80
GET / HTTP/1.1 bytes=0-1,2-3,4-5 -
--
Eric Covener
cove...@gmail.com
Re: CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 (DRAFT-3)
On Wed, Aug 24, 2011 at 9:29 AM, Eric Covener cove...@gmail.com wrote:
On Wed, Aug 24, 2011 at 9:17 AM, Eric Covener cove...@gmail.com wrote:
* Is this the right list (and order) of the mitigations - or should
ReWrite be first ?
FWIW I don't like rewrite first because it's so unruly with being
defined once per vhost + main server + RewriteEngine on.
I like RequestHeader simplicity, and could be combined with SetEnvIf
to only zap long malicious looking headers.
e.g.
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
CustomLog logs/range.log %r %{Range}i %{bad-range}e
printf GET / HTTP/1.1\r\nHost:
localhost\r\nRange:bytes=0-1,2-3,4-5,5-6,7-9,10-12,11-99,44\r\n\r\n |
nc localhost 80
GET / HTTP/1.1 - 1
printf GET / HTTP/1.1\r\nHost:
localhost\r\nRange:bytes=0-1,2-3,4-5\r\n\r\n | nc localhost 80
GET / HTTP/1.1 bytes=0-1,2-3,4-5 -
Or more like Ruedigers:
SetEnvIf Range (,[^,]*){5,} bad-range=1
Re: Mitigation Range header
On Wed, Aug 24, 2011 at 9:01 AM, Plüm, Rüdiger, VF-Group ruediger.pl...@vodafone.com wrote: Hmm - when I remove mod_deflate (i.e. explicitly as it is the default in all our installs) and test on a / entry which is a static file which is large (100k)* - then I cannot get apache on its knees on a freebsd machine - saturating the 1Gbit connection it has (Note: the attack machines *are* getting saturated). The moment i put in mod_deflate, mod_external filter, etc - it is much easier to get deplete enough resources to notice. Dw. *: as I cannot reproduce the issue with very small index.html files. Have you tried if the same happens with mod_deflate, but with one of the the proposed mitigations in place? As said my guess is that this might be an issue with mod_deflate that is unrelated to the Range request issue. I think mod_deflate is just the tool to convert an O(N^2) data size problem into an O(N^2) CPU usage problem, where N is some function of LimitRequestLine. If the file size is smaller than the largest range end used in the attack, it may reduce the amount of data actually going down the filter chain. Greg
RE: Mitigation Range header (Was: DoS with mod_deflate range requests)
-Original Message-
From: Eric Covener [mailto:cove...@gmail.com]
Sent: Mittwoch, 24. August 2011 14:59
To: dev@httpd.apache.org
Subject: Re: Mitigation Range header (Was: DoS with
mod_deflate range requests)
Of course it should have been:
RewriteCond %{HTTP:range} !^bytes=[^,]+(,[^,]+){0,4}$
RewriteRule .* - [F]
The problem with the negation is you need an addl rule to handle an
empty range header, this would forbid normal non-range requests.
Damn it. Got me again. How about this:
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
RewriteRule .* - [F]
Regards
Rüdiger
RE: CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 (DRAFT-3)
Reverse the order a litte bit:
2) , 3), 1) (as 1) is likely to break the most things compared to 2) and 3))
Regarding 2) see the ongoing discussion between Eric and me to find the correct
expression.
Regards
Rüdiger
-Original Message-
From: Dirk-WIllem van Gulik
Sent: Mittwoch, 24. August 2011 15:08
To: Dirk-Willem van Gulik
Cc: dev@httpd.apache.org; secur...@httpd.apache.org
Subject: Re: CVE-2011-3192: Range header DoS vulnerability in
Apache 1.3 and Apache 2 (DRAFT-3)
* Folks - do we also need to add Request-Range ?
* Updated with Rudigers comments., Eric, Florians
* Consensus that the deflate stuff needs to go out reflected.
* More Comments please. Esp. on the quality and
realisticness of the mitigtions.
* Is this the right list (and order) of the mitigations -
or should ReWrite be first ?
* Timeline mentioning fine (we've never done that before)
-- or best avoided ?
My plan is to wait for the US to fully wake up - and then
call for a few quick +1's to get this out - ideally before 1600 zulu.
Thanks,
Dw.
Title:CVE-2011-3192: Range header DoS
vulnerability in Apache 1.3 and Apache 2
Date: 20110824 1600Z
# Last Updated: 20110824 1600Z
Product: Apache Web Server
Versions: Apache 1.3 all versions, Apache 2 all versions
Description:
A denial of service vulnerability has been found in the way
the multiple overlapping ranges are handled by apache
(http://seclists.org/fulldisclosure/2011/Aug/175). An attack
tool is circulating in the wild. Active use of this tools has
been observed.
The attack can be done remotely and with a modest number of
requests leads to very significant memory and CPU usage.
The default apache installation is vulnerable.
There is currently no patch/new version of apache which fixes
this vulnerability. This advisory will be updated when a long
term fix is available. A fix is expected in the next 96 hours.
Mitigation:
However are several immediate options to mitigate this issue
until that time:
1)Use mod_headers to dis-allow the use of Range headers:
RequestHeader unset Range
Note that this may break certain clients - such as
those used for
e-Readers and progressive/http-streaming video.
2)Use mod_rewrite to limit the number of ranges:
RewriteCond %{HTTP:range} !^bytes=[^,]+(,[^,]+){0,4}$
RewriteRule .* - [F]
3)Limit the size of the request field to a few hundred
bytes. Note that while this
keeps the offending Range header short - it may break
other headers; such as sizable
cookies or security fields.
LimitRequestFieldSize 200
Note that as the attack evolves in the field you are
likely to have
to further limit this and/or impose other
LimitRequestFields limits.
See:
http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize
3)Deploy a Range header count module as a temporary
stopgap measure:
http://people.apache.org/~dirkx/mod_rangecnt.c
5)Apply any of the current patches under discussion - such as:
http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox
/%3cCAAPSnn2PO-d-C4nQt_TES2RRWiZr7urefhTKPWBC1b+K1Dqc7g@mail.g
mail.com%3e
Actions:
---
Apache HTTPD users are advised to investigate wether they are
vulnerable (e.g. allow use of the Range header )and consider
implementing any of the above mitigations immediately.
When using a third party attack tool to verify vulnerability
- know that most of the versions in the wild currently check
for the presence of mod_deflate; and will (mis)report that
your server is not vulnerable if this module is not present.
This vulnerability is not dependent on presence or absence of
that module.
Planning:
-
This advisory will be updated when a fix/patch or new release
is available. A patch or new apache release for Apache 2.0
and 2.2 is expected in the next 96 hours. Note that, while
popular, Apache 1.3 is deprecated.
RE: CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 (DRAFT-3)
-Original Message-
From: Eric Covener [mailto:cove...@gmail.com]
Sent: Mittwoch, 24. August 2011 15:29
To: dev@httpd.apache.org
Subject: Re: CVE-2011-3192: Range header DoS vulnerability in
Apache 1.3 and Apache 2 (DRAFT-3)
On Wed, Aug 24, 2011 at 9:17 AM, Eric Covener
cove...@gmail.com wrote:
* Is this the right list (and order) of the
mitigations - or should ReWrite be first ?
FWIW I don't like rewrite first because it's so unruly with being
defined once per vhost + main server + RewriteEngine on.
I like RequestHeader simplicity, and could be combined with SetEnvIf
to only zap long malicious looking headers.
e.g.
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
Nice one as well. Might be even better then the rewrite rule.
Regards
Rüdiger
RE: Mitigation Range header
From: Greg Ames Sent: Mittwoch, 24. August 2011 16:05 To: dev@httpd.apache.org Subject: Re: Mitigation Range header On Wed, Aug 24, 2011 at 9:01 AM, Plüm, Rüdiger, VF-Group ruediger.pl...@vodafone.com wrote: Hmm - when I remove mod_deflate (i.e. explicitly as it is the default in all our installs) and test on a / entry which is a static file which is large (100k)* - then I cannot get apache on its knees on a freebsd machine - saturating the 1Gbit connection it has (Note: the attack machines *are* getting saturated). The moment i put in mod_deflate, mod_external filter, etc - it is much easier to get deplete enough resources to notice. Dw. *: as I cannot reproduce the issue with very small index.html files. Have you tried if the same happens with mod_deflate, but with one of the the proposed mitigations in place? As said my guess is that this might be an issue with mod_deflate that is unrelated to the Range request issue. I think mod_deflate is just the tool to convert an O(N^2) data size problem into an O(N^2) CPU usage problem, where N is some function of LimitRequestLine. If the file size is smaller than the largest range end used in the attack, it may reduce the amount of data actually going down the filter chain. Greg I don't think so. The compression happens before the byterange filter and the byterange filter just hacks the already compressed brigade into more buckets and rearranges them. mod_deflate does not do more work if it is a range request. It does the same amount of work as for the non range request. Regards Rüdiger
Re: CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 (NEAR FINAL DRAFT-4)
Dirk, Am 24.08.2011 15:23, schrieb Dirk-WIllem van Gulik: 4) Deploy a Range header count module as a temporary stopgap measure: http://people.apache.org/~dirkx/mod_rangecnt.c can you please apply: --- mod_rangecnt.c.orig Wed Aug 24 16:25:34 2011 +++ mod_rangecnt.c Wed Aug 24 15:26:48 2011 @@ -22,6 +22,7 @@ #include httpd.h #include http_config.h #include http_log.h +#include http_protocol.h #ifndef MAXRANGEHEADERS #define MAXRANGEHEADERS (5) which I need on NetWare in order to get ap_hook_post_read_request() proto; and maybe we should also add links to mod_rangecnt binaries? for Netware: http://people.apache.org/~fuankg/httpd/apache_2.2.x-mod_rangecnt.zip http://people.apache.org/~fuankg/httpd/apache_2.0.x-mod_rangecnt.zip Gregg, are you up to provide Win32 binaries too? Gün.
VOTES please -- CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 (Final-5)
Folks,
Can I have a few +1's on below - or feedback on what we'd like to have changed ?
* Would like to get this out in an hour or so ?
* FIne with the 48 hours commitment of an update ?
Dw.
Title:CVE-2011-3192: Range header DoS vulnerability Apache HTTPD 1.3/2.x
Date: 20110824 1600Z
Product: Apache HTTPD Web Server
Versions: Apache 1.3 all versions, Apache 2 all versions
Description:
A denial of service vulnerability has been found in the way the multiple
overlapping ranges are handled by the Apache HTTPD server:
http://seclists.org/fulldisclosure/2011/Aug/175
An attack tool is circulating in the wild. Active use of this tools has been
observed.
The attack can be done remotely and with a modest number of requests can cause
very significant memory and CPU usage on the server.
The default Apache HTTPD installation is vulnerable.
There is currently no patch/new version of Apache HTTPD which fixes this
vulnerability. This advisory will be updated when a long term fix is available.
A full fix is expected in the next 48 hours.
Mitigation:
However there are several immediate options to mitigate this issue until that
time:
1) Use mod_rewrite to limit the number of ranges:
Option 1L
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
RewriteRule .* - [F]
Option 2:
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
# optional logging.
CustomLog logs/range.log %r %{Range}i %{bad-range}e
2) Limit the size of the request field to a few hundred bytes. Note that while
this
keeps the offending Range header short - it may break other headers; such as
sizeable cookies or security fields.
LimitRequestFieldSize 200
Note that as the attack evolves in the field you are likely to have
to further limit this and/or impose other LimitRequestFields limits.
See:
http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize
3) Use mod_headers to dis-allow the use of Range headers:
RequestHeader unset Range
Note that this may break certain clients - such as those used for
e-Readers and progressive/http-streaming video.
4) Deploy a Range header count module as a temporary stopgap measure:
http://people.apache.org/~dirkx/mod_rangecnt.c
5) Apply any of the current patches under discussion - such as:
http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3ccaapsnn2po-d-c4nqt_tes2rrwizr7urefhtkpwbc1b+k1dq...@mail.gmail.com%3e
Actions:
---
Apache HTTPD users who are concerned about a DoS attack against their server
should consider implementing any of the above mitigations immediately.
When using a third party attack tool to verify vulnerability - know that most
of the versions in the wild currently check for the presence of mod_deflate;
and will (mis)report that your server is not vulnerable if this module is not
present. This vulnerability is not dependent on presence or absence of that
module.
Planning:
-
This advisory will be updated when a fix/patch or new release is available. A
patch or new apache release for Apache 2.0 and 2.2 is expected in the next 48
hours. Note that, while popular, Apache 1.3 is deprecated.
Re: CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 (NEAR FINAL DRAFT-4)
On 24 Aug 2011, at 15:34, Guenter Knauf wrote: can you please apply: --- mod_rangecnt.c.orig Wed Aug 24 16:25:34 2011 +++ mod_rangecnt.cWed Aug 24 15:26:48 2011 Done. which I need on NetWare in order to get ap_hook_post_read_request() proto; and maybe we should also add links to mod_rangecnt binaries? for Netware: http://people.apache.org/~fuankg/httpd/apache_2.2.x-mod_rangecnt.zip http://people.apache.org/~fuankg/httpd/apache_2.0.x-mod_rangecnt.zip Added pointers. Dw.
RE: VOTES please -- CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 (Final-5)
-Original Message-
From: Dirk-Willem van Gulik [mailto:di...@webweaving.org]
Sent: Mittwoch, 24. August 2011 16:36
To: dev@httpd.apache.org
Subject: VOTES please -- CVE-2011-3192: Range header DoS
vulnerability in Apache 1.3 and Apache 2 (Final-5)
Folks,
Can I have a few +1's on below - or feedback on what we'd
like to have changed ?
* Would like to get this out in an hour or so ?
* FIne with the 48 hours commitment of an update ?
Dw.
Title:CVE-2011-3192: Range header DoS vulnerability
Apache HTTPD 1.3/2.x
Date: 20110824 1600Z
Product: Apache HTTPD Web Server
Versions: Apache 1.3 all versions, Apache 2 all versions
Description:
A denial of service vulnerability has been found in the way
the multiple overlapping ranges are handled by the Apache
HTTPD server:
http://seclists.org/fulldisclosure/2011/Aug/175
An attack tool is circulating in the wild. Active use of this
tools has been observed.
The attack can be done remotely and with a modest number of
requests can cause very significant memory and CPU usage on
the server.
The default Apache HTTPD installation is vulnerable.
There is currently no patch/new version of Apache HTTPD which
fixes this vulnerability. This advisory will be updated when
a long term fix is available.
A full fix is expected in the next 48 hours.
Mitigation:
However there are several immediate options to mitigate this
issue until that time:
1) Use mod_rewrite to limit the number of ranges:
Option 1L
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
RewriteRule .* - [F]
Option 2:
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
# optional logging.
CustomLog logs/range.log %r %{Range}i %{bad-range}e
Shouldn't it be a conditional logging?
CustomLog logs/range.log %r %{Range}i env=bad-range
Otherwise looks good. +1.
Regards
Rüdiger
Re: VOTES please -- CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 (Final-5)
CustomLog logs/range.log %r %{Range}i env=bad-range
Actually I was only using that to show/debug the result of the
directives, did not occur that folks would also want to log these!
Of course that makes sense though.
Unfortunately we lose the range header in the log when we zap it, so
logging it is not really so useful in concert with the conditional.
so probably just wise to collect them under common logformat:
SetEnvIf Range (,[^,]*){5,} bad-range=1
RequestHeader unset Range env=bad-range
CustomLog logs/range.log common env=bad-range
--
Eric Covener
cove...@gmail.com
Re: VOTES please -- CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 (Final-6)
Various suggest on-list and off-list fixes applied. Thanks all.
A few more +1's would be nice :)
Dw.
Title:CVE-2011-3192: Range header DoS vulnerability Apache HTTPD 1.3/2.x
Apache HTTPD Security ADVISORY
Date: 20110824 1600Z
Product: Apache HTTPD Web Server
Versions: Apache 1.3 all versions, Apache 2 all versions
Description:
A denial of service vulnerability has been found in the way the multiple
overlapping ranges are handled by the Apache HTTPD server:
http://seclists.org/fulldisclosure/2011/Aug/175
An attack tool is circulating in the wild. Active use of this tools has been
observed.
The attack can be done remotely and with a modest number of requests can cause
very significant memory and CPU usage on the server.
The default Apache HTTPD installation is vulnerable.
There is currently no patch/new version of Apache HTTPD which fixes this
vulnerability. This advisory will be updated when a long term fix is available.
A full fix is expected in the next 48 hours.
Mitigation:
However there are several immediate options to mitigate this issue until that
time.
1) Use mod_rewrite to limit the number of ranges:
Option 1:
# drop Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
# optional logging.
CustomLog logs/range-CVE-2011-3192.log common env=bad-range
Option 2:
# Reject request when more than 5 ranges in the Range: header.
# CVE-2011-3192
#
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
RewriteRule .* - [F]
The number 5 is arbitrary. Several 10's should not be an issue and may be
required for sites which for example serve PDFs to very high end eReaders
or use things such complex http based video streaming.
2) Limit the size of the request field to a few hundred bytes. Note that while
this
keeps the offending Range header short - it may break other headers; such as
sizeable cookies or security fields.
LimitRequestFieldSize 200
Note that as the attack evolves in the field you are likely to have
to further limit this and/or impose other LimitRequestFields limits.
See: http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize
3) Use mod_headers to completely dis-allow the use of Range headers:
RequestHeader unset Range
Note that this may break certain clients - such as those used for
e-Readers and progressive/http-streaming video.
4) Deploy a Range header count module as a temporary stopgap measure:
http://people.apache.org/~dirkx/mod_rangecnt.c
Precompiled binaries for some platforms are available at:
http://people.apache.org/~dirkx/BINARIES.txt
5) Apply any of the current patches under discussion - such as:
http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3ccaapsnn2po-d-c4nqt_tes2rrwizr7urefhtkpwbc1b+k1dq...@mail.gmail.com%3e
Actions:
---
Apache HTTPD users who are concerned about a DoS attack against their server
should consider implementing any of the above mitigations immediately.
When using a third party attack tool to verify vulnerability - know that most
of the versions in the wild currently check for the presence of mod_deflate;
and will (mis)report that your server is not vulnerable if this module is not
present. This vulnerability is not dependent on presence or absence of that
module.
Planning:
-
This advisory will be updated when new information, a patch or a new release is
available. A patch or new apache release for Apache 2.0 and 2.2 is expected in
the next 48 hours. Note that, while popular, Apache 1.3 is deprecated.
Re: VOTES please -- CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 (Final-6)
see inline updates
On Wed, Aug 24, 2011 at 10:56 AM, Dirk-Willem van Gulik
di...@webweaving.org wrote:
Various suggest on-list and off-list fixes applied. Thanks all.
A few more +1's would be nice :)
Dw.
Title: CVE-2011-3192: Range header DoS vulnerability Apache HTTPD 1.3/2.x
Apache HTTPD Security ADVISORY
Date: 20110824 1600Z
Product: Apache HTTPD Web Server
Versions: Apache 1.3 all versions, Apache 2 all versions
Description:
A denial of service vulnerability has been found in the way the multiple
overlapping ranges are handled by the Apache HTTPD server:
http://seclists.org/fulldisclosure/2011/Aug/175
An attack tool is circulating in the wild. Active use of this tools has been
observed.
The attack can be done remotely and with a modest number of requests can
cause very significant memory and CPU usage on the server.
The default Apache HTTPD installation is vulnerable.
There is currently no patch/new version of Apache HTTPD which fixes this
vulnerability. This advisory will be updated when a long term fix is
available.
A full fix is expected in the next 48 hours.
Mitigation:
However there are several immediate options to mitigate this issue until that
time.
1) Use mod_rewrite to limit the number of ranges:
^ clarify due to directive addition
Option 1:
# drop Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
# optional logging.
CustomLog logs/range-CVE-2011-3192.log common env=bad-range
Option 2:
# Reject request when more than 5 ranges in the Range: header.
# CVE-2011-3192. Must be added to each VirtualHost and once
# in the base configuration.
+RewriteEngine on
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
RewriteRule .* - [F]
The number 5 is arbitrary. Several 10's should not be an issue and may be
required for sites which for example serve PDFs to very high end eReaders
or use things such complex http based video streaming.
2) Limit the size of the request field to a few hundred bytes. Note that
while this
keeps the offending Range header short - it may break other headers; such as
sizeable cookies or security fields.
LimitRequestFieldSize 200
Note that as the attack evolves in the field you are likely to have
to further limit this and/or impose other LimitRequestFields limits.
See: http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize
3) Use mod_headers to completely dis-allow the use of Range headers:
RequestHeader unset Range
Note that this may break certain clients - such as those used for
e-Readers and progressive/http-streaming video.
4) Deploy a Range header count module as a temporary stopgap measure:
http://people.apache.org/~dirkx/mod_rangecnt.c
Precompiled binaries for some platforms are available at:
http://people.apache.org/~dirkx/BINARIES.txt
5) Apply any of the current patches under discussion - such as:
http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3ccaapsnn2po-d-c4nqt_tes2rrwizr7urefhtkpwbc1b+k1dq...@mail.gmail.com%3e
Actions:
---
Apache HTTPD users who are concerned about a DoS attack against their server
should consider implementing any of the above mitigations immediately.
When using a third party attack tool to verify vulnerability - know that most
of the versions in the wild currently check for the presence of mod_deflate;
and will (mis)report that your server is not vulnerable if this module is not
present. This vulnerability is not dependent on presence or absence of that
module.
Planning:
-
This advisory will be updated when new information, a patch or a new release
is available. A patch or new apache release for Apache 2.0 and 2.2 is
expected in the next 48 hours. Note that, while popular, Apache 1.3 is
deprecated.
--
Eric Covener
cove...@gmail.com
Re: CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 (DRAFT-3)
+1
On Aug 24, 2011, at 10:29 AM, Plüm, Rüdiger, VF-Group wrote:
-Original Message-
From: Eric Covener [mailto:cove...@gmail.com]
Sent: Mittwoch, 24. August 2011 15:29
To: dev@httpd.apache.org
Subject: Re: CVE-2011-3192: Range header DoS vulnerability in
Apache 1.3 and Apache 2 (DRAFT-3)
On Wed, Aug 24, 2011 at 9:17 AM, Eric Covener
cove...@gmail.com wrote:
* Is this the right list (and order) of the
mitigations - or should ReWrite be first ?
FWIW I don't like rewrite first because it's so unruly with being
defined once per vhost + main server + RewriteEngine on.
I like RequestHeader simplicity, and could be combined with SetEnvIf
to only zap long malicious looking headers.
e.g.
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
Nice one as well. Might be even better then the rewrite rule.
Regards
Rüdiger
Re: VOTES please -- CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 (Final-6)
With the current fixes, +1
On Aug 24, 2011, at 10:56 AM, Dirk-Willem van Gulik wrote:
Various suggest on-list and off-list fixes applied. Thanks all.
A few more +1's would be nice :)
Dw.
Title:CVE-2011-3192: Range header DoS vulnerability Apache HTTPD 1.3/2.x
Apache HTTPD Security ADVISORY
Date: 20110824 1600Z
Product: Apache HTTPD Web Server
Versions: Apache 1.3 all versions, Apache 2 all versions
Description:
A denial of service vulnerability has been found in the way the multiple
overlapping ranges are handled by the Apache HTTPD server:
http://seclists.org/fulldisclosure/2011/Aug/175
An attack tool is circulating in the wild. Active use of this tools has been
observed.
The attack can be done remotely and with a modest number of requests can
cause very significant memory and CPU usage on the server.
The default Apache HTTPD installation is vulnerable.
There is currently no patch/new version of Apache HTTPD which fixes this
vulnerability. This advisory will be updated when a long term fix is
available.
A full fix is expected in the next 48 hours.
Mitigation:
However there are several immediate options to mitigate this issue until that
time.
1) Use mod_rewrite to limit the number of ranges:
Option 1:
# drop Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
# optional logging.
CustomLog logs/range-CVE-2011-3192.log common env=bad-range
Option 2:
# Reject request when more than 5 ranges in the Range: header.
# CVE-2011-3192
#
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
RewriteRule .* - [F]
The number 5 is arbitrary. Several 10's should not be an issue and may be
required for sites which for example serve PDFs to very high end eReaders
or use things such complex http based video streaming.
2) Limit the size of the request field to a few hundred bytes. Note that
while this
keeps the offending Range header short - it may break other headers; such
as
sizeable cookies or security fields.
LimitRequestFieldSize 200
Note that as the attack evolves in the field you are likely to have
to further limit this and/or impose other LimitRequestFields limits.
See: http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize
3) Use mod_headers to completely dis-allow the use of Range headers:
RequestHeader unset Range
Note that this may break certain clients - such as those used for
e-Readers and progressive/http-streaming video.
4) Deploy a Range header count module as a temporary stopgap measure:
http://people.apache.org/~dirkx/mod_rangecnt.c
Precompiled binaries for some platforms are available at:
http://people.apache.org/~dirkx/BINARIES.txt
5) Apply any of the current patches under discussion - such as:
http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3ccaapsnn2po-d-c4nqt_tes2rrwizr7urefhtkpwbc1b+k1dq...@mail.gmail.com%3e
Actions:
---
Apache HTTPD users who are concerned about a DoS attack against their server
should consider implementing any of the above mitigations immediately.
When using a third party attack tool to verify vulnerability - know that most
of the versions in the wild currently check for the presence of mod_deflate;
and will (mis)report that your server is not vulnerable if this module is not
present. This vulnerability is not dependent on presence or absence of that
module.
Planning:
-
This advisory will be updated when new information, a patch or a new release
is available. A patch or new apache release for Apache 2.0 and 2.2 is
expected in the next 48 hours. Note that, while popular, Apache 1.3 is
deprecated.
Re: VOTES please -- CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 (Final-6)
On Wed, Aug 24, 2011 at 10:56 AM, Dirk-Willem van Gulik
di...@webweaving.org wrote:
+1 with Eric's edits. specifically,
1) Use mod_rewrite to limit the number of ranges:
Option 1 doesn't use mod_rewrite.
Option 1:
# drop Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
# optional logging.
CustomLog logs/range-CVE-2011-3192.log common env=bad-range
Greg
Final draft / CVE-2011-3192
Thanks for all the help. All fixes included. Below will go out to announce at
the top of the hour - unless I see a veto.
Dw.
Title:CVE-2011-3192: Range header DoS vulnerability Apache HTTPD 1.3/2.x
Apache HTTPD Security ADVISORY
Date: 20110824 1600Z
Product: Apache HTTPD Web Server
Versions: Apache 1.3 all versions, Apache 2 all versions
Description:
A denial of service vulnerability has been found in the way the multiple
overlapping ranges are handled by the Apache HTTPD server:
http://seclists.org/fulldisclosure/2011/Aug/175
An attack tool is circulating in the wild. Active use of this tools has
been observed.
The attack can be done remotely and with a modest number of requests can
cause very significant memory and CPU usage on the server.
The default Apache HTTPD installation is vulnerable.
There is currently no patch/new version of Apache HTTPD which fixes this
vulnerability. This advisory will be updated when a long term fix
is available.
A full fix is expected in the next 48 hours.
Mitigation:
However there are several immediate options to mitigate this issue until
that time.
1) Use SetEnvIf or mod_rewrite to detect a large number of ranges and then
either ignore the Range: header or reject the request.
Option 1: (Apache 2.0 and 2.2)
# drop Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
# optional logging.
CustomLog logs/range-CVE-2011-3192.log common env=bad-range
Option 2: (Also for Apache 1.3)
# Reject request when more than 5 ranges in the Range: header.
# CVE-2011-3192
#
RewriteEngine on
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
RewriteRule .* - [F]
The number 5 is arbitrary. Several 10's should not be an issue and may be
required for sites which for example serve PDFs to very high end eReaders
or use things such complex http based video streaming.
2) Limit the size of the request field to a few hundred bytes. Note that while
this keeps the offending Range header short - it may break other headers;
such as sizeable cookies or security fields.
LimitRequestFieldSize 200
Note that as the attack evolves in the field you are likely to have
to further limit this and/or impose other LimitRequestFields limits.
See: http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize
3) Use mod_headers to completely dis-allow the use of Range headers:
RequestHeader unset Range
Note that this may break certain clients - such as those used for
e-Readers and progressive/http-streaming video.
4) Deploy a Range header count module as a temporary stopgap measure:
http://people.apache.org/~dirkx/mod_rangecnt.c
Precompiled binaries for some platforms are available at:
http://people.apache.org/~dirkx/BINARIES.txt
5) Apply any of the current patches under discussion - such as:
http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3ccaapsnn2po-d-c4nqt_tes2rrwizr7urefhtkpwbc1b+k1dq...@mail.gmail.com%3e
Actions:
However there are several immediate options to mitigate this issue until
that time.
1) Use SetEnvIf or mod_rewrite to detect a large number of ranges and then
either ignore the Range: header or reject the request.
Option 1: (Apache 2.0 and 2.2)
# drop Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
# optional logging.
CustomLog logs/range-CVE-2011-3192.log common env=bad-range
Option 2: (Also for Apache 1.3)
# Reject request when more than 5 ranges in the Range: header.
# CVE-2011-3192
#
RewriteEngine on
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
RewriteRule .* - [F]
The number 5 is arbitrary. Several 10's should not be an issue and may be
required for sites which for example serve PDFs to very high end eReaders
or use things such complex http based video streaming.
2) Limit the size of the request field to a few hundred bytes. Note that while
this keeps the offending Range header short - it may break other headers;
such as sizeable cookies or security fields.
LimitRequestFieldSize 200
Note that as the attack evolves in the field you are likely to have
to further limit this and/or impose other LimitRequestFields limits.
See: http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize
3) Use mod_headers to completely dis-allow the use of Range headers:
RequestHeader unset Range
Note that this may break certain clients - such as those used for
e-Readers and progressive/http-streaming video
Re: DoS with mod_deflate range requests
On Tue, Aug 23, 2011, Roy T. Fielding wrote: And the spec says ... When a client requests multiple ranges in one request, the server SHOULD return them in the order that they appeared in the request. My suggestion is to reject any request with overlapping ranges or more than five ranges with a 416, and to send 200 for any request with 4-5 ranges. There is simply no need to support random access in HTTP. Deshpande Zeng in http://dx.doi.org/10.1145/500141.500197 describe a method for streaming JPEG 2000 documents over HTTP, using many more than 5 ranges in a single request. A client that knows about any server-side limit could make multiple requests each with a small number of ranges, but discovering that limit will add latency and take more code. Tim Bannister
Re: DoS with mod_deflate range requests
On Aug 23, 2011, at 9:34 PM, Roy T. Fielding wrote: On Aug 23, 2011, at 2:34 PM, William A. Rowe Jr. wrote: On 8/23/2011 4:00 PM, Greg Ames wrote: On Tue, Aug 23, 2011 at 3:32 PM, William A. Rowe Jr. wrote: I suggest we should be parsing and reassembling the list before we start the bucket logic. I propose we satisfy range requests in the only sensible manner, returning the ranges in sequence, yeah, overlapping ranges should be merged up front. That ought to completely fix the issue. So the only remaining question; are we free to reorder them into sequence? And the spec says ... When a client requests multiple ranges in one request, the server SHOULD return them in the order that they appeared in the request. My suggestion is to reject any request with overlapping ranges +1 or more than five ranges with a 416, and to send 200 for any request with 4-5 ranges. There is simply no need to support random access in HTTP. -0
Re: DoS with mod_deflate range requests
On 24 Aug 2011, at 16:35, Tim Bannister wrote: On Tue, Aug 23, 2011, Roy T. Fielding wrote: And the spec says ... When a client requests multiple ranges in one request, the server SHOULD return them in the order that they appeared in the request. My suggestion is to reject any request with overlapping ranges or more than five ranges with a 416, and to send 200 for any request with 4-5 ranges. There is simply no need to support random access in HTTP. Deshpande Zeng in http://dx.doi.org/10.1145/500141.500197 describe a method for streaming JPEG 2000 documents over HTTP, using many more than 5 ranges in a single request. A client that knows about any server-side limit could make multiple requests each with a small number of ranges, but discovering that limit will add latency and take more code. Agreed - I've seen many 10's of ranges in a single request for things like clever PDF pagination (or tiny TIFF quicklooks for the pages), clever http fake streaming and clever use of jumping to i-Frames. I think we just need to sit this out - and accept up to RequestFieldSize limit bytes on that line - and then do a sort merge overlaps as needed. And then it is fine. Dw
Re: DoS with mod_deflate range requests
On Aug 24, 2011, at 4:05 AM, Plüm, Rüdiger, VF-Group wrote: Patch looks good, but some comments: As far as I can see the following range request would not get merged: Range: bytes=0-0,1-1,2-2 into a 0-2 range as need_sort would remain 0. OTOH Range: bytes=0-0,0-1,1-2 would get get merged into a 0-2 range. Using boundary and !boundary in the later if statements to decide whether a request is multi range or single range is IMHO bad as boundary is set based on the old number ranges and not based on the number of merged ranges. So multiple ranges in the beginning might get merged to a single range in the end. +1… Suggestion: Let's fold the patch, as-is, into trunk, tune it there and then backport to 2.x...
RE: DoS with mod_deflate range requests
-Original Message- From: Dirk-Willem van Gulik [mailto:dirk-willem.van.gu...@bbc.co.uk] Sent: Mittwoch, 24. August 2011 17:46 To: dev@httpd.apache.org Subject: Re: DoS with mod_deflate range requests On 24 Aug 2011, at 16:35, Tim Bannister wrote: On Tue, Aug 23, 2011, Roy T. Fielding wrote: And the spec says ... When a client requests multiple ranges in one request, the server SHOULD return them in the order that they appeared in the request. My suggestion is to reject any request with overlapping ranges or more than five ranges with a 416, and to send 200 for any request with 4-5 ranges. There is simply no need to support random access in HTTP. Deshpande Zeng in http://dx.doi.org/10.1145/500141.500197 describe a method for streaming JPEG 2000 documents over HTTP, using many more than 5 ranges in a single request. A client that knows about any server-side limit could make multiple requests each with a small number of ranges, but discovering that limit will add latency and take more code. Agreed - I've seen many 10's of ranges in a single request for things like clever PDF pagination (or tiny TIFF quicklooks for the pages), clever http fake streaming and clever use of jumping to i-Frames. I think we just need to sit this out - and accept up to RequestFieldSize limit bytes on that line - and then do a sort merge overlaps as needed. Hm. If I got it right what Roy says above about the spec sorting and merging is not an option as we need to stick to the order and number of ranges the client requested. But we can deny overlapping with a 416. Or we do a 416 as well if merging would change something. Regards Rüdiger
Re: DoS with mod_deflate range requests
Sorting isn't allowed but I get the impression that merging is OK… Roy can confirm… If not, then some sort of runtime limit on the number of allowable ranges plus a 416 w/ overlapping ranges makes the most sense. On Aug 24, 2011, at 11:55 AM, Plüm, Rüdiger, VF-Group wrote: Hm. If I got it right what Roy says above about the spec sorting and merging is not an option as we need to stick to the order and number of ranges the client requested. But we can deny overlapping with a 416. Or we do a 416 as well if merging would change something. Regards Rüdiger
RE: DoS with mod_deflate range requests
-Original Message- From: Jim Jagielski [mailto:j...@jagunet.com] Sent: Mittwoch, 24. August 2011 17:48 To: dev@httpd.apache.org Subject: Re: DoS with mod_deflate range requests On Aug 24, 2011, at 4:05 AM, Plüm, Rüdiger, VF-Group wrote: Patch looks good, but some comments: As far as I can see the following range request would not get merged: Range: bytes=0-0,1-1,2-2 into a 0-2 range as need_sort would remain 0. OTOH Range: bytes=0-0,0-1,1-2 would get get merged into a 0-2 range. Using boundary and !boundary in the later if statements to decide whether a request is multi range or single range is IMHO bad as boundary is set based on the old number ranges and not based on the number of merged ranges. So multiple ranges in the beginning might get merged to a single range in the end. +1... Suggestion: Let's fold the patch, as-is, into trunk, tune it there and then backport to 2.x... Based on Roy's comment about the spec I think we cannot optimize this way. I think we can only detect if something weird goes on (overlapping, merging would result in smaller number of ranges, excessive number of ranges, whereas excessive needs to be configurable with a sane default) and reply with a 416 then. Regards Rüdiger
RE: DoS with mod_deflate range requests
-Original Message- From: Jim Jagielski [mailto:j...@jagunet.com] Sent: Mittwoch, 24. August 2011 18:02 To: dev@httpd.apache.org Subject: Re: DoS with mod_deflate range requests Sorting isn't allowed but I get the impression that merging is OK... Roy can confirm... But merging might require sorting... If not, then some sort of runtime limit on the number of allowable ranges plus a 416 w/ overlapping ranges makes the most sense. On Aug 24, 2011, at 11:55 AM, Plüm, Rüdiger, VF-Group wrote: Hm. If I got it right what Roy says above about the spec sorting and merging is not an option as we need to stick to the order and number of ranges the client requested. But we can deny overlapping with a 416. Or we do a 416 as well if merging would change something. Regards Rüdiger Regards Rüdiger
Re: Mitigation Range header
On Wed, Aug 24, 2011 at 10:33 AM, Plüm, Rüdiger, VF-Group ruediger.pl...@vodafone.com wrote: ** I think mod_deflate is just the tool to convert an O(N^2) data size problem into an O(N^2) CPU usage problem, where N is some function of LimitRequestLine. If the file size is smaller than the largest range end used in the attack, it may reduce the amount of data actually going down the filter chain. Greg I don't think so. The compression happens before the byterange filter and the byterange filter just hacks the already compressed brigade into more buckets and rearranges them. mod_deflate does not do more work if it is a range request. It does the same amount of work as for the non range request. OK, thanks for the clarification, Rüdiger. Then I don't understand why mod_deflate seems to be an important factor in killing the server. If the DEFLATE filter runs first, can you do anything useful with a subrange of its output? i.e., could a client decompress a subrange that starts in the middle of the compressed version and get a subrange of the original uncompressed data? Greg
Re: DoS with mod_deflate range requests
On 8/24/2011 10:55 AM, Plüm, Rüdiger, VF-Group wrote: Hm. If I got it right what Roy says above about the spec sorting and merging is not an option as we need to stick to the order and number of ranges the client requested. No. Merging -is- recommended. 10.4.17 416 Requested Range Not Satisfiable A server SHOULD return a response with this status code if a request included a Range request-header field (section 14.35), and none of the range-specifier values in this field overlap the current extent of the selected resource, and the request did not include an If-Range request-header field. (For byte-ranges, this means that the first- byte-pos of all of the byte-range-spec values were greater than the current length of the selected resource.) Note; the FIRST byte-pos is invalid. It doesn't suggest that 416 can be used for semantically valid ranges longer than the document length, or to represent that valid byte ranges overlapped. In fact, if ONE range can be satisfied, 416 is not appropriate. So if ONE range can be satisfied, it is to be returned (this is reiterated in 14.16), which may obviously be out-of-sequence. I would suggest we simply ignore/extend for all overlapping ranges rather than rejecting them. E.g. 0-, 40-50 becomes 0- 0-499, 400-599 becomes 0-599 1000-1075, 200-250, 1051-1100 becomes 1000-1100, 200-250 -Sorting- is to be avoided, although as its a SHOULD, I am happy to break that recommendation if there is no reasonably efficient solution to the server side. As Roy suggests, random access on the server side is very dubious. A client issuing rich requests should assemble them and must respect the individual Content-Range response headers.
Re: DoS with mod_deflate range requests
On Aug 24, 2011, at 12:05 PM, Plüm, Rüdiger, VF-Group wrote: -Original Message- From: Jim Jagielski [mailto:j...@jagunet.com] Sent: Mittwoch, 24. August 2011 18:02 To: dev@httpd.apache.org Subject: Re: DoS with mod_deflate range requests Sorting isn't allowed but I get the impression that merging is OK... Roy can confirm... But merging might require sorting... then we don't do that merge, imo… In other words, we progress thru the set of ranges and once a range is merged as far as it can be (due to the next range not being merge-able with the previous one), we let it go...
RE: Mitigation Range header
From: Greg Ames [mailto:ames.g...@gmail.com] Sent: Mittwoch, 24. August 2011 18:20 To: dev@httpd.apache.org Subject: Re: Mitigation Range header On Wed, Aug 24, 2011 at 10:33 AM, Plüm, Rüdiger, VF-Group ruediger.pl...@vodafone.com wrote: I think mod_deflate is just the tool to convert an O(N^2) data size problem into an O(N^2) CPU usage problem, where N is some function of LimitRequestLine. If the file size is smaller than the largest range end used in the attack, it may reduce the amount of data actually going down the filter chain. Greg I don't think so. The compression happens before the byterange filter and the byterange filter just hacks the already compressed brigade into more buckets and rearranges them. mod_deflate does not do more work if it is a range request. It does the same amount of work as for the non range request. OK, thanks for the clarification, Rüdiger. Then I don't understand why mod_deflate seems to be an important factor in killing the server. If the DEFLATE filter runs first, can you do anything useful with a subrange of its output? i.e., could a client decompress a subrange that starts in the middle of the compressed version and get a subrange of the original uncompressed data? Greg It depends. Think of a download that was broken in the middle and that was compressed by mod_deflate on the fly. A client could just request the missing bits and decompress the whole thing afterwards. I guess in general it only works if the client has all the missing pieces (or at least the ones before the contents of the partial response) that are not sent via the partial response at hand to decompress the whole stream (or decompress at least until the last part of the partial response). Regards Rüdiger
Re: DoS with mod_deflate range requests
On Aug 24, 2011, at 12:22 PM, William A. Rowe Jr. wrote: 0-, 40-50 becomes 0- 0-499, 400-599 becomes 0-599 1000-1075, 200-250, 1051-1100 becomes 1000-1100, 200-250 This goes against Roy's recommendation to 416 overlaps… But I do see that an overlap is specifically noted in an example Until we are *clear* on what we should be doing, spec-wise, I think it's unwise to make assumptions… From the above, I would be more comfortable with 0-, 40-50 --- 0- 0-499, 400-599 --- 0-599 1000-1075, 1025-1088, 200-250, 1051-1100 -- 1000-1088, 200-250, 1051-1100 that it, merge as we can, but never resort...
Re: DoS with mod_deflate range requests
On Wednesday 24 August 2011, Jim Jagielski wrote: On Aug 24, 2011, at 12:05 PM, Plüm, Rüdiger, VF-Group wrote: -Original Message- From: Jim Jagielski [mailto:j...@jagunet.com] Sent: Mittwoch, 24. August 2011 18:02 To: dev@httpd.apache.org Subject: Re: DoS with mod_deflate range requests Sorting isn't allowed but I get the impression that merging is OK... Roy can confirm... But merging might require sorting... then we don't do that merge, imo… In other words, we progress thru the set of ranges and once a range is merged as far as it can be (due to the next range not being merge-able with the previous one), we let it go... We could also use a two stage approach: Up to some limit (e.g. 50) ranges, we return them as the client requested them. Over that limit, we violate the RFC-SHOULD and sort and merge them.
Re: DoS with mod_deflate range requests
On 24 Aug 2011, at 17:47, Stefan Fritsch wrote: On Wednesday 24 August 2011, Jim Jagielski wrote: On Aug 24, 2011, at 12:05 PM, Plüm, Rüdiger, VF-Group wrote: But merging might require sorting... then we don't do that merge, imo… In other words, we progress thru the set of ranges and once a range is merged as far as it can be (due to the next range not being merge-able with the previous one), we let it go... We could also use a two stage approach: Up to some limit (e.g. 50) ranges, we return them as the client requested them. Over that limit, we violate the RFC-SHOULD and sort and merge them. Another option is just to return 200. Servers MAY ignore the Range header. I prefer this because existing clients already handle that case well, and there's no opportunity for a client to exploit this (“malicious” clients that want the whole entity need only request it). Can anyone see why returning 200 for these complex requests (by ignoring Range / If-Range) is a bad idea? -- Tim Bannister – is...@jellybaby.net
Re: DoS with mod_deflate range requests
On Wed, Aug 24, 2011 at 12:42 PM, Jim Jagielski j...@jagunet.com wrote: On Aug 24, 2011, at 12:22 PM, William A. Rowe Jr. wrote: 0-, 40-50 becomes 0- 0-499, 400-599 becomes 0-599 1000-1075, 200-250, 1051-1100 becomes 1000-1100, 200-250 This goes against Roy's recommendation to 416 overlaps… But I do see that an overlap is specifically noted in an example yeah. The very end of section 14.35.1 says an overlap is legal, so I'm confused. Until we are *clear* on what we should be doing, spec-wise, I think it's unwise to make assumptions… From the above, I would be more comfortable with 0-, 40-50 --- 0- 0-499, 400-599 --- 0-599 1000-1075, 1025-1088, 200-250, 1051-1100 -- 1000-1088, 200-250, 1051-1100 that it, merge as we can, but never resort... how about: 1000-2000,100-200,3000-4000,200-300,1999-3001 ? If we don't return a 416 for that due to overlap, I think the merge should be; 1000-4000,100-300 If we only merge adjacent ascending ranges, then it seems like an attacker could just craft a header where the ranges jump around and dodge our fix. The other small point I wanted to make is that both ends of a range could overlap previously specified ranges. Greg
Re: DoS with mod_deflate range requests
On Aug 24, 2011, at 2:43 PM, Tim Bannister wrote: On 24 Aug 2011, at 17:47, Stefan Fritsch wrote: On Wednesday 24 August 2011, Jim Jagielski wrote: On Aug 24, 2011, at 12:05 PM, Plüm, Rüdiger, VF-Group wrote: But merging might require sorting... then we don't do that merge, imo… In other words, we progress thru the set of ranges and once a range is merged as far as it can be (due to the next range not being merge-able with the previous one), we let it go... We could also use a two stage approach: Up to some limit (e.g. 50) ranges, we return them as the client requested them. Over that limit, we violate the RFC-SHOULD and sort and merge them. Another option is just to return 200. Servers MAY ignore the Range header. I prefer this because existing clients already handle that case well, and there's no opportunity for a client to exploit this (“malicious” clients that want the whole entity need only request it). Can anyone see why returning 200 for these complex requests (by ignoring Range / If-Range) is a bad idea? In what cases would we ignore it? Dependent only on =X ranges? It does seem that 14.5 gives us this as an out...
Re: DoS with mod_deflate range requests
On Aug 24, 2011, at 3:10 PM, Greg Ames wrote: On Wed, Aug 24, 2011 at 12:42 PM, Jim Jagielski j...@jagunet.com wrote: From the above, I would be more comfortable with 0-, 40-50 --- 0- 0-499, 400-599 --- 0-599 1000-1075, 1025-1088, 200-250, 1051-1100 -- 1000-1088, 200-250, 1051-1100 that it, merge as we can, but never resort... how about: 1000-2000,100-200,3000-4000,200-300,1999-3001 ? If we don't return a 416 for that due to overlap, I think the merge should be; 1000-4000,100-300 That's what Bill thinks as well, but that almost seems like a resorting to be, such that the 100-200 range (2nd requested) comes *after* the server sends 3000-4000, which is actually the 3rd range requested. If we only merge adjacent ascending ranges, then it seems like an attacker could just craft a header where the ranges jump around and dodge our fix. I think no matter what, we should still have some sort of upper limit on the number of range-sets we accept… after all, merge doesn't prevent jumping around ;)
Re: DoS with mod_deflate range requests
On 8/24/2011 11:42 AM, Jim Jagielski wrote: On Aug 24, 2011, at 12:22 PM, William A. Rowe Jr. wrote: 0-, 40-50 becomes 0- 0-499, 400-599 becomes 0-599 1000-1075, 200-250, 1051-1100 becomes 1000-1100, 200-250 This goes against Roy's recommendation to 416 overlaps… But I do see that an overlap is specifically noted in an example And... 416 is not identified for this specific purpose, we would need to go with 400 or fall back on the 200 full-content solution. Until we are *clear* on what we should be doing, spec-wise, I think it's unwise to make assumptions… From the above, I would be more comfortable with 0-, 40-50 --- 0- 0-499, 400-599 --- 0-599 1000-1075, 1025-1088, 200-250, 1051-1100 -- 1000-1088, 200-250, 1051-1100 that it, merge as we can, but never resort... We should adamantly refuse to serve bytes 1051-1088 twice, no matter which scheme we use.
Re: Final draft / CVE-2011-3192
I'm seeing Apache 2.0 doesn't accept our RequestHeader syntax due to a
defect, it misinterprets it as a value and fails startup.
If we have the opportunity to amend, I think we need to suggest the
rewrite flavor for Apache 2.0 and earlier, not just 1.3 and earlier.
Also for 1.3, is our RE safe for non-PCRE? And should we reconsider
the 5 for something more liberal?
Option 1: (Apache 2.0 and 2.2)
# drop Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
# optional logging.
CustomLog logs/range-CVE-2011-3192.log common env=bad-range
Option 2: (Also for Apache 1.3)
# Reject request when more than 5 ranges in the Range: header.
# CVE-2011-3192
#
RewriteEngine on
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
RewriteRule .* - [F]
Re: DoS with mod_deflate range requests
On Aug 24, 2011, at 3:34 PM, William A. Rowe Jr. wrote: On 8/24/2011 11:42 AM, Jim Jagielski wrote: On Aug 24, 2011, at 12:22 PM, William A. Rowe Jr. wrote: 0-, 40-50 becomes 0- 0-499, 400-599 becomes 0-599 1000-1075, 200-250, 1051-1100 becomes 1000-1100, 200-250 This goes against Roy's recommendation to 416 overlaps… But I do see that an overlap is specifically noted in an example And... 416 is not identified for this specific purpose, we would need to go with 400 or fall back on the 200 full-content solution. Until we are *clear* on what we should be doing, spec-wise, I think it's unwise to make assumptions… From the above, I would be more comfortable with 0-, 40-50 --- 0- 0-499, 400-599 --- 0-599 1000-1075, 1025-1088, 200-250, 1051-1100 -- 1000-1088, 200-250, 1051-1100 that it, merge as we can, but never resort... We should adamantly refuse to serve bytes 1051-1088 twice, no matter which scheme we use. Why? If allowed by the spec, or, at least, not disallowed, then what is the rationale? After all, the client is expecting it after it gets bytes 200-250.
Re: CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 (DRAFT-3)
On Wed, 24 Aug 2011 09:30:34 -0400
Eric Covener cove...@gmail.com wrote:
Or more like Ruedigers:
SetEnvIf Range (,[^,]*){5,} bad-range=1
Or just
Untaint HTTP_RANGE (,[^,]*){5,}
Is it time to re-suggest dropping mod_taint into trunk?
--
Nick Kew
Re: Final draft / CVE-2011-3192
That is fine - we can do another update tomorrow, say noon zulu - if we expect
that we do not have a proper patch and/or a 2.0.65 / 2.2.20 in the day
following.
Weird though - my 2.0.61 and 64 does seem fine. So probably very early 2.0
series.
Dw
On 24 Aug 2011, at 20:40, Eric Covener wrote:
I'm seeing Apache 2.0 doesn't accept our RequestHeader syntax due to a
defect, it misinterprets it as a value and fails startup.
If we have the opportunity to amend, I think we need to suggest the
rewrite flavor for Apache 2.0 and earlier, not just 1.3 and earlier.
Also for 1.3, is our RE safe for non-PCRE? And should we reconsider
the 5 for something more liberal?
Option 1: (Apache 2.0 and 2.2)
# drop Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
# optional logging.
CustomLog logs/range-CVE-2011-3192.log common env=bad-range
Option 2: (Also for Apache 1.3)
# Reject request when more than 5 ranges in the Range: header.
# CVE-2011-3192
#
RewriteEngine on
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
RewriteRule .* - [F]
Re: DoS with mod_deflate range requests
On 24 Aug 2011, at 20:13, Jim Jagielski wrote: Another option is just to return 200. Servers MAY ignore the Range header. I prefer this because existing clients already handle that case well, and there's no opportunity for a client to exploit this (“malicious” clients that want the whole entity need only request it). Can anyone see why returning 200 for these complex requests (by ignoring Range / If-Range) is a bad idea? In what cases would we ignore it? Dependent only on =X ranges? I don't have any strong opinion about exactly when to ignore Range. From an HTTP client PoV I wouldn't want to get 416 from requesting a satisfiable but complex range (maliciously or otherwise). Ignoring Range on (ranges = X) is simple to implement and easy to document, so why not do that? -- Tim Bannister – is...@jellybaby.net
Re: DoS with mod_deflate range requests
On Wed, Aug 24, 2011 at 3:19 PM, Jim Jagielski j...@jagunet.com wrote: If we only merge adjacent ascending ranges, then it seems like an attacker could just craft a header where the ranges jump around and dodge our fix. I think no matter what, we should still have some sort of upper limit on the number of range-sets we accept… after all, merge doesn't prevent jumping around ;) The problem I have with the upper limit on the number of range sets is the use case someone posted for JPEG2000 streaming. That has a lot of range sets but is completely legit. However, the ranges are in ascending order and don't overlap. Maybe we could count overlaps and/or non-ascending order ranges and fall back to 200 + the whole object if it exceeds a limit. Greg
Re: DoS with mod_deflate range requests
On 24 Aug 2011, at 21:39, Greg Ames wrote: On Wed, Aug 24, 2011 at 3:19 PM, Jim Jagielski j...@jagunet.com wrote: If we only merge adjacent ascending ranges, then it seems like an attacker could just craft a header where the ranges jump around and dodge our fix. I think no matter what, we should still have some sort of upper limit on the number of range-sets we accept… after all, merge doesn't prevent jumping around ;) The problem I have with the upper limit on the number of range sets is the use case someone posted for JPEG2000 streaming. That has a lot of range sets but is completely legit. However, the ranges are in ascending order and don't overlap. Maybe we could count overlaps and/or non-ascending order ranges and fall back to 200 + the whole object if it exceeds a limit. Right - and the other two use cases in the wild are - PDF readers - which fetch something at the start in RQ 1 and then the index form the end - and then quick looks images for each page and title pages. I've seen them do a second and 3rd request with many 10's of ranges. - Some of the streaming video (semi/pro) video editors - which fetch a bunch of i-Frames and do clever skip over stuff. Not in the high tens; but 10-15 ranges common. - Likewise for very clever MXF professional editing equipment - the largest case (yup - it did crash my server) tried to fetch over 2000 ranges :) So I think we really should endeavor to allow 50 to a few 100 of them. Or at the very least - make it a config option to cut off below 50 or so. Dw.
Re: DoS with mod_deflate range requests
On Aug 24, 2011, at 8:35 AM, Tim Bannister wrote: On Tue, Aug 23, 2011, Roy T. Fielding wrote: And the spec says ... When a client requests multiple ranges in one request, the server SHOULD return them in the order that they appeared in the request. My suggestion is to reject any request with overlapping ranges or more than five ranges with a 416, and to send 200 for any request with 4-5 ranges. There is simply no need to support random access in HTTP. Deshpande Zeng in http://dx.doi.org/10.1145/500141.500197 describe a method for streaming JPEG 2000 documents over HTTP, using many more than 5 ranges in a single request. A client that knows about any server-side limit could make multiple requests each with a small number of ranges, but discovering that limit will add latency and take more code. I have no interest in supporting such a use case over HTTP. Consider how stupid it is to request ranges like their example Range: bytes=120-168,175-200,205-300,345-346,400-500,555-666, 667-800,900-1000,2500-2567,2890-3056,5678-9000, 1-12004,12050-12060,15600-15605,17000-17001, 17005-17010,17050-17060,17800-17905,2-20005 keeping in mind that between each one of those ranges will be a multipart boundary of approximately 80 bytes! Hence, any range request that contains gaps of less than 80 bytes should be considered a denial of service, or at least an idiot programmer that deserves to be slapped by Apache. To be clear, I am more than willing to rewrite the part on Ranges such that the above is explicitly forbidden in HTTP. I am not sure what the WG would agree to, but I am quite certain that part of the reason we have an Apache server is to protect the Internet from idiotic ideas like the above. Roy
Re: DoS with mod_deflate range requests
On Aug 24, 2011, at 8:55 AM, Plüm, Rüdiger, VF-Group wrote: Hm. If I got it right what Roy says above about the spec sorting and merging is not an option as we need to stick to the order and number of ranges the client requested. But we can deny overlapping with a 416. We should implement whatever is needed to make the service secure from this denial of service. If that means changing the spec, then so be it. Or we do a 416 as well if merging would change something. Or 200 if folks are squeamish about making the developer feel the pain. Roy
Re: DoS with mod_deflate range requests
On 8/24/2011 3:45 PM, Dirk-WIllem van Gulik wrote: On 24 Aug 2011, at 21:39, Greg Ames wrote: On Wed, Aug 24, 2011 at 3:19 PM, Jim Jagielski j...@jagunet.com mailto:j...@jagunet.com wrote: If we only merge adjacent ascending ranges, then it seems like an attacker could just craft a header where the ranges jump around and dodge our fix. I think no matter what, we should still have some sort of upper limit on the number of range-sets we accept… after all, merge doesn't prevent jumping around ;) The problem I have with the upper limit on the number of range sets is the use case someone posted for JPEG2000 streaming. That has a lot of range sets but is completely legit. However, the ranges are in ascending order and don't overlap. Maybe we could count overlaps and/or non-ascending order ranges and fall back to 200 + the whole object if it exceeds a limit. Right - and the other two use cases in the wild are -PDF readers - which fetch something at the start in RQ 1 and then the index form the end - and then quick looks images for each page and title pages. I've seen them do a second and 3rd request with many 10's of ranges. -Some of the streaming video (semi/pro) video editors - which fetch a bunch of i-Frames and do clever skip over stuff. Not in the high tens; but 10-15 ranges common. -Likewise for very clever MXF professional editing equipment - the largest case (yup - it did crash my server) tried to fetch over 2000 ranges :) So I think we really should endeavor to allow 50 to a few 100 of them. Or at the very least - make it a config option to cut off below 50 or so. At least, after 256 ranges or so, fall back to a 200 response in lieu of a 400/416 response.
Re: DoS with mod_deflate range requests
On 8/24/2011 3:12 PM, Jim Jagielski wrote: On Aug 24, 2011, at 3:34 PM, William A. Rowe Jr. wrote: On 8/24/2011 11:42 AM, Jim Jagielski wrote: On Aug 24, 2011, at 12:22 PM, William A. Rowe Jr. wrote: 0-, 40-50 becomes 0- 0-499, 400-599 becomes 0-599 1000-1075, 200-250, 1051-1100 becomes 1000-1100, 200-250 This goes against Roy's recommendation to 416 overlaps… But I do see that an overlap is specifically noted in an example And... 416 is not identified for this specific purpose, we would need to go with 400 or fall back on the 200 full-content solution. Until we are *clear* on what we should be doing, spec-wise, I think it's unwise to make assumptions… From the above, I would be more comfortable with 0-, 40-50 --- 0- 0-499, 400-599 --- 0-599 1000-1075, 1025-1088, 200-250, 1051-1100 -- 1000-1088, 200-250, 1051-1100 that it, merge as we can, but never resort... We should adamantly refuse to serve bytes 1051-1088 twice, no matter which scheme we use. Why? If allowed by the spec, or, at least, not disallowed, then what is the rationale? After all, the client is expecting it after it gets bytes 200-250. The client was malformed, if not malicious. The range 0-,0-,0-,0- is syntactically valid, but the client doesn't deserve four copies.
Re: DoS with mod_deflate range requests
On Wednesday 24 August 2011, Dirk-WIllem van Gulik wrote: I think no matter what, we should still have some sort of upper limit on the number of range-sets we accept… after all, merge doesn't prevent jumping around ;) The problem I have with the upper limit on the number of range sets is the use case someone posted for JPEG2000 streaming. That has a lot of range sets but is completely legit. However, the ranges are in ascending order and don't overlap. Maybe we could count overlaps and/or non-ascending order ranges and fall back to 200 + the whole object if it exceeds a limit. Right - and the other two use cases in the wild are - PDF readers - which fetch something at the start in RQ 1 and then the index form the end - and then quick looks images for each page and title pages. I've seen them do a second and 3rd request with many 10's of ranges. - Some of the streaming video (semi/pro) video editors - which fetch a bunch of i-Frames and do clever skip over stuff. Not in the high tens; but 10-15 ranges common. - Likewise for very clever MXF professional editing equipment - the largest case (yup - it did crash my server) tried to fetch over 2000 ranges :) So I think we really should endeavor to allow 50 to a few 100 of them. Or at the very least - make it a config option to cut off below 50 or so. Do you know if those clients send the ranges in order? If they are sorted, it is easy to check if they are non-overlapping. And in that case, we could easily allow 1000 ranges.
Fixing Ranges
AFAICS[1], we've discussed an advisory and some protections users can deploy. For the future we should be looking at a robust solution that prevents Range requests only when they're likely to present a problem. Most obviously, we should be able to serve arbitrary ranges from any static or cached file without sweat to support apps such as JPEG2000 or PDF streaming. That can be done much more efficiently at source than in a ranges filter. Does this look like a plan? 1. Add Ranges capability into the default handler and mod_cache. They could then set a ranges-handled flag in r-notes. 2. Insert the Ranges filter according to the logic that's been discussed here today. 3. The Ranges filter then checks ranges-handled, and removes itself if set, to avoid returning recursive ranges. I guess implementing that would imply factoring out the multipart encoding stuff from the range filter into an API. [1] that is, returning to an overflowing mailbox after a tiring day in offline chores, so I could easily have missed something! -- Nick Kew
Re: DoS with mod_deflate range requests
I'm cool w/ that… treat non-ascending ranges as potential hinky and count those and only allow a certain number of them… Still not sure if we should count overlaps as bad or not… that RFC example troubles me: 14.35.1 Byte Ranges - Several legal but not canonical specifications of the second 500 bytes (byte offsets 500-999, inclusive): bytes=500-600,601-999 bytes=500-700,601-999 The 2nd seems to imply that one *MUST* merge adjacent overlaps to get the correct response (500 bytes not 201+399=600bytes) With all that in mind, I am still of the opinion that any adjacent overlaps should be merged… So how about we parse Range and merge all adjacent overlaps (or merges (200-249,250-999 would merge into 200-999); We then count how many non-ascends are in that revised set of ranges and 200 out if it exceeds some config limit. We can also provide some overall limit on the number of ranges, or at least the ability to add one (a default of 0 means unlimited)… Sound OK? On Aug 24, 2011, at 4:39 PM, Greg Ames wrote: On Wed, Aug 24, 2011 at 3:19 PM, Jim Jagielski j...@jagunet.com wrote: If we only merge adjacent ascending ranges, then it seems like an attacker could just craft a header where the ranges jump around and dodge our fix. I think no matter what, we should still have some sort of upper limit on the number of range-sets we accept… after all, merge doesn't prevent jumping around ;) The problem I have with the upper limit on the number of range sets is the use case someone posted for JPEG2000 streaming. That has a lot of range sets but is completely legit. However, the ranges are in ascending order and don't overlap. Maybe we could count overlaps and/or non-ascending order ranges and fall back to 200 + the whole object if it exceeds a limit. Greg
Re: DoS with mod_deflate range requests
On Aug 24, 2011, at 5:00 PM, William A. Rowe Jr. wrote: At least, after 256 ranges or so, fall back to a 200 response in lieu of a 400/416 response. +1 on not sending 416 if we hit some limit and fall back on 200.
Re: DoS with mod_deflate range requests
On 8/24/2011 3:56 PM, Roy T. Fielding wrote: On Aug 24, 2011, at 8:35 AM, Tim Bannister wrote: On Tue, Aug 23, 2011, Roy T. Fielding wrote: And the spec says ... When a client requests multiple ranges in one request, the server SHOULD return them in the order that they appeared in the request. My suggestion is to reject any request with overlapping ranges or more than five ranges with a 416, and to send 200 for any request with 4-5 ranges. There is simply no need to support random access in HTTP. Deshpande Zeng in http://dx.doi.org/10.1145/500141.500197 describe a method for streaming JPEG 2000 documents over HTTP, using many more than 5 ranges in a single request. A client that knows about any server-side limit could make multiple requests each with a small number of ranges, but discovering that limit will add latency and take more code. I have no interest in supporting such a use case over HTTP. Consider how stupid it is to request ranges like their example Range: bytes=120-168,175-200,205-300,345-346,400-500,555-666, 667-800,900-1000,2500-2567,2890-3056,5678-9000, 1-12004,12050-12060,15600-15605,17000-17001, 17005-17010,17050-17060,17800-17905,2-20005 keeping in mind that between each one of those ranges will be a multipart boundary of approximately 80 bytes! Hence, any range request that contains gaps of less than 80 bytes should be considered a denial of service, or at least an idiot programmer that deserves to be slapped by Apache. To be clear, I am more than willing to rewrite the part on Ranges such that the above is explicitly forbidden in HTTP. I am not sure what the WG would agree to, but I am quite certain that part of the reason we have an Apache server is to protect the Internet from idiotic ideas like the above. Then if we are opening up the spec for sensible revision, particularly in the gray areas of what was not answered, insisting that the server is free to respond to the client with any serialized superset of their requested ranges [deliberately ignoring the SHOULD in the section you had previously quoted] is the right answer. In your pedantic case above, adjacent ranges 80 bytes apart would be processed as a single merged range. A client insisting on ranges must be prepared to follow the rules provided to all proxies in that section on range handling, given that the proxy case is already one user agent case, and the requirements for proxy handling should certainly be applied in the generic case. The spec does not actually state that ranges are returned 1:1 in sequence, and I believe we should liberally read this to protect the server from abuse. Perhaps we have a threshold number of ranges which trigger the behavior, or any overlapping (apparently abusive) range requests would trigger the behavior regardless.
Re: Fixing Ranges
On 8/24/2011 4:06 PM, Nick Kew wrote: AFAICS[1], we've discussed an advisory and some protections users can deploy. For the future we should be looking at a robust solution that prevents Range requests only when they're likely to present a problem. Most obviously, we should be able to serve arbitrary ranges from any static or cached file without sweat to support apps such as JPEG2000 or PDF streaming. That can be done much more efficiently at source than in a ranges filter. Does this look like a plan? 1. Add Ranges capability into the default handler and mod_cache. They could then set a ranges-handled flag in r-notes. Fails if the default handler has been filtered into a differently sized document, e.g. code page conversion. 2. Insert the Ranges filter according to the logic that's been discussed here today. 3. The Ranges filter then checks ranges-handled, and removes itself if set, to avoid returning recursive ranges. You are now requiring all filters which change the document's geometry to not only discard C-L, but also reset ranges-handled. Not a reasonable path forward for 2.[02].x.
Re: Fixing Ranges
On Wednesday 24 August 2011, Nick Kew wrote: AFAICS[1], we've discussed an advisory and some protections users can deploy. For the future we should be looking at a robust solution that prevents Range requests only when they're likely to present a problem. Most obviously, we should be able to serve arbitrary ranges from any static or cached file without sweat to support apps such as JPEG2000 or PDF streaming. That can be done much more efficiently at source than in a ranges filter. Does this look like a plan? 1. Add Ranges capability into the default handler and mod_cache. They could then set a ranges-handled flag in r-notes. 2. Insert the Ranges filter according to the logic that's been discussed here today. 3. The Ranges filter then checks ranges-handled, and removes itself if set, to avoid returning recursive ranges. I guess implementing that would imply factoring out the multipart encoding stuff from the range filter into an API. This looks like an awful lot of work for me to fix something that should be a simple issue. And it is definitely too intrusive for 2.2. I have another idea: Instead of using apr_brigade_partition write a new function ap_brigade_copy_part that leaves the original brigade untouched. It would copy the necessary buckets to a new brigade and then split the first and last of those copied buckets as necessary and destroy the excess buckets. AFAICS, this would reduce the quadratic growth into linear. Do you think that would solve our problems?
Re: DoS with mod_deflate range requests
On 8/24/2011 4:06 PM, Jim Jagielski wrote: I'm cool w/ that… treat non-ascending ranges as potential hinky and count those and only allow a certain number of them… Still not sure if we should count overlaps as bad or not… that RFC example troubles me: 14.35.1 Byte Ranges - Several legal but not canonical specifications of the second 500 bytes (byte offsets 500-999, inclusive): bytes=500-600,601-999 bytes=500-700,601-999 The 2nd seems to imply that one *MUST* merge adjacent overlaps to get the correct response (500 bytes not 201+399=600bytes) With all that in mind, I am still of the opinion that any adjacent overlaps should be merged… So how about we parse Range and merge all adjacent overlaps (or merges (200-249,250-999 would merge into 200-999); We then count how many non-ascends are in that revised set of ranges and 200 out if it exceeds some config limit. We can also provide some overall limit on the number of ranges, or at least the ability to add one (a default of 0 means unlimited)… Sound OK? Yup, sounds good. The only question is non-adjacent overlaps. Given Roy's pedantic example, I believe we should also start to dismiss any gap of less than X (80 bytes?) and provide those bytes as well in the merged range. Yes, clients may break. They were morons anyways for asking us to skip a few bytes for them and increase network traffic. Once the author accommodates the fact that they aren't in control, the response is semantically accurate. For that matter, perhaps User-Agent could be used to determine if we have a backwards-broken client for which we fall into the very well documented 200 response.
Re: DoS with mod_deflate range requests
On Wed, Aug 24, 2011 at 5:06 PM, Jim Jagielski j...@jagunet.com wrote: I'm cool w/ that… treat non-ascending ranges as potential hinky and count those and only allow a certain number of them… Still not sure if we should count overlaps as bad or not… that RFC example troubles me: 14.35.1 Byte Ranges - Several legal but not canonical specifications of the second 500 bytes (byte offsets 500-999, inclusive): bytes=500-600,601-999 bytes=500-700,601-999 The 2nd seems to imply that one *MUST* merge adjacent overlaps to get the correct response (500 bytes not 201+399=600bytes) With all that in mind, I am still of the opinion that any adjacent overlaps should be merged… So how about we parse Range and merge all adjacent overlaps (or merges (200-249,250-999 would merge into 200-999); We then count how many non-ascends are in that revised set of ranges and 200 out if it exceeds some config limit. Sounds good to me. Maybe re-define an overlap to include gaps of less than 80 bytes, per Roy's comments, and merge those too. We can also provide some overall limit on the number of ranges, or at least the ability to add one (a default of 0 means unlimited)… sure, but it feels less urgent than the above. Greg
Re: DoS with mod_deflate range requests
On Aug 24, 2011, at 1:56 PM, Roy T. Fielding wrote: To be clear, I am more than willing to rewrite the part on Ranges such that the above is explicitly forbidden in HTTP. I am not sure what the WG would agree to, but I am quite certain that part of the reason we have an Apache server is to protect the Internet from idiotic ideas like the above. http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311 Roy
My first Apache module!
Hey everyone, I don't like to bother mailing lists with beginner questions so I spent a few hours on Google looking for info and tutorials. I'm sure at least one of you has had that experience :) Anyway, I have finished my first module and it works exactly how I want it to. I still have more features I want to add but I'm a little rusty with my C and even worse at Apache Modules. Would you mind taking a glance at my code to see if I'm doing anything wrong or have any memory leaks or anything? Here's the source code: https://github.com/chrislondon/Dynamic-Stylesheets/blob/master/mod_dss.c Feel free to fork my project: https://github.com/chrislondon/Dynamic-Stylesheets The README file ( https://github.com/chrislondon/Dynamic-Stylesheets/blob/master/README) contains usage info and the project contains a simple test case. Thanks everyone! Chris London CTO - Kwista, LLC. ch...@kwista.com
[PATCH] mod_status: s/%c/'%c'/ in table
Rationale: allow me to search in my browser for 'W' (with quotes) to
find entries in the W state.
Patch (against trunk):
[[[
Index: modules/generators/mod_status.c
===
--- modules/generators/mod_status.c (revision 1161295)
+++ modules/generators/mod_status.c (working copy)
@@ -765,40 +765,40 @@
switch (ws_record-status) {
case SERVER_READY:
-ap_rputs(/tdtd_, r);
+ap_rputs(/tdtd'_', r);
break;
case SERVER_STARTING:
-ap_rputs(/tdtdbS/b, r);
+ap_rputs(/tdtdb'S'/b, r);
break;
case SERVER_BUSY_READ:
-ap_rputs(/tdtdbR/b, r);
+ap_rputs(/tdtdb'R'/b, r);
break;
case SERVER_BUSY_WRITE:
-ap_rputs(/tdtdbW/b, r);
+ap_rputs(/tdtdb'W'/b, r);
break;
case SERVER_BUSY_KEEPALIVE:
-ap_rputs(/tdtdbK/b, r);
+ap_rputs(/tdtdb'K'/b, r);
break;
case SERVER_BUSY_LOG:
-ap_rputs(/tdtdbL/b, r);
+ap_rputs(/tdtdb'L'/b, r);
break;
case SERVER_BUSY_DNS:
-ap_rputs(/tdtdbD/b, r);
+ap_rputs(/tdtdb'D'/b, r);
break;
case SERVER_CLOSING:
-ap_rputs(/tdtdbC/b, r);
+ap_rputs(/tdtdb'C'/b, r);
break;
case SERVER_DEAD:
-ap_rputs(/tdtd., r);
+ap_rputs(/tdtd'.', r);
break;
case SERVER_GRACEFUL:
-ap_rputs(/tdtdG, r);
+ap_rputs(/tdtd'G', r);
break;
case SERVER_IDLE_KILL:
-ap_rputs(/tdtdI, r);
+ap_rputs(/tdtd'I', r);
break;
default:
-ap_rputs(/tdtd?, r);
+ap_rputs(/tdtd'?', r);
break;
}
]]]
I'll send in a formal bug report if it helps, but hoped that for a trivial
patch the registration/filing overhead could be spared.
Re: Fixing Ranges
On Wed, Aug 24, 2011 at 5:16 PM, Stefan Fritsch s...@sfritsch.de wrote: I have another idea: Instead of using apr_brigade_partition write a new function ap_brigade_copy_part that leaves the original brigade untouched. It would copy the necessary buckets to a new brigade and then split the first and last of those copied buckets as necessary and destroy the excess buckets. AFAICS, this would reduce the quadratic growth into linear. Do you think that would solve our problems? How does apr_brigade_partition contribute to quadratic growth? Does the original brigade end up with a lot of one byte buckets? Greg
Re: Fixing Ranges
On Thursday 25 August 2011, Greg Ames wrote:
On Wed, Aug 24, 2011 at 5:16 PM, Stefan Fritsch s...@sfritsch.de
wrote:
I have another idea: Instead of using apr_brigade_partition write
a new function ap_brigade_copy_part that leaves the original
brigade untouched. It would copy the necessary buckets to a new
brigade and then split the first and last of those copied
buckets as necessary and destroy the excess buckets. AFAICS,
this would reduce the quadratic growth into linear. Do you think
that would solve our problems?
How does apr_brigade_partition contribute to quadratic growth?
Does the original brigade end up with a lot of one byte buckets?
Yes, it splits the buckets in the original brigade, creating up to two
new buckets for every range. These split one-byte buckets are then
copied again for each of the subsequent ranges.
The attached PoC patch does not change the original brigade and seems
to fix the DoS for me. It needs some more work and some review for
integer overflows, though. (apr_brigade_partition does some
interesting things there).
diff --git a/modules/http/byterange_filter.c b/modules/http/byterange_filter.c
index 13bf0a1..f363239 100644
--- a/modules/http/byterange_filter.c
+++ b/modules/http/byterange_filter.c
@@ -140,6 +140,98 @@ static int use_range_x(request_rec *r)
#define PARTITION_ERR_FMT apr_brigade_partition() failed \
[% APR_OFF_T_FMT ,% APR_OFF_T_FMT ]
+static apr_status_t copy_brigade_range(apr_bucket_brigade *bb,
+ apr_bucket_brigade *bbout,
+ apr_off_t start,
+ apr_off_t end)
+{
+apr_bucket *first = NULL, *last = NULL, *out_first = NULL, *e;
+apr_off_t pos = 0, off_first = 0, off_last = 0;
+apr_status_t rv;
+const char *s;
+apr_size_t len;
+
+if (start 0 || start end)
+return APR_EINVAL;
+
+for (e = APR_BRIGADE_FIRST(bb);
+ e != APR_BRIGADE_SENTINEL(bb);
+ e = APR_BUCKET_NEXT(e))
+{
+/* we know that no bucket has undefined length (-1) */
+AP_DEBUG_ASSERT(e-length != (apr_size_t)(-1));
+if (!first (e-length start || e-length + pos start)) {
+first = e;
+off_first = pos;
+}
+if (!last (e-length = end || e-length + pos = end)) {
+last = e;
+off_last = pos;
+break;
+}
+pos += e-length;
+}
+if (!first || !last)
+return APR_EINVAL;
+
+e = first;
+for (; ; )
+{
+apr_bucket *copy;
+AP_DEBUG_ASSERT(e != APR_BRIGADE_SENTINEL(bb));
+rv = apr_bucket_copy(e, copy);
+if (rv != APR_SUCCESS)
+goto err; /* XXX try apr_bucket_read */
+
+APR_BRIGADE_INSERT_TAIL(bbout, copy);
+if (e == first) {
+if (off_first != start) {
+rv = apr_bucket_split(copy, start - off_first);
+if (rv == APR_ENOTIMPL) {
+rv = apr_bucket_read(copy, s, len, APR_BLOCK_READ);
+if (rv != APR_SUCCESS)
+goto err;
+rv = apr_bucket_split(copy, start - off_first);
+if (rv != APR_SUCCESS)
+goto err;
+}
+out_first = APR_BUCKET_NEXT(copy);
+APR_BUCKET_REMOVE(copy);
+apr_bucket_destroy(copy);
+}
+else {
+out_first = copy;
+}
+}
+if (e == last) {
+if (e == first) {
+off_last += start - off_first;
+copy = out_first;
+}
+else {
+APR_BRIGADE_INSERT_TAIL(bbout, copy);
+}
+if (end - off_last != e-length) {
+rv = apr_bucket_split(copy, end + 1 - off_last);
+if (rv != APR_SUCCESS)
+goto err;
+copy = APR_BUCKET_NEXT(copy);
+APR_BUCKET_REMOVE(copy);
+apr_bucket_destroy(copy);
+}
+break;
+}
+e = APR_BUCKET_NEXT(e);
+}
+
+AP_DEBUG_ASSERT(APR_SUCCESS == apr_brigade_length(bbout, 1, pos));
+AP_DEBUG_ASSERT(pos == end - start + 1);
+return APR_SUCCESS;
+err:
+apr_brigade_cleanup(bbout);
+return rv;
+}
+
AP_CORE_DECLARE_NONSTD(apr_status_t) ap_byterange_filter(ap_filter_t *f,
apr_bucket_brigade *bb)
{
@@ -149,6 +241,7 @@ AP_CORE_DECLARE_NONSTD(apr_status_t) ap_byterange_filter(ap_filter_t *f,
byterange_ctx *ctx;
apr_bucket *e;
apr_bucket_brigade *bsend;
+apr_bucket_brigade *tmpbb;
apr_off_t range_start;
apr_off_t range_end;
char *current;
@@ -219,31 +312,24 @@ AP_CORE_DECLARE_NONSTD(apr_status_t) ap_byterange_filter(ap_filter_t *f,
/* this brigade holds
Re: DoS with mod_deflate range requests
On 8/24/2011 4:54 PM, Roy T. Fielding wrote: On Aug 24, 2011, at 1:56 PM, Roy T. Fielding wrote: To be clear, I am more than willing to rewrite the part on Ranges such that the above is explicitly forbidden in HTTP. I am not sure what the WG would agree to, but I am quite certain that part of the reason we have an Apache server is to protect the Internet from idiotic ideas like the above. http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311 Excellent, thanks. Just curious, isn't this clarification outside of the remit of 2616bis?
Re: DoS with mod_deflate range requests
On Aug 24, 2011, at 4:39 PM, William A. Rowe Jr. wrote: On 8/24/2011 4:54 PM, Roy T. Fielding wrote: On Aug 24, 2011, at 1:56 PM, Roy T. Fielding wrote: To be clear, I am more than willing to rewrite the part on Ranges such that the above is explicitly forbidden in HTTP. I am not sure what the WG would agree to, but I am quite certain that part of the reason we have an Apache server is to protect the Internet from idiotic ideas like the above. http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311 Excellent, thanks. Just curious, isn't this clarification outside of the remit of 2616bis? Security repairs are never out of scope. Roy
Re: DoS with mod_deflate range requests
On 8/24/2011 6:43 PM, Roy T. Fielding wrote: On Aug 24, 2011, at 4:39 PM, William A. Rowe Jr. wrote: On 8/24/2011 4:54 PM, Roy T. Fielding wrote: On Aug 24, 2011, at 1:56 PM, Roy T. Fielding wrote: To be clear, I am more than willing to rewrite the part on Ranges such that the above is explicitly forbidden in HTTP. I am not sure what the WG would agree to, but I am quite certain that part of the reason we have an Apache server is to protect the Internet from idiotic ideas like the above. http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311 Excellent, thanks. Just curious, isn't this clarification outside of the remit of 2616bis? Security repairs are never out of scope. Ack. So, I suspect the best we can do today, 4 days later, is to implement Roy's draft [link] as the POC/reference implementation and work with the rest of the http server community to ensure it is the right solution. I suggest we publish this as a patch, /not/ as a release, until we find just a bit more buy-in from the other implementors. Bill
Re: DoS with mod_deflate range requests
On Aug 24, 2011, at 4:56 PM, Roy T. Fielding wrote: On Aug 24, 2011, at 8:35 AM, Tim Bannister wrote: On Tue, Aug 23, 2011, Roy T. Fielding wrote: And the spec says ... When a client requests multiple ranges in one request, the server SHOULD return them in the order that they appeared in the request. My suggestion is to reject any request with overlapping ranges or more than five ranges with a 416, and to send 200 for any request with 4-5 ranges. There is simply no need to support random access in HTTP. Deshpande Zeng in http://dx.doi.org/10.1145/500141.500197 describe a method for streaming JPEG 2000 documents over HTTP, using many more than 5 ranges in a single request. A client that knows about any server-side limit could make multiple requests each with a small number of ranges, but discovering that limit will add latency and take more code. I have no interest in supporting such a use case over HTTP. Consider how stupid it is to request ranges like their example Range: bytes=120-168,175-200,205-300,345-346,400-500,555-666, 667-800,900-1000,2500-2567,2890-3056,5678-9000, 1-12004,12050-12060,15600-15605,17000-17001, 17005-17010,17050-17060,17800-17905,2-20005 keeping in mind that between each one of those ranges will be a multipart boundary of approximately 80 bytes! Hence, any range request that contains gaps of less than 80 bytes should be considered a denial of service, or at least an idiot programmer that deserves to be slapped by Apache. To be clear, I am more than willing to rewrite the part on Ranges such that the above is explicitly forbidden in HTTP. I am not sure what the WG would agree to, but I am quite certain that part of the reason we have an Apache server is to protect the Internet from idiotic ideas like the above. OK then… we seem to be coalescing into some consensus here… basically, if the client sends stuff which is brain-dead stupid, we simply 2000 and send the whole kit-and-kaboodle. I'd like to propose that we update the byterange filter to perform the following: o coalesce all adjacent ranges, whether overlapping or not. (eg: 200-250,251-300 200-250,220-300 both merge to 200-300) o We count: the number of times a gap between ranges is 80bytes the number of times we hit a descendent range (eg: 200-1000,2000-3000,1200-1500,4000-5000 would count as 1) the number of ranges total (post ascending merge) If any = some config-time limit, we send a 200 This is a start and was chosen simply for ease of implementation… We can then expand it to be more functional… Comments?
Re: DoS with mod_deflate range requests
On Aug 24, 2011, at 5:54 PM, Roy T. Fielding wrote: On Aug 24, 2011, at 1:56 PM, Roy T. Fielding wrote: To be clear, I am more than willing to rewrite the part on Ranges such that the above is explicitly forbidden in HTTP. I am not sure what the WG would agree to, but I am quite certain that part of the reason we have an Apache server is to protect the Internet from idiotic ideas like the above. http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311 This is why I still love httpd...
Re: Final draft / CVE-2011-3192
For Mitigation of Apache Range Header DoS Attack with mod_security, see
also:
http://blog.spiderlabs.com/2011/08/mitigation-of-apache-range-header-dos-attack.html
- Original Message -
From: Dirk-Willem van Gulik di...@webweaving.org
Newsgroups: gmane.comp.apache.devel
To: secur...@httpd.apache.org; dev@httpd.apache.org
Sent: Wednesday, August 24, 2011 5:34 PM
Subject: Final draft / CVE-2011-3192
Thanks for all the help. All fixes included. Below will go out to announce
at the top of the hour - unless I see a veto.
Dw.
Title:CVE-2011-3192: Range header DoS vulnerability Apache HTTPD 1.3/2.x
Apache HTTPD Security ADVISORY
Date: 20110824 1600Z
Product: Apache HTTPD Web Server
Versions: Apache 1.3 all versions, Apache 2 all versions
Description:
A denial of service vulnerability has been found in the way the multiple
overlapping ranges are handled by the Apache HTTPD server:
http://seclists.org/fulldisclosure/2011/Aug/175
An attack tool is circulating in the wild. Active use of this tools has
been observed.
The attack can be done remotely and with a modest number of requests can
cause very significant memory and CPU usage on the server.
The default Apache HTTPD installation is vulnerable.
There is currently no patch/new version of Apache HTTPD which fixes this
vulnerability. This advisory will be updated when a long term fix
is available.
A full fix is expected in the next 48 hours.
Mitigation:
However there are several immediate options to mitigate this issue until
that time.
1) Use SetEnvIf or mod_rewrite to detect a large number of ranges and then
either ignore the Range: header or reject the request.
Option 1: (Apache 2.0 and 2.2)
# drop Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
# optional logging.
CustomLog logs/range-CVE-2011-3192.log common env=bad-range
Option 2: (Also for Apache 1.3)
# Reject request when more than 5 ranges in the Range: header.
# CVE-2011-3192
#
RewriteEngine on
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
RewriteRule .* - [F]
The number 5 is arbitrary. Several 10's should not be an issue and may be
required for sites which for example serve PDFs to very high end eReaders
or use things such complex http based video streaming.
2) Limit the size of the request field to a few hundred bytes. Note that
while
this keeps the offending Range header short - it may break other headers;
such as sizeable cookies or security fields.
LimitRequestFieldSize 200
Note that as the attack evolves in the field you are likely to have
to further limit this and/or impose other LimitRequestFields limits.
See: http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize
3) Use mod_headers to completely dis-allow the use of Range headers:
RequestHeader unset Range
Note that this may break certain clients - such as those used for
e-Readers and progressive/http-streaming video.
4) Deploy a Range header count module as a temporary stopgap measure:
http://people.apache.org/~dirkx/mod_rangecnt.c
Precompiled binaries for some platforms are available at:
http://people.apache.org/~dirkx/BINARIES.txt
5) Apply any of the current patches under discussion - such as:
http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3ccaapsnn2po-d-c4nqt_tes2rrwizr7urefhtkpwbc1b+k1dq...@mail.gmail.com%3e
Actions:
However there are several immediate options to mitigate this issue until
that time.
1) Use SetEnvIf or mod_rewrite to detect a large number of ranges and then
either ignore the Range: header or reject the request.
Option 1: (Apache 2.0 and 2.2)
# drop Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
# optional logging.
CustomLog logs/range-CVE-2011-3192.log common env=bad-range
Option 2: (Also for Apache 1.3)
# Reject request when more than 5 ranges in the Range: header.
# CVE-2011-3192
#
RewriteEngine on
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
RewriteRule .* - [F]
The number 5 is arbitrary. Several 10's should not be an issue and may be
required for sites which for example serve PDFs to very high end eReaders
or use things such complex http based video streaming.
2) Limit the size of the request field to a few hundred bytes. Note that
while
this keeps the offending Range header short - it may break other headers;
such as sizeable cookies or security fields.
LimitRequestFieldSize 200
Note that as the attack evolves in the field you are likely to have
to further limit this and/or impose other
