Live data from Hacker News

Apache vulnerable to easy DOS attack - workaround available

mail-archives.apache.org

11–20 of 23 posts

Re: Apache vulnerable to easy DOS attack - workaround available

#11
post #8
post #6

For sites that don't serve large files, option #4, disabling the range header, is the simplest option. Note that this means that downloads are not resumable, which can easily annoy site users even if there is no multimedia involved. You only need to specify one range in the header in this case, but to do that you need option #1.

I guess you could just allow ONE range which seems like a good compromise and defeat the attack? RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,1}$|^$) RewriteRule .* - [F] (for those that don't speak regex: the 0,1 allows either one or none range headers to be accepted, more or less will fail to be served anything) That will allow downloads to still resume and it works in any version of apache.

If you want to limit to one then ? is simpler. Doesn't that version limit to 1+0-1 -> 1-2 though? But why bother with a complex anchored regex when you can just search for "," in the range header.

Re: Apache vulnerable to easy DOS attack - workaround available

#12
post #2

Of all the workarounds, this is probably the best option because it will still allow ranges to function. Option 1: (Apache 2.0 and 2.2) # Drop the 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 th…

Additional info : Changing this slightly to drop range header when more than 10 ranges (i:e the 5 on the third line becomes a 10 instead ), can avoid problems where serving of large pdfs get broken by this fix.

Re: Apache vulnerable to easy DOS attack - workaround available

#13
post #8
post #6

For sites that don't serve large files, option #4, disabling the range header, is the simplest option. Note that this means that downloads are not resumable, which can easily annoy site users even if there is no multimedia involved. You only need to specify one range in the header in this case, but to do that you need option #1.

I guess you could just allow ONE range which seems like a good compromise and defeat the attack? RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,1}$|^$) RewriteRule .* - [F] (for those that don't speak regex: the 0,1 allows either one or none range headers to be accepted, more or less will fail to be served anything) That will allow downloads to still resume and it works in any version of apache.

Or just Apache's Option 1 as in your post above?

Re: Apache vulnerable to easy DOS attack - workaround available

#15
post #14

I created a little mini site that lets you check if your server is vulnerable, along with some information about the exploit: http://apache-range-exploit.com/

   created Thu, 25 Aug 2011 14:32:30 UTC
Wow, that's nice and clean for a morning project (and thanks!)

Re: Apache vulnerable to easy DOS attack - workaround available

#16
post #15
post #14

I created a little mini site that lets you check if your server is vulnerable, along with some information about the exploit: http://apache-range-exploit.com/

created Thu, 25 Aug 2011 14:32:30 UTC Wow, that's nice and clean for a morning project (and thanks!)

Nice use of Twitter's Bootstrap: http://twitter.github.com/bootstrap/

I've used it for a recent one-off project and it's great and meant for that kind of things: good looking pages even if they were thrown together quickly.

Re: Apache vulnerable to easy DOS attack - workaround available

#17
post #2

Of all the workarounds, this is probably the best option because it will still allow ranges to function. Option 1: (Apache 2.0 and 2.2) # Drop the 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 th…

I've been testing this fix today on Apache 2.0.53 and observed that when running the attack script against a server patched with option 1 (minus the optional logging) there was still a significant hike in CPU usage, perhaps because there is a cost in processing the header analysis.

Option 2 produced no such hike, and protected the server from attack.

Re: Apache vulnerable to easy DOS attack - workaround available

#18
post #14

I created a little mini site that lets you check if your server is vulnerable, along with some information about the exploit: http://apache-range-exploit.com/

Just a quick note from the advisory site

"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."

Not sure if that's how you are checking for vulnerability, however it was reporting that my site was "not vulnerable" when it was very much so.

Re: Apache vulnerable to easy DOS attack - workaround available

#19
post #7
post #3

Earlier quoted context omitted.

Making sure ranges work is especially important if you're serving up streaming video.

Also for download resuming if I remember correctly.

Yes, but very few people are using browsers / download clients that will actually resume downloads, and in many cases sites don't support it for files anyway. However with video it's absolutely expected behaviour.

Re: Apache vulnerable to easy DOS attack - workaround available

#20
post #19
post #7

Earlier quoted context omitted.

Also for download resuming if I remember correctly.

Yes, but very few people are using browsers / download clients that will actually resume downloads, and in many cases sites don't support it for files anyway. However with video it's absolutely expected behaviour.

Both firefox and chrome will resume downloads if they're paused.
Post reply on HN