we are in version freeze so if you have great arguments for release manager (and if maintainer is ok with that)

Keywords: (none) => Triaged
Assignee: bugsquad => remco
Summary: fail2ban-0.8.11-pre1 => new version of fail2ban 0.8.11-pre1

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

0.8.12 released:

https://github.com/fail2ban/fail2ban/releases/tag/0.8.12

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.

URL: https://github.com/fail2ban/fail2ban/releases/tag/0.8.11.pre1 => (none)
CC: (none) => luigiwalser
Component: RPM Packages => Security
Summary: new version of fail2ban 0.8.11-pre1 => fail2ban new security issues CVE-2013-7176 and CVE-2013-7177
Whiteboard: (none) => MGA4TOO, MGA3TOO
Severity: enhancement => major

Will work on this coming weekend.

Status: NEW => ASSIGNED

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

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,

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.

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.

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

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

Assignee: remco => qa-bugs

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

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.

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.

Whiteboard: MGA3TOO => MGA3TOO has_procedure mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok

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
> 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?

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

Whiteboard: MGA3TOO has_procedure => MGA3TOO has_procedure mga3-32-ok mga4-64-ok

Testing complete mga3 64 & mga4 32

Whiteboard: MGA3TOO has_procedure mga3-32-ok mga4-64-ok => MGA3TOO has_procedure mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok

Advisory uploaded. Validating.

Could sysadmin please push to 3 & 4 updates

Thanks

Keywords: (none) => validated_update
Whiteboard: MGA3TOO has_procedure mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok => MGA3TOO has_procedure advisory mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok
CC: (none) => sysadmin-bugs

Update Pushed: http://advisories.mageia.org/MGASA-2014-0176.html

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

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.