tags 461772 - security
tags 461772 + etch
thanks

I really doubt that security team would consider this a security issue
in any dimension... If you has discovered it before I issued etch2
update I could have included this along.

It is not a denial of service at all -- since root is the one who starts
fail2ban he/she has full ability to remove bogus socket file and start
fail2ban properly.

Thus imho it is not a security issue per se, thus I am removing the tag
(I will leave it important just to give it some of a priority). If
you don't agree, some quotation from any Debian document or
email/correspondence with debian security team that states that it is
indeed a security issue -- I will tag it back.

Otherwise I guess, the best I could do is either prepare proposed-update
for fail2ban to include the modifications from sid's version, or to wait
for next security update (which might never come) and include this
modification into it -- what would be your choice?

Cheers

On Sun, 20 Jan 2008, Nico Golde wrote:

> Package: fail2ban
> Version: 0.7.5-2etch1
> Severity: important
> Tags: security

> Hi,
> from sserver.py:
> def initialize(self, sock = "/tmp/fail2ban.sock", force = False):
>         self.__socket = sock
>         # Remove socket
>         if os.path.exists(sock):
>                 logSys.error("Fail2ban seems to be already running")
>                 if force:
>                         logSys.warn("Forcing execution of the server")
>                         os.remove(sock)
>                 else:
>                         raise SSocketErrorException("Server already runn ing")

> local users who want to brute force other system accounts would just
> need to create a file in /tmp/fail2ban.sock to disable fail2ban if it gets 
> re/started
> unless it is called with force.

> On etch there is no check in the init script for this file, in unstable 
> fail2ban
> is called with -x if the file exists and there is also a patch that creates 
> the
> file under /var/run.

> The etch version does not even give an error in such a case, it just needs
> longer to start and then exists with success.

> Unpatched fail2ban sources of course also have this problem.

> This is not a severe thing but still should be fixed.

> Kind regards
> Nico
-- 
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        



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to