This problem should be fixed in fail2ban-0.8.8-6.1.mga3 and fail2ban-0.8.6-3.2.mga2, both available in their respective updates_testing repositories.

Only people using fail2ban to monitor their apache log files are potentially affected by this DoS-possibility.

More information on this vulnerability, including an explanation and the fix applied, can be found at https://vndh.net/note:fail2ban-089-denial-service

CC: (none) => remco
Hardware: i586 => All
Assignee: remco => qa-bugs

Remco I notice this is set to Cauldron, has Cauldron been updated now?

If it has I'll alter the bug. We can't push updates unless Cauldron has been done first.

Hi Claire,

I pushed version 0.8.10 to Cauldron this morning, which has this fix applied in it already. Thanks!

Thanks

Version: Cauldron => 3
Whiteboard: MGA3TOO, MGA2TOO => MGA2TOO

Could you list rpms please aswell as the srpms above. Testing is full of kde at the moment so it's almost impossible for us to guess them.

Also, is there a CVE for this now? Could you give an advisory please. Luigi12 is busy with $dayjob so be nice if we can lighten the load a little for him.

Advisory:
======================
Updated fail2ban package fix DoS-vulnerability

Krzysztof Katowicz-Kowalewski discovered a vulnerability in Fail2ban, a log monitoring and system which can act on attack by preventing hosts to connect to specified services using the local firewall.

When using Fail2ban to monitor Apache logs, improper input validation in log parsing could enable a remote attacker to trigger an IP ban on arbitrary addresses, thus causing a denial of service (CVE-2013-2178)

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2178
http://www.debian.org/security/2013/dsa-2708
https://vndh.net/note:fail2ban-089-denial-service
======================

Updated packages in core/updates_testing:
======================
fail2ban-0.8.6-3.2.mga2
fail2ban-0.8.8-6.1.mga3

SRPMS:
======================
fail2ban-0.8.6-3.2.mga2
fail2ban-0.8.8-6.1.mga3

Thanks Remco!

Just adjusting some minor formatting things with the advisory, but thanks for doing that.  Just so you know what I changed below, we usually limit the width to approx. 78 characters, I usually put the other distro advisory last in the references, and the SRPM names get a .src.rpm at the end.

Advisory:
========================

Updated fail2ban package fixes security vulnerability:

Krzysztof Katowicz-Kowalewski discovered a vulnerability in Fail2ban, a log
monitoring and system which can act on attack by preventing hosts to connect
to specified services using the local firewall.

When using Fail2ban to monitor Apache logs, improper input validation in log
parsing could enable a remote attacker to trigger an IP ban on arbitrary
addresses, thus causing a denial of service (CVE-2013-2178).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2178
https://vndh.net/note:fail2ban-089-denial-service
http://www.debian.org/security/2013/dsa-2708
========================

Updated packages in core/updates_testing:
========================
fail2ban-0.8.6-3.2.mga2
fail2ban-0.8.8-6.1.mga3

from SRPMS:
fail2ban-0.8.6-3.2.mga2.src.rpm
fail2ban-0.8.8-6.1.mga3.src.rpm

Remotely exploitable DOS so raising priority

Severity: normal => critical

RedHat has rated as "moderate," so following suit.

Severity: critical => major

Some issues with default config Remco, i'll create a new bug for it though. Mainly paths in /etc/fail2ban/jail.conf and also default actions using sendmail.

Checking the 'Affected Files' list here https://vndh.net/note:fail2ban-089-denial-service found in /etc/fail2ban/ the shipped regex's are the same (text match without any positional checks).

Confirmed after update that they now use ^%(_apache_error_client)s which is now defined in filter.d/apache-common.conf

Added the jails as below and started the server.

[apache-auth]

enabled  = true
filter   = apache-auth
action   = shorewall
logpath  = /var/log/httpd/error_log

[apache-noscript]

enabled  = true
filter   = apache-noscript
action   = shorewall
logpath  = /var/log/httpd/error_log

[apache-overflows]

enabled  = true
filter   = apache-overflows
action   = shorewall    
logpath  = /var/log/httpd/error_log

[apache-nohome]

enabled  = true
filter   = apache-nohome  
action   = shorewall
logpath  = /var/log/httpd/error_log

Confirmed the affected jails loaded OK with 
# systemctl status fail2ban.service

Tested by manually sending lines to the log file and confirming no action.

# echo '[Sat Jun 25 14:36:42 2013] [error] [client 192.168.33.1] File does not exist: /srv/http/site/[client 192.168.0.1] user root not found' >> /var/log/httpd/error_log

Whiteboard: MGA2TOO => MGA2TOO has_procedure mga3-64-ok

bug 10617 created for the default config issues

Testing complete mga3 32

Tested successfully with ssh-iptables jail. Used incorrect password to log in to ssh several times and was blocked.

Whiteboard: MGA2TOO has_procedure mga3-64-ok => MGA2TOO has_procedure mga3-64-ok mga3-32-ok

testing complete mga2 32 & 64

Validating. Advisory in comment 7 uploaded.

Could sysadmin please push from 2 & 3 core/updates_testing to core/updates

Thanks!

Keywords: (none) => validated_update
Whiteboard: MGA2TOO has_procedure mga3-64-ok mga3-32-ok => MGA2TOO has_procedure mga3-64-ok mga3-32-ok mga2-32-ok mga2-64-ok
CC: (none) => sysadmin-bugs

http://advisories.mageia.org/MGASA-2013-0192.html

Status: ASSIGNED => RESOLVED
CC: (none) => boklm
Resolution: (none) => FIXED