There is a bug in Apache 2.0.x that can cause the whole machine to run out of memory (RAM & swap) under certain circumstances. The discussion on the Apache mailing list is here: http://tinyurl.com/7rpzt (there are 8 messages in the thread). To summarize: 1) Server owner running Apache 2.0.x sets up a CGI script to transfer a file. The script (lets call it http://example.com/download.cgi) can be as simple as a program that reads a file from the hard drive and outputs it in 1K chunks. 2) User requests http://example.com/download.cgi using a download accelerator that splits a download into multiple requests to speed up the download. 3) Apache bug in handling byterange requests causes the apache2 processes to use up an arbitrary amount of RAM, very likely exhausting all RAM and swap space on the server. Note that the amount of memory used can be far greater than the actual size of the file being download. This only happens when a download accelerator is used (which makes the byterange requests) and a CGI program is used on the server side to handle the file transfer. I'll attach a patch which solves the problem by not allowing byterange requests under those circumstances. Once applied, a download accelerator would only be able to make a single request for the file. (Byterange requests are still allowed when the file is downloaded directly, without a CGI script involved - in which case the download accelerator can still split the request into multiple requests without impacting the server's memory usage). This patch is known to work with net-www/apache-2.0.54-r13 .
Created attachment 66245 [details, diff] Patch to fix byterange bug for Apache 2.0.x
I should point out that this is Joe Orton's patch for the byterange problem, fixed in Apache 2.1.5, and backported into the patch file I uploaded so it will work with Apache 2.0.x . See http://issues.apache.org/bugzilla/show_bug.cgi?id=29962 for the bug and http://svn.apache.org/viewcvs?rev=188797&view=rev for Joe's patch to Apache 2.1.5
security, can this be considered a vulnerability (like DoS)?
I tend to say yes, apache-bugs please advise.
If not a vulnerability, definetly something that should be fixed. It seems valid to me (and in fact I may be experiencing the same issues on my server, I just haven't gotten around to figuring out what exactly is the issue there). I'll take another look at this tomorrow evening when I am more awake and have more time.
New ebuilds commited Stable/old-style: apache-2.0.54-r9 Unstable/new-style: apache-2.0.54-r14 Here's hoping this is the last security bump before new-style becomes stable (aiming for 11-Sept-2005), as there are several ebuilds in the tree that expect <-r10 to be old-style and >=-r10 to be new-style and they will all have to be changed with another bump to old-style.
Dear arches, please test+stable apache-2.0.54-r9 - thanks.
Stable on ppc and hppa.
looks good, marked stable on sparc.
You finally get our shiny keyword ! Marked alpha Cheers, Ferdy
stable on ppc64
Marked Stable on AMD64.
Ok, pretty much ready for GLSA.
We should confirm it's considered as a vulnerability first. Security, please vote on this.
I would vote YES, it doesnt sound that obscure to me. Even a non-skilled attacker could identify a vulnerable script and effectively take the machine out, no skill would be required to trigger it.
I tend to vote YES also.
2 said yes, i would be the third, re-requesting GLSA.
GLSA 200508-15 mips please remember to mark stable to benifit from GLSA.
Stable on mips.
This is CAN-2005-2728.
