Bugzilla Bug 157166

remote unauthenticated attackers can add arbitrary hosts to the block list of
systems using fail2ban.

using something like 
$ ssh "foo from 123.123.123.123"@localhost

As they point out in their faq, local users can also block arbitrary hosts.

tavis, has upstream been notified and is there a fix available?

Hi Tavis and Matthias,

I'm the author of Fail2ban and a Gentoo user too ;)

For 0.6.x, the Debian package contains a fix for this. The problem is that it
will break user configuration. I decided not to add this patch for this reason.

For 0.7.x, no releases are normally affected by this issue. If they are, then
it is "only" a configuration issue.

Concerning the local exploit, it is not really an issue in Fail2ban. It is not
possible to know if the log came from a real daemon or a malicious user. A
solution would be to change the permissions on /dev/log.

A solution would be to stabilize the 0.7.2 ebuild and then remove the 0.6.x

I'm with C

I'm with Cédric.

Arches please test and mark stable. Target keywords are:

fail2ban-0.7.2.ebuild:KEYWORDS="amd64 hppa x86"

And now actually with arches CC'ed:-)

Looks like fail2ban-0.7.2 can't be succesfully restarted:

root@daria /home/ticho # /etc/init.d/fail2ban restart
 * Starting fail2ban ...                                                       
  [ ok ]
root@daria /home/ticho # /etc/init.d/fail2ban restart
 * Stopping fail2ban ...                                                       
  [ ok ]
 * Starting fail2ban ...
 * Failed to start fail2ban                                                    
  [ !! ]
root@daria /home/ticho # /etc/init.d/fail2ban restart
 * Starting fail2ban ...                                                       
  [ ok ]
root@daria /home/ticho # /etc/init.d/fail2ban restart
 * Stopping fail2ban ...                                                       
  [ ok ]
 * Starting fail2ban ...
 * Failed to start fail2ban                                                    
  [ !! ]
root@daria /home/ticho # 

Tried manually:

root@daria /home/ticho # fail2ban-client start
WARNING No 'maxtime' defined in 'postfix-tcpwrapper'
WARNING No 'maxtime' defined in 'ssh-iptables-report'
WARNING No 'maxtime' defined in 'ssh-tcpwrapper'
WARNING No 'maxtime' defined in 'vsftpd-notification'
WARNING No 'maxtime' defined in 'ssh-iptables'
2006-12-10 10:46:25,969 fail2ban.server : INFO   Starting Fail2ban
root@daria /home/ticho # echo $?
0
root@daria /home/ticho # fail2ban-client stop 
Shutdown successful
root@daria /home/ticho # echo $?
0
root@daria /home/ticho # fail2ban-client start
WARNING No 'maxtime' defined in 'postfix-tcpwrapper'
WARNING No 'maxtime' defined in 'ssh-iptables-report'
WARNING No 'maxtime' defined in 'ssh-tcpwrapper'
WARNING No 'maxtime' defined in 'vsftpd-notification'
WARNING No 'maxtime' defined in 'ssh-iptables'
ERROR  Could not start server. Try -x option
root@daria /home/ticho # 2006-12-10 10:46:38,763 fail2ban.server : INFO  
Starting Fail2ban
root@daria /home/ticho # echo $?
255
root@daria /home/ticho # 


The error above was printed immediately, the command returned to shell, and
after a moment, the "INFO Starting Fail2ban" message appeared. The
"fail2ban-client start" command returned 255, though.

This might be worth looking into.

Back to ebuild status awaiting a fixed ebuild.

OK, I have tried 0.7.5, which behaves the same on restart via initscript.

I removed "&> /dev/null" parts from both start() and stop(), and here's what I
found out:

root@daria /usr/gentoo/portage/net-analyzer/fail2ban # /etc/init.d/fail2ban
restart
 * Starting fail2ban ...
2006-12-10 11:13:55,314 fail2ban.server : INFO   Starting Fail2ban             
  [ ok ]
root@daria /usr/gentoo/portage/net-analyzer/fail2ban # /etc/init.d/fail2ban
restart
 * Stopping fail2ban ...
Shutdown successful                                                            
  [ ok ]
 * Starting fail2ban ...
