Denial of service through log injection in fail2ban

0.8.0-2 is still affected. either upcomming -3 or 0.8.1 should fix the
problem

On Thu, 21 Jun 2007, Chris Fryer wrote:

> ** Description changed:

> Binary package hint: fail2ban

> According to CVE 2006-6302
> (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-6302) fail2ban 0.6.1 and
> below is vulnerable to log injection techniques, which can lead to the
> wrong IP address being banned. This can result in denial of service.

> Ubuntu 6.06 (Dapper) uses fail2ban-0.6.0-3.deb
> - Ubuntu 6.10 (Edgy) uses 0.6.1-8.deb
> + Ubuntu 6.10 (Edgy) uses fail2ban-0.6.1-8.deb

> Both are still vulnerable.

> There is a very similar vulnerability reported here:

> http://www.ossec.net/en/attacking-loganalysis.html#fail2ban

> However, I am unsure whether this is specific to fail2ban version 0.8
--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
        101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik

This particular bug doesn't affect Feisty or Gutsy, but you'll probably want to create a separate bug for the new vulnerability.

Yaroslav, your comment toward the end of the debian bug report says that this is fixed in debian prior to 0.6, but here you say it is still vulnerable. Since ubuntu uses debian source packages, I am confused by your statements. Can you clarify?

I never said 'prior to 0.6'. I said that it is fixed in etch version
which is 0.7.5-2, where failregex looks like

failregex = (?:(?:Authentication failure|Failed [-/\w+]+) for(?: [iI](?:llegal|nvalid) user)?|[Ii](?:llegal|nvalid) user|ROOT LOGIN REFUSED) .*(?: from|FROM) <HOST>

which is different from the reported in the bugreport against ubuntu package

So please clarify what actual failregex in what versions of fail2ban
shipped with ubuntu you have... and if they are different to corresponding ones
in debian.

On Wed, 12 Dec 2007, Jamie Strandboge wrote:

> Yaroslav, your comment toward the end of the debian bug report says that
> this is fixed in debian prior to 0.6, but here you say it is still
> vulnerable. Since ubuntu uses debian source packages, I am confused by
> your statements. Can you clarify?

> ** Changed in: fail2ban (Ubuntu Edgy)
> Status: Confirmed => Incomplete

> ** Changed in: fail2ban (Ubuntu Dapper)
> Status: Confirmed => Incomplete
--
Yaroslav Halchenko
     Ph.D. Student CS Dept. NJIT

checked the 0.7.6-3 -- indeed it had the bug....
but it was fixed later on so debian package is not shipped with it any
longer ;-)

On Wed, 12 Dec 2007, Yaroslav Halchenko wrote:

> I never said 'prior to 0.6'. I said that it is fixed in etch version
> which is 0.7.5-2, where failregex looks like

> failregex = (?:(?:Authentication failure|Failed [-/\w+]+) for(?: [iI](?:llegal|nvalid) user)?|[Ii](?:llegal|nvalid) user|ROOT LOGIN REFUSED) .*(?: from|FROM) <HOST>

> which is different from the reported in the bugreport against ubuntu package

> So please clarify what actual failregex in what versions of fail2ban
> shipped with ubuntu you have... and if they are different to corresponding ones
> in debian.

> On Wed, 12 Dec 2007, Jamie Strandboge wrote:

> > Yaroslav, your comment toward the end of the debian bug report says that
> > this is fixed in debian prior to 0.6, but here you say it is still
> > vulnerable. Since ubuntu uses debian source packages, I am confused by
> > your statements. Can you clarify?

> > ** Changed in: fail2ban (Ubuntu Edgy)
> > Status: Confirmed => Incomplete

> > ** Changed in: fail2ban (Ubuntu Dapper)
> > Status: Confirmed => Incomplete
--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
        101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik

This is the relevant line from /etc/fail2ban.conf when fail2ban 0.6.0-3 is installed on Ubuntu 6.06 LTS (Dapper).

failregex = : (?:(?:Authentication failure|Failed [-/\w+]+) for(?: [iI](?:llegal|nvalid) user)?|[Ii](?:llegal|nvalid) user) .* from (?:::f{4,6}:)?(?P<host>\S*)

This seems to allow any non-whitespace characters after <host>, which I believe is the nature of the vulnerability described in CVE-2006-6302. Please correct me if I'm wrong.

> This seems to allow any non-whitespace characters after <host>, which I
> believe is the nature of the vulnerability described in CVE-2006-6302.
> Please correct me if I'm wrong.
being not anchored at the end of the string is the real reason for such
vulnerability imho

--
Yaroslav Halchenko
     Ph.D. Student CS Dept. NJIT

Yaroslav, this is a quote from you in the Debian report:
"This issue had been fixed in debian long ago see bug 330827 I think"

debian/changelog for the ubuntu package contains:
fail2ban (0.5.4-5) unstable; urgency=low

  * Made failregex'es more specific to don't allow usernames to be used as a
    tool for denial of service attacks. Config files (or at least
    failregex'es) must be updated from this package, otherwise the security
    breach would remain open and only warning gets issued (closes: #330827)

Therefore, I wasn't sure whether it was fixed or not. Here are the versions we have, with the regex:

Dapper (0.6.0-3) has :
failregex = (?:(?:Authentication failure|Failed [-/\w+]+) for(?: [iI](?:llegal|nvalid) user)?|[Ii](?:llegal|nvalid) user|ROOT LOGIN REFUSED) .*(?: from|FROM) <HOST>

Edgy (0.6.1-8) has:
failregex = : (?:(?:Authentication failure|Failed [-/\w+]+) for(?: [iI](?:llegal|nvalid) user)?|[Ii](?:llegal|nvalid) user|ROOT LOGIN REFUSED) .*(?: from|FROM) (?:::f{4,6}:)?(?P<host>\S*)

Feisty (0.7.6-3ubuntu1):
failregex = (?:Authentication failure|Failed [-/\w+]+) for(?: [iI](?:llegal|nvalid))? user .*(?: from|FROM) <HOST>
            ROOT LOGIN REFUSED .* FROM <HOST>
            [iI](?:llegal|nvalid) user .* from <HOST>

Gutsy is 0.8.1-1 and Hardy 0.8.1-3.

Dapper, Edgy, Gutsy, and Hardy are the debian packages of the same version. Feisty is 0.7.6-3, with a small change to debian/rules.

Sorry, I didn't give the complete regexes, only the ROOT LOGIN REFUSED part.

Anyway, since these are the Debian package versions, do you know if they are indeed affected? Simply put, Ubuntu did not make any changes to failregex, so are these versions of the Debian packages affected?

and actually since .* is greedy, vulnerability is not there actually...
could you test on example?

On Wed, 12 Dec 2007, Chris Fryer wrote:

> This is the relevant line from /etc/fail2ban.conf when fail2ban 0.6.0-3
> is installed on Ubuntu 6.06 LTS (Dapper).

> failregex = : (?:(?:Authentication failure|Failed [-/\w+]+) for(?:
> [iI](?:llegal|nvalid) user)?|[Ii](?:llegal|nvalid) user) .* from
> (?:::f{4,6}:)?(?P<host>\S*)

> This seems to allow any non-whitespace characters after <host>, which I
> believe is the nature of the vulnerability described in CVE-2006-6302.
> Please correct me if I'm wrong.
--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
        101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik

ok ... a bit more details... that elderly bug fixed in debian's
0.5-whatever is only about disallowing hostaddress appearing anywhere in
the logline. It per se doesn't fix recent vulnerability (see
http://www.ossec.net/en/attacking-loganalysis.html) for more details

for that one 0.8.1 upstream release got the fix (and may be I did patch
it a bit earlier in debian releases). Lets now give a try to ubuntu's
failregexes:

Dapper (0.6.0-3) has :
failregex = (?:(?:Authentication failure|Failed [-/\w+]+) for(?: [iI](?:llegal|nvalid) user)?|[Ii](?:llegal|nvalid) user|ROOT LOGIN
REFUSED) .*(?: from|FROM) <HOST>

*$> fail2ban-regex "Jun 4 14:49:46 slacker sshd[4153]: Bad protocol version identification 'ROOT LOGIN REFUSED hi FROM 1.5.6.7 ' from 10.1.1.14" "(?:(?:Authentication failure|Failed [-/\w+]+) for(?: [iI](?:llegal|nvalid) user)?|[Ii](?:llegal|nvalid) user|ROOT LOGIN REFUSED) .*(?: from|FROM) <HOST>" | grep -A2 "Addresses found"
Addresses found:
[1]
    10.1.1.14 (Mon Jun 04 14:49:46 2007)

so we are good since .* absorbs "1.5.6.7 ' from" leading to correct <HOST> determination

Edgy (0.6.1-8) has:
failregex = : (?:(?:Authentication failure|Failed [-/\w+]+) for(?: [iI](?:llegal|nvalid) user)?|[Ii](?:llegal|nvalid) user|ROOT LOGIN
REFUSED) .*(?: from|FROM) (?:::f{4,6}:)?(?P<host>\S*)

*$> fail2ban-regex "Jun 4 14:49:46 slacker sshd[4153]: Bad protocol version identification 'ROOT LOGIN REFUSED hi FROM 1.5.6.7 ' from 10.1.1.14" ": (?:(?:Authentication failure|Failed [-/\w+]+) for(?: [iI](?:llegal|nvalid) user)?|[Ii](?:llegal|nvalid) user|ROOT LOGIN REFUSED) .*(?: from|FROM) (?:::f{4,6}:)?(?P<host>\S*)" | grep -A2 "Addresses found"

empty output, which is again desired behavior since we are not to catch "Bad protocol..." lines here, but if intruder adjusts its line to include that ": "

fail2ban-regex "Jun 4 14:49:46 slacker sshd[4153]: Bad protocol version identification ': ROOT LOGIN REFUSED hi FROM 1.5.6.7 ' from 10.1.1.14" ": (?:(?:Authentication failure|Failed [-/\w+]+) for(?: [iI](?:llegal|nvalid) user)?|[Ii](?:llegal|nvalid) user|ROOT LOGIN REFUSED) .*(?: from|FROM) (?:::f{4,6}:)?(?P<host>\S*)" | grep -A2 "Addresses found"
Addresses found:
[1]
    10.1.1.14 (Mon Jun 04 14:49:46 2007)

so it is somewhat not good but at least we are banning correct IP.

ok - lets see etch'vs version (0.7.5-2)

$> fail2ban-regex "Jun 4 14:49:46 slacker sshd[4153]: Bad protocol version identification ': ROOT LOGIN REFUSED hi FROM 1.5.6.7 ' from 10.1.1.14" config/filter.d/sshd.conf | grep -A4 "Addresses found"
Addresses found:
[1]
    10.1.1.14 (Mon Jun 04 14:49:46 2007)

we are somewhat good -- since we reacted to wrong line (which is bad) but
detected correct IP.

next one -- 0.7.6-3:

(git)~.m/deb/gits/fail2ban:[tags/debian/0.7.6-3]
*$> fail2ban-regex "Jun 4 14:49:46 slacker sshd[4153]: Bad protocol version identification ': ROOT LOGIN REFUSED hi FROM 1.5.6.7 ' from 10.1.1.14" config/filter.d/sshd.conf | grep -A4 "Addresses found"
Addresses found:
[1]
[2]
    1.5.6.7 (Mon Jun 04 14:49:46 2007)
[3]

oops -- bad bad bad ;-) vulnerable.... Due to the fact I think that ROOT LOGIN ... pattern is on a separate line now and they are matched in turn and it matches...

Ubuntu Edgy Eft is no longer supported, so a SRU will not be issued for this release. Marking Edgy as Won't Fix.