Comment 11 for bug 121374

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 only capitalized FROM, so .* doesn't absorb it.

Current version in debian (0.8.1-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"
emtpy output (good) -- it is due to the fact that failregex is anchored at the end.

So, to summarize: indeed some ubuntu versions are vulnerable to this issue,
revisions in debian are not. Nevetheless -- I tried only 1 exemplar of logline
which might lead to DoS, and I need to confess that under some circumstances it
is still possible (probably) to craft a logline somehow in auth.log from
another service or using not catched lines (such as Bad protocol version) which
would lead to DoS. Cyril (upstream author of fail2ban) already absorbed 1
tentative solution I suggested to this problem which would match the full line
entirely which would disallow easily craft line leading to DoS. That one is in
0.9 devel branch of fail2ban. I am looking at finding some spare moment to
craft another tentative solution which would be more elegant, but it is just in
plans for now.

If you come up with a logged logline which still triggers current version (in
etch or sid) to ban wrong IP - I would be very thankful if you share so I could
provide a fix earlier than later ;-)

Besides that, I am stopping investigation of the "universe" of fail2ban
versions within Ubuntu (it is easy to release every 1/2 year but is it easy to
maintain all those versions properly? that was a rhetoric question -- no
follow up is necessary)

On Wed, 12 Dec 2007, Jamie Strandboge wrote:

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