ERROR  Server already running
 * Failed to start fail2ban                                                    
  [ !! ]
root@daria /usr/gentoo/portage/net-analyzer/fail2ban #

Looks like "fail2ban-client stop" is returning too soon, when the server is
still running. This is confirmed by manually stopping and starting fail2ban
quickly:

root@daria /usr/gentoo/portage/net-analyzer/fail2ban # fail2ban-client stop &&
fail2ban-client start
Shutdown successful
ERROR  Server already running
root@daria /usr/gentoo/portage/net-analyzer/fail2ban # 

Hi all,

Sorry I should have added myself to CC :(

I have just released 0.6.2 which fixes the issue. Old configuration files will
still work but will generate a warning. A named group "host" is now required.
This group should match the host address in the log line. Please look at the
provided configuration files.

The init script problem has been reported by RedHat users too. Restart need to
wait a bit that server shutdowns. I will look into this as soon as possible.

I consider odd version numbers (0.3, 0.5, 0.7) as development releases. Even
number (0.4, 0.6, upcoming 0.8) are stable releases. Please, if possible, only
stabilize these releases. I will always try to do my best to provide fixes for
security issues for these "stable" releases.

0.6.2 (renamed 0.6.1-r1 ebuild) seems to work.

As this is a security bug, I took the liberty of committing 0.6.2 to the tree,
with x86 keyword stable. I hope netmon won't mind. :)

Security, cue archteams! :)

Thx Andrej, however the 0.6.x series is only safe with the Debian patch
according to comment #2.

(In reply to comment #13)
> Thx Andrej, however the 0.6.x series is only safe with the Debian patch
> according to comment #2.
> 

In comment #11, Cyril says that 0.6.2 has this issue fixed, so I went from
there. I can not reproduce the vulnerability with 0.6.2, which bans correct IP,
instead of bogus one, as in 0.6.0.

Woops sorry Andrej.

Arches please test and mark stable. Target keywords are:

fail2ban-0.6.2.ebuild:KEYWORDS="amd64 hppa ~ppc ~ppc64 x86"

Stable for HPPA.

Sorry, this is not really the good place to talk about this but as this was
reveal in this bug, I post it here.

I (hopefully) fixed the init script for the "restart" issue. Inspired by the
squid init script.

https://svn.sourceforge.net/svnroot/fail2ban/trunk/files/gentoo-initd

Could you test it? Is this the right way to do this? Any suggestions?

Thank you

(In reply to comment #11)
> Hi all,
> 
> Sorry I should have added myself to CC :(
> 
> I have just released 0.6.2 which fixes the issue. Old configuration files will
> still work but will generate a warning. A named group "host" is now required.
> This group should match the host address in the log line. Please look at the
> provided configuration files.
> 
> The init script problem has been reported by RedHat users too. Restart need to
> wait a bit that server shutdowns. I will look into this as soon as possible.
> 
> I consider odd version numbers (0.3, 0.5, 0.7) as development releases. Even
> number (0.4, 0.6, upcoming 0.8) are stable releases. Please, if possible, only
> stabilize these releases. I will always try to do my best to provide fixes for
> security issues for these "stable" releases.
> 


Hallo,

I have emerged the latest in portage fail2ban (0.6.2) with its original
configuration file. However, I cannot find the relevant information that has to
do with the following error message: 

WARNING: No 'host' group defined. This is a security issue. Please fix your
configuration file and look at CVE-2006-6302


I do not clearly understand the way that I can cure this error message. 

From what it is said in this thread I cannot figure out what is the "host
address in the log line" that should be matched by the defined 'host' group and
how this group can actually be defined. I expected to find some information in
the configuration files that I did not manage to spot successfully. 


Kind regards,
orange_juice

amd64 stable

time to glsa-vote.

We issued a GLSA for denyhosts, so i would say Yes here.

i'm actually the only active member of the security team, so i can't apply the
policy telling that 2 positive votes include a GLSA. 

Let's have one btw :)

GLSA 200702-05

I have the same problem. Also have no clue what does it mean by host group and
how to cure this message.

@Fox, please open a new bug instead if the problem persists.