full-disclosure - Re: Apache Killer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCvwp79rdX4X7Z9DW3aO06nmVoUgdOKVtpy1g_aEVR7f8_GZg@mail.gmail.com>
Date: Wed, 24 Aug 2011 08:54:53 +1000
From: "-= Glowing Sex =-" <doomxd@...il.com>
To: nix@...roxylists.com
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Apache Killer

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@...roxylists.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@...sz.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@...itz-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/
>
>
>

Content of type "text/html" skipped

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