Bug 11569 - fail2ban new security issues CVE-2013-7176 and CVE-2013-7177
: fail2ban new security issues CVE-2013-7176 and CVE-2013-7177
Status: RESOLVED FIXED
Product: Mageia
Classification: Unclassified
Component: Security
: 4
: All Linux
: Normal Severity: major
: ---
Assigned To: QA Team
: Sec team
: http://lwn.net/Vulnerabilities/590195/
: MGA3TOO has_procedure advisory mga3-3...
: Triaged, validated_update
:
: 10617
  Show dependency treegraph
 
Reported: 2013-10-31 06:33 CET by Daniel Black
Modified: 2014-04-16 16:22 CEST (History)
4 users (show)

See Also:
Source RPM: fail2ban
CVE:
Status comment:


Attachments

Description Daniel Black 2013-10-31 06:33:49 CET
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:

https://github.com/fail2ban/fail2ban/releases/tag/0.8.11.pre1

Cheers,

Your friendly fail2ban dev,

Daniel

Reproducible: 

Steps to Reproduce:
Comment 1 Manuel Hiebel 2013-11-01 16:40:10 CET
we are in version freeze so if you have great arguments for release manager (and if maintainer is ok with that)
Comment 2 Daniel Black 2013-11-12 22:37:27 CET
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:

https://github.com/fail2ban/fail2ban/releases/tag/0.8.11
Comment 3 Daniel Black 2014-01-21 22:31:12 CET
0.8.12 released:

https://github.com/fail2ban/fail2ban/releases/tag/0.8.12
Comment 4 David Walser 2014-03-10 16:49:14 CET
OpenSuSE has issued an advisory on March 8:
http://lists.opensuse.org/opensuse-updates/2014-03/msg00021.html

They updated it to 0.8.12, which they said fixes two new security issues.
Comment 5 Remco Rijnders 2014-03-20 13:28:26 CET
Will work on this coming weekend.
Comment 6 Daniel Black 2014-03-20 22:11:20 CET
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.
Comment 7 Remco Rijnders 2014-03-21 08:09:33 CET
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).
Comment 8 Remco Rijnders 2014-03-23 17:31:46 CET
(In reply to David Walser from comment #4)
> OpenSuSE has issued an advisory on March 8:
> http://lists.opensuse.org/opensuse-updates/2014-03/msg00021.html
> 
> 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.
Comment 9 David Walser 2014-03-23 18:06:53 CET
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.
Comment 10 Daniel Black 2014-03-23 21:17:16 CET
> I read it to say that 0.8.11 closes the security issues,

Yes.

> 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.
Comment 11 Daniel Black 2014-03-23 23:57:28 CET
exact differences in versions:

https://github.com/fail2ban/fail2ban/compare/0.8.11...0.8.13

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.
Comment 12 David Walser 2014-04-08 22:11:06 CEST
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.
Comment 13 Remco Rijnders 2014-04-09 07:46:43 CEST
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).

References:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-7176
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-7177
https://bugs.mageia.org/show_bug.cgi?id=11569
=====================

Source RPM's:
3/core
fail2ban-0.8.13-1.mga3

4/core
fail2ban-0.8.13-1.mga4
Comment 14 David Walser 2014-04-09 14:29:35 CEST
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:
https://github.com/fail2ban/fail2ban/releases
http://lists.opensuse.org/opensuse-updates/2014-03/msg00021.html
Comment 15 claire robinson 2014-04-10 08:41:09 CEST
Is the test suite run during build Remco? It seems to be removed from the package.
Comment 16 claire robinson 2014-04-10 11:59:22 CEST
Testing complete mga3 32 & 64 and mga4 32 & 64

Bug 10617 is stil valid for incorrect log paths in jail.conf.

Procedure:
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)..

[ssh-iptables]

enabled  = false
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
           sendmail-whois[name=SSH, dest=you@example.com, 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.
Comment 17 claire robinson 2014-04-10 15:37:30 CEST
I asked Remco to leave a comment here this morning. He intends to look at the incorrect paths later today.
Comment 18 Remco Rijnders 2014-04-10 18:52:45 CEST
(In reply to claire robinson from comment #15)
> Is the test suite run during build Remco? It seems to be removed from the
> package.

Good point, and one I'll take into account for future changes to this package.

Short answer:
No, it isn't.

Longer answer:
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

FAILED (failures=1)

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?
Comment 19 David Walser 2014-04-10 18:56:45 CEST
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.
Comment 20 David Walser 2014-04-10 18:59:13 CEST
(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.
Comment 21 claire robinson 2014-04-16 13:52:26 CEST
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
Comment 22 claire robinson 2014-04-16 14:21:31 CEST
Testing complete mga3 64 & mga4 32
Comment 23 claire robinson 2014-04-16 14:41:23 CEST
Advisory uploaded. Validating.

Could sysadmin please push to 3 & 4 updates

Thanks
Comment 24 Colin Guthrie 2014-04-16 15:19:23 CEST
Update Pushed: http://advisories.mageia.org/MGASA-2014-0176.html
Comment 25 Remco Rijnders 2014-04-16 15:53:11 CEST
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
Comment 26 claire robinson 2014-04-16 16:22:07 CEST
That makes sense Remco, thanks for clarifying.

Note You need to log in before you can comment on or make changes to this bug.