From secunia security advisor at $URL:
The vulnerability is caused due to an error within the processing of malformed HTTP requests in mod_proxy_ajp when being used in combination with mod_proxy_balancer. This can be exploited to put a backend server into an error state by sending specially crafted HTTP requests, resulting in a temporary DoS until the retry timeout expires.
The vulnerability is reported in versions 2.2.20.
Update to version 2.2.21.
New version is in tree. Arch teams, please, test and stabilize.
amd64: emerges fine, basic usage ok.
I wasn't able to check whether fix works or not, I used mod with tomcat and when I ran pyloris against it, apache stalled - slowloris attack was succesfull.
Maybe I've misconfigured something though, I am not familiar with apache.
note: app-admin/apache-tools-2.2.21 needs stabilisation as well.
ok on my box / runs on hardened server also amd64
all emerges ok
Archtested on x86: Emerges fine, tested some rdeps and started it with a very basic config. I'm no apache expert so this is as far as i go. Everything ok.
x86 stable, thanks JD.
+ 16 Sep 2011; Tony Vroon <firstname.lastname@example.org> apache-tools-2.2.21.ebuild:
+ Marked stable as a dependency of www-servers/apache-2.2.21 based on arch
+ testing by Tomáš "Mepho" Pružina, Agostino "ago" Sarubbo, Ian "idella4"
+ Delaney & Elijah "Armageddon" El Lazkani in bug #382971.
+ 16 Sep 2011; Tony Vroon <email@example.com> apache-2.2.21.ebuild:
+ Marked stable on AMD64 based on arch testing by Tomáš "Mepho" Pružina,
+ Agostino "ago" Sarubbo, Ian "idella4" Delaney & Elijah "Armageddon" El
+ Lazkani in bug #382971.
Standards are slipping again.
Arch teams, please test and mark stable:
Target KEYWORDS="alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86"
Stable for HPPA.
ppc/ppc64 stable, last arch done
Thans, everyone. Added to existing GLSA request.
The mod_proxy_ajp module in the Apache HTTP Server before 2.2.21, when used
with mod_proxy_balancer in certain configurations, allows remote attackers
to cause a denial of service (temporary "error state" in the backend server)
via a malformed HTTP request.
This issue was resolved and addressed in
GLSA 201206-25 at http://security.gentoo.org/glsa/glsa-201206-25.xml
by GLSA coordinator Tobias Heinlein (keytoaster).