Mageia Bugzilla – Bug 11569
fail2ban new security issues CVE-2013-7176 and CVE-2013-7177
Last modified: 2014-04-16 16:22:07 CEST
Failban devs have make a pre-release available predominately aimed at package maintainers to test everything.
If you'd like to test this out too we'd encourage feedback on github.com/fail2ban/fail2ban/issues.
A full 0.8.11 release will be out in 1-2 weeks incorporating any feedback received.
All the changes and tarballs/rpms/srpms etc:
Your friendly fail2ban dev,
Steps to Reproduce:
we are in version freeze so if you have great arguments for release manager (and if maintainer is ok with that)
Arguments for getting beyond a version freeze (if its not too late and as a former distro maintainer I know how painful these are):
mainly from pre-release notices:
In light of CVE-2013-2178 that triggered our last release we have put a significant effort into tightening all of the regexs of our filters to avoid another similar vulnerability. We haven't examined [previous filters] for a potential DoS scenario however it is possible that another DoS vulnerability exists that is fixed by this release.
A large number of filters have been updated to include more failure regexs supporting previously unbanned failures and support newer application versions too.
(e.g. Support modern versions of apache-2.4, asterisk and openssh-6.3)
Final 0.8.11 release:
OpenSuSE has issued an advisory on March 8:
They updated it to 0.8.12, which they said fixes two new security issues.
Will work on this coming weekend.
fyi fail2ban-0.8.13 and 0.9.0 are also released https://github.com/fail2ban/fail2ban/releases. There's a few bugs discovered post release with 0.9.0 so we may do another release in a week.
Daniel, do you think it is worth waiting with this update for the new release? (I am mainly thinking here about the version shipped with Mageia 3 and 4, as I don't want to burden our QA-team more than is necessary).
(In reply to David Walser from comment #4)
> OpenSuSE has issued an advisory on March 8:
> They updated it to 0.8.12, which they said fixes two new security issues.
David, I read it to say that 0.8.11 closes the security issues, and that 0.8.12 provides additional bugfixes (of the non security kind).
I can go to either 11 or 12, but the changes in 12 seem more extensive than we normally do for updates to our releases.
It's not real clear whether the issues were fixed in 11 or 12, and 12 and 13 are supposed to be bugfixes. Given that OpenSuSE updated it to what was the newest at the time, it's not clear to me why we wouldn't just follow suit.
> I read it to say that 0.8.11 closes the security issues,
> and that 0.8.12 provides additional bugfixes (of the non security kind).
Though there are some that say when we've got a filter that doesn't comprehensively cover the authentication failures of an application its a security bug.
> It's not real clear whether the issues were fixed in 11 or 12, and 12 and 13 are supposed to be bugfixes
Fixes where done in 11. 12 and 13 where bug fixes and improvements to other filters. The 0.9.0 is changing some large internal aspects so probably leave this for Cauldron.
If you're going for 0.8.13 there have been a couple of breaks in python <2.5 compatibility that have been fixed in that branch. Most other upstream bug fixes are for the 0.9.0 branch.
exact differences in versions:
As you can see most are filter improvements backed up by log samples. Other improvements are error handling around the parsing of configuration files and in some of the actions.
Optional features ignorecommand and flushlogs where added.
I'm happy to answer questions related to any code changes that you think make cause distribution incompatibility.
Remmy has packaged 0.8.13 for Mageia 3 and Mageia 4, but not updated Cauldron yet. I'm guessing he's waiting for 0.9.1.
fail2ban doesn't have any subpackages, so once Cauldron is fixed, the update candidates will be fail2ban-0.8.13-1.mga3 and fail2ban-0.8.13-1.mga4.
QA, please test 0.8.13 which is waiting for you in updates-testing. Please ensure that the package still works and can recognise brute force login attempts on any of the monitored services. (For example, a failed ssh login attempt for >3 times).
Recommended advisory (taken partly from OpenSUSE):
An update to fail2ban 0.8.13 has been released to fix security issues, amongst other bugfixes.
fail2ban versions prior to 0.8.11 would allow a remote unauthenticated attacker
to cause arbitrary IP addresses to be blocked by Fail2ban causing legitimate users to be blocked from accessing services protected by Fail2ban. These services are cyrus-imap (CVE-2013-7177) and postfix (CVE-2013-7176).
This still hasn't been fixed in Cauldron. I don't usually assign to QA until it is. Remmy, even if you're working on 0.9.x or something, would you mind submitting the same update you did for mga3/mga4 to Cauldron in the meantime?
We can add a couple more links to the references:
Is the test suite run during build Remco? It seems to be removed from the package.
Testing complete mga3 32 & 64 and mga4 32 & 64
Bug 10617 is stil valid for incorrect log paths in jail.conf.
Checked with ssh and ssh-iptables filter.
After installing fail2ban and starting rsyslog service so the relevant log files are created, edit /etc/fail2ban/jail.conf and find this bit (not the commented example at the top)..
enabled = false
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
sendmail-whois[name=SSH, firstname.lastname@example.org, sender=fail2ban@examp$
logpath = /var/log/auth.log
Change the enabled to true and then start fail2ban service.
Attempt ssh login using a false username (eg. ssh bert@fail2banhost) and notice it hang after a few attempts. Check the journal on the fail2ban host and notice it has blocked connections from the host attempting to login.
Stop the fail2ban service to return things to normal.
I asked Remco to leave a comment here this morning. He intends to look at the incorrect paths later today.
(In reply to claire robinson from comment #15)
> Is the test suite run during build Remco? It seems to be removed from the
Good point, and one I'll take into account for future changes to this package.
No, it isn't.
I have just run it myself, and it failed on one test having to do with its own configuration:
FAIL: testConfigurator (testcases.clientreadertestcase.JailsReaderTest)
Traceback (most recent call last):
File "/home/remmy/rpmbuild/BUILD/fail2ban-0.8.13/testcases/clientreadertestcase.py", line 348, in testConfigurator
['set', 'logtarget', '/var/log/fail2ban.log']])
AssertionError: Lists differ: [['set', 'loglevel', 3], ['set... != [['set', 'loglevel', 3], ['set...
First differing element 1:
['set', 'logtarget', 'SYSLOG']
['set', 'logtarget', '/var/log/fail2ban.log']
- [['set', 'loglevel', 3], ['set', 'logtarget', 'SYSLOG']]
+ [['set', 'loglevel', 3], ['set', 'logtarget', '/var/log/fail2ban.log']]
Ran 195 tests in 109.468s
The package ships with a patch changing the log location, but appearantly without updating the test for it (further indication the testsuit has never been part of the regular packaging process).
Do you think it would be of use to ship the test program in the rpm?
Remmy has uploaded fail2ban-0.8.13-2.mga5 for Cauldron, so this is now fixed there. Thanks Remmy!
Also he has updated the update candidates for Mageia 3 and Mageia 4 to fail2ban-0.8.13-2.mga3 and fail2ban-0.8.13-2.mga4 to fix the Apache error log paths (Bug 10617), so this will need fresh testing.
(In reply to Remco Rijnders from comment #18)
> Do you think it would be of use to ship the test program in the rpm?
I would say not really, but if the build-time test suite could be made to work successfully, enabling that would be good. It would help give more confidence that updates like this one don't cause regressions.
The apache log path is now..
logpath = /var/log/httpd/*error_log
So it is now correct, it might be better as error_log* but let's get this one validated.
Testing complete mga3 32 & mga4 64
Testing complete mga3 64 & mga4 32
Advisory uploaded. Validating.
Could sysadmin please push to 3 & 4 updates
Update Pushed: http://advisories.mageia.org/MGASA-2014-0176.html
Thanks Daniel, David, for your help.
Thanks Claire for testing!
(In reply to claire robinson from comment #21)
> The apache log path is now..
> logpath = /var/log/httpd/*error_log
> So it is now correct, it might be better as error_log* but let's get this
> one validated.
I assume you say error_log* would be better so it also catches error_log.1 etc. But fail2ban only has to watch the active log to decide what to ban and what not. The *error_log is that also people having multiple domains can have logs like domain1.error_log and domain2.error_log
That makes sense Remco, thanks for clarifying.