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]

Date: Wed, 24 Aug 2011 08:30:29 +1000
From: "-= Glowing Sex =-" <doomxd@...il.com>
To: Levente Peres <sheridan@...sz.org>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Apache Killer

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


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/
>

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/