From ${URL} : It was reported [1] that fail2ban improperly parses Apache log files, due to improper regular expressions. This could allow a remote attacker to send a crafted URL to a web site which, when parsed by fail2ban, would deny a specific IP address (not the remote attacker's IP). This was reported against fail2ban 0.8.9, but earlier versions use the same regular expression. This has not yet been addressed upstream; the original report suggests replacement regular expressions, but in my (limited) testing they do not seem to work (testing using fail2ban-regex). [1] https://vndh.net/note:fail2ban-089-denial-service @maintainer(s): after the bump, in case we need to stabilize the package, please say explicitly if it is ready for the stabilization or not.
Arch teams, please test and mark stable: =net-analyzer/fail2ban-0.8.10 Stable KEYWORDS : amd64 hppa ppc ppc64 x86
Stable for HPPA.
amd64 stable
x86 stable
ppc stable
ppc64 stable
GLSA vote: no.
GLSA vote: yes (we have one pending GLSA request for it)
CVE-2013-2178 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-2178): The apache-auth.conf, apache-nohome.conf, apache-noscript.conf, and apache-overflows.conf files in Fail2ban before 0.8.10 do not properly validate log messages, which allows remote attackers to block arbitrary IP addresses via certain messages in a request.
Added to existing GLSA draft
This issue was resolved and addressed in GLSA 201406-03 at http://security.gentoo.org/glsa/glsa-201406-03.xml by GLSA coordinator Chris Reffett (creffett).
