Slashdot Mirror
Apache Warns Web Server Admins of DoS Attack Tool
CWmike writes "Developers of the Apache open-source project warned users of the Web server software on Wednesday that a denial-of-service (DoS) tool is circulating that exploits a bug in the program. 'Apache Killer' showed up last Friday in a post to the 'Full Disclosure' security mailing list. The Apache project said it would release a fix for Apache 2.0 and 2.2 in the next 48 hours. All versions in the 1.3 and 2.0 lines are said to be vulnerable to attack. The group no longer supports the older Apache 1.3. 'The attack can be done remotely and with a modest number of requests can cause very significant memory and CPU usage on the server,' Apache said in an advisory. The bug is not new. Michal Zalewski, a security engineer who works for Google, pointed out that he had brought up the DoS exploitability of Apache more than four-and-a-half years ago. In lieu of a fix, Apache offered steps administrators can take to defend their Web servers until a patch is available."
Yes, that's why I use Hiawatha.
Algorithmic complexity attacks (of which this is an example) are nothing new. They have been done on really bad sorting algorithms (quick sort, which is still defended by quite a few people that simply do not get it or are not bright enough to implement the alternatives) and are today employed, e.g., against hash-tables. Libraries/languages by people with a clue (e.g. LUA), have protection against that. Others do not.
Writing secure code is a bit harder than writing merely working code. I guess people have to find that out over and over again....
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
http://www.gossamer-threads.com/lists/apache/dev/401638 -- someone has got a patch. Keep those fast moving script kittens at bay
Imagine the anti-Microsoft shitstorm around here if this was an IIS attack tool.
All versions in the 1.3 and 2.0 lines are said to be vulnerable to attack. The group no longer supports the older Apache 1.3.
Since Slashdot is still stuck in the late '90's with a thin veneer of bad javascript, over apache 1.3 it's vulnerable... and no patch either.
AntiFA: An abbreviation for Anti First Amendment.
Really? Apache has 200+ failed unit tests that are just ignored?
They're not even close to comparable. Apache has served me very well. My server is not even vulnerable to this as I don't have mod_deflate loaded or compiled. (I tested using the kill script.)
Disclaimer: IANAL. This post is, however, legal advice, and creates an attorney-client relationship.
A quick summary: A client can use byte range requests that are overlapping and/or duplicated to use a single small request to overload the server. eg: 0-,0-,0- would request the entire contents of the file three times. YMMV but this has to do with how Apache handles the multipart responses consuming memory and isn't an actual bandwidth DoS.
Unfortunately there are legit reasons for allowing out-of-order ranges and multiple ranges, such as a PDF reader requesting the header, then skipping to the end of the file for the index, then using ranges to request specific pages. Another example was a streaming movie skipping forward by grabbing byte ranges to look for i-frames without downloading the entire file.
So the fix discussion centers on when to ignore a range request, when can you merge ranges, can you re-order them, can you reject overlapping ranges and how much do they need to overlap, etc. The consensus seems to be that first you merge adjacent ranges, then if too many ranges are left OR too many duplicated bytes are requested then the request skips the multi-part handling and just does a straight up 200 OK stream of the whole file or throws back a 416 (can't satisfy multipart request).
Natural != (nontoxic || beneficial)
The link in the blurb claiming to point to the advisory from Apache isn't correct.
The actual advisory from Apache notes that mod_deflate's presence is orthogonal (irrelevant) to the exploitability of this issue.
The correct link:
http://mail-archives.apache.org/mod_mbox/httpd-announce/201108.mbox/%3C20110824161640.122D387DD@minotaur.apache.org%3E
Welcome to 2011, not running CGI scripts is a feature (and a good one at that).
Regardless, my server isn't vulnerable - that's all I care about.
Disclaimer: IANAL. This post is, however, legal advice, and creates an attorney-client relationship.
I read the advisory, chose a course of action, then it took about a minute to make my server not vulnerable. It's great that they made the disclosure.
You can do a quick test with something like this:
If you're vulnerable, you should see a really ridiculously long Content-Length header, like 900k or so.
Disabling mod_deflate or the equivalent prevents this behavior, but it's not clear that there isn't another exploit waiting to happen. A super quick fix is to kill the Range header entirely using mod_header, like so
RequestHeader unset Range
in your apache.conf or moral equivalent. For the most part, you can get away with not serving Range headers, and if you can't, you know it and don't need my advice on fixing this.
using chroot/jails/containers/zones
Not being a Linux guru, I thought I had heard repeatedly "Chroots do NOT provide security"? Cant someone who pulls off a privelege escalation escape the chroot?
What about running CGI scripts on a separate virtual machine from the rest of the system? Basically set up a separate web server on that, and have all CGI scripts be executed from there. For access to shared resources, have a "gate keeper" process (or module in the web server) running on the original host which can give out one-time passwords which are then passed onto the script, and which the script can then use to access the resources through that gate keeper. The gate keeper can have a detailed knowledge about what each script is allowed to access, and block any other request. I'm not sure if this would be feasible performance-wise, but I think it would make quite a secure system. Indeed, the script server could mount all file systems readonly (you could even remove the write capability from the file system driver if you're paranoid enough), because you don't need to change the scripts from within the scripts (installing the scripts would be done from the host system or another virtual machine). That way, even if someone managed to hijack a script, the worst he could do is to mess with those things the specific script is allowed to access (because the gate keeper knows which script was called, and won't allow any other access). Unless the attacker additionally finds a security hole in the gate keeper process, of course. As an additional bonus, the scripts would not need to have the database password (the gate keeper would have it), so even if the script server was completely hacked, the database password would still not leak.
The Tao of math: The numbers you can count are not the real numbers.
I think Apache is just like all the other projects that grow too big ! The jewelry store, welcome to go and have a look .
When I saw the headline, I thought Apache was going to warn retailers about selling HP touchpads...
has anyone noticed if mod_evasive disarms/mitigates this attack vector?
IT Admins Group: Where you decide the content
And people call Apache bloated. Right.
Rudolf Hess edited Mein Kampf. He was the very first grammar nazi.
Cant someone who pulls off a privelege escalation escape the chroot?
Yes, he can. Basically, the trick is to do another chroot to a subdirectory, but without doing the chdir. So now the attacker is in a situation where the current directory is above the root. Here he can keep doing chdir(".."); until he reaches the real root, and then all he needs to do is chroot(".");.
What's worse, this exploit is due to the way how chroot is spec'ed, thus it can't really be fixed by the kernel.
So yes, you can escape a chroot jail if you've got root. However, the point of the chroot jail is to prevent attackers from gaining root in the first place, by confining them to a minimal and more controllable environment which has no spare crowbars lying around.
Moreover, other confinements, such as BSD jails, containers or zones may not have the problem outlined above.
Exploit code and ways of testing the vulnerability seem to be addressed towards HTTP. Has anyone tested it against HTTPS yet?
With the bug first reported over 4.5 years ago, this was entirely avoidable.
http://seclists.org/bugtraq/2007/Jan/83
FY, Options -indexes on /var/www made my boxes safe against this attack.
Lets not forget that being a proper admin and having Apache locked down by, for example, some SELinux policies... it's kind of a tough nut to break.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Comment removed based on user account deletion
A proper SELinux (or AppArmor, I'd imagine) policy would also serve to confine them in their box.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Since we're discussing Apache anyway... I've used Apache for over a decade now. Right now I'm working on a Pyramid app and publishing it with mod_wsgi on Apache 2.2, for no other reason than that I'm already familiar with Apache. Since this is a brand new project and will be running on its own dedicated server - and therefore doesn't have play nicely with any pre-existing web apps - I wanted to re-evaluate my decision. If you needed to publish a WSGI app today, what server would you use and why?
Dewey, what part of this looks like authorities should be involved?
Do not reply to the AC trolls, please.
Although, your comment was quite damn funny.
So...
...
"... and said it would release a fix for Apache 2.0 and 2.2 in the next 48 hours."
"... According to Apache, all versions in the 1.3 and 2.0 lines are vulnerable to attack."
So dropping support for 1.3 I understand (EOL etc), but fixing 2.2 event though it isn't reported as vulnerable? which is it?
Web servers run without root privileges so that the server isn't capable of doing overtly harmful things but you can still modify things that the web server is supposed to modify. That is, it can still mess it up.
If you want to give scripts a separately isolated area, you can use this: http://httpd.apache.org/docs/2.0/suexec.html File system permissions takes over from here.
I don't know too much about SQL servers, but couldn't you probably use kerberos or something instead of directly using database passwords?
I am glad they finally got to it, but if apache had told their bank that there was an issue with their account , I am sure they would have wanted their bank to do something right away about it, and not 4.5 years ago....you just have to hit them where it hurts...ddos their banks, not their servers.....
Or, OpenVZ containers.
I know tobacco is bad for you, so I smoke weed with crack.