Full Disclosure mailing list archives

Re: Apache Killer


From: "-= Glowing Sex =-" <doomxd () gmail com>
Date: Wed, 24 Aug 2011 08:54:53 +1000

Yea, i think only way to get around it is to upgrade httpd versions.. I
tried it on freeBSD8.2 standard default settings and httpd devel and that
seems fine, even standard httpd alone on another box, again running 8.2, is
fine.
Some boxes also seem to only consume ram, when it is swap that is the real
killer... it also is not possible to b stopped with apache commands, once
the box starts tipping, you must killall -9 httpd , just to stop the box
from tipping over, this is when the script is execd against it in testing,
we were able to only stop it that way, on a badly affected httpd.
I still wish apache.org would at the least release some form of advisory for
this and help for some people who dislike upgrades :s like bosses with small
pockets ;p
cheers
xd



On 24 August 2011 08:47, <nix () myproxylists com> wrote:

Reagrding this bug,
The release should have also specified a bugfix / workaround, ofcourse
usually this is the case, altho the one i have seen, does not work on all
boxes.
On a BSD 8.0 box, it killed eveything, swap/ram, eveything died/needed
reboot.  now, what is quite annoying, i guess is that i had someone go
thru
my setup, aswell as myself, to check for anything that could trigger it,
we
found the gzip lines, but nothing else for mod_deflate so we went ahead
and
restarted, and bang, dead again... what do we do here ?
Apache has done nothing about this, there is no UN official patching,
this
is nasty... Please, any suggestions for patching this, seriously, it
should
not be that i must have to shutdown a company webserver, incase someone
should attack it.
Regards,
xd


'perl killapache.pl mysite.com 50' said: Host does not seem vulnerable and
it did exited instantly.

Tested it against local linux site using Apache 2.2.19 and the remote site
uses 2.2.17.



On 21 August 2011 01:31, Levente Peres <sheridan () sansz org> wrote:

My findings, hope it helps... Properly configured HAProxy with queue
management and per-server limits can dampen the effects quite
drastically.

In my testing (three low-end SunFire servers and a LB) an attack volume
of well over a 1000 threads was necessary to notice any small speed
degradation on the frontend - which triggeres anti DOS immediately if
done from outside LAN. System immediately recovers fully when the attack
stops, no coredumps, nothing, not even after half an hour of sustained
attack. No crashing or unstability whatsoever happened on any servers,
not even at 2000, but dared not to test further on a live system... If
performed from multiple IPs or varied content etc however, a pattern
recognition scheme would be necessary to block it I believe... Also
tested it with a simple one-server setup with Squid as frontend before
apache, it reported not vulnerable... Not tested any further yet.

Done on a "barefoot" apache however, it was devastating even at 100
threads regardless the lots of RAM and quadcode setup :-(

Levente

2011.08.20. 14:31 keltezéssel, HI-TECH . írta:
Disabling mod_gzip/mod_deflate is a workaround I guess.

2011/8/20 Moritz Naumann<security () moritz-naumann com>:
On 20.08.2011 00:23 HI-TECH . wrote:
(see attachment)
/Kingcope
Works (too) well here. Are there any workarounds other than rate
limiting or detecting + dropping the traffic IPS-wise?

Moritz

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


---
avast! Antivirus: Inbound message clean.
Virus Database (VPS): 110819-1, 2011.08.19
Tested on: 2011.08.20. 14:32:33
avast! - copyright (c) 1988-2011 AVAST Software.
http://www.avast.com





_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/



_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Current thread: