priority 438187 normal
thanks

With such follow-up I would like to lower priority to Normal so 0.8.1
gets sucked into testing, so the issue is at least partially resolved
there. I want to leave the bug open as the reminder that more work is
needed.

Also, etch's version remains prone to this issue as well as others
reported. The problem is that patch-picking between 0.7.5-2 (in etch)
and 0.8.1 would not result in a proper fix anyways. I will upload 0.8.1
to backports as soon as it reaches testing. That should resolve major
concern.

I would appreciate other examples of injection (remote) than the one
given in CVE


----- Forwarded message from Yaroslav Halchenko <[EMAIL PROTECTED]> -----

Date: Wed, 15 Aug 2007 15:57:49 -0400
From: Yaroslav Halchenko <[EMAIL PROTECTED]>
To: Stefan Fritsch <[EMAIL PROTECTED]>
Cc: Cyril Jaquier <[EMAIL PROTECTED]>
Subject: Re: CVE-2007-4321: DoS vulnerability in fail2ban

Hi Stefan,

> Can you please check whether this is actually fixed and tell me the 
> result. If you upload a fix, please mention the CVE id in the 
> changelog.

It is partially fixed in 0.8-4. Just partially because

* yet not all filters have anchored by the end of line failregexes. ssh
  filter should be quite safe (unless **), some other filters (e.g.
  apache-auth) might be prone to the injection.

** since we only anchored failregex at the end, if there is any other
daemon which logs some information with user provided data at the end of
the string without any quotation -- we are in problem. For instance this
can be easily done with sudo by any local user:

sudo echo ROOT LOGIN REFUSED hi FROM 1.5.6.7

results in the log line in auth.log
Aug 15 15:52:24 dimholt sudo:      cat : 1 incorrect password attempt ; 
TTY=pts/0 ; PWD=/home/cat ; USER=root ; COMMAND=/bin/echo ROOT LOGIN
REFUSED hi FROM 1.5.6.7
which will trigger fail2ban's action.

There might be some other services which log in the same 'unsafe' way,
and which I simply don't know.

To fix ** it is needed to provide failregex which covers entire log line
(or to say -- line with date/time part stripped) with sensible anchors
at the beginning of the line as well as at the end (as it is as of now).
And we are looking into implementing it in the foreseen future, right
Cyril? :-)

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

----- End forwarded message -----

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

Reply via email to