Hi Thijs, Thanks a lot for a rapid feedback. So, now I know who is a member of security team I guess ;-)
> * Propagated fix for asctime pattern from 0.7.8 release (closes:
> #421848) I do not see the security implications of this bug.
indeed -- it is not of direct security issue. It is just that first 10
days of the month fail2ban would fail to detect "failed" lines in the
logs, thus would not perform up to its duty. If someone relies on
fail2ban to prevent any kind of attack (such as DoS, dictionary,
etc) against his servers, effectively it would lead to DoS
possibility as if fail2ban wasn't in use at all. And that is what
original submitted had as an opinion. Since the fix is really minimal I
thought it would be worth including it. But if you insist I can remove
this one, but it is really minimal
> * Propagated fix for not closed log files from 0.7.8-1
> (closes: #439962,434368)
> Surely a critical bug, but does it have security implications?
> * Propagated fix for "reload" bug which is as sever as #439962 and just
> never was hit by any Debian user yet
> It's unclear to me what issue this is exactly.
Sorry for cryptic description and I must confess that I can't recall
100% clearly what it was about although I provided initial fix. I
believe it had the same implication that fail2ban would stall on reload
command.
So, both issues lead to a similar, serious and imho security
related bug: fail2ban would stall on reload, and fail2ban reload is
called by logrotate which is in turn is called by cron. What we have at
the end - is the system which if not taken care about might have
disabled cron activity, which might have scheduled some health/security
monitoring such as tiger, cfengine, etc. That might have all kinds of
implications including making the system vulnerable to specific kinds of
attacks. I even not mentioning that fail2ban would not perform as
promised thus opening posibilities to attacks.
> * Rigid call to python2.4 instead of via /usr/bin/env to prevent
> in-the-middle attack via environment poisoning
> Is this theoretical or is it a realistic scenario? Can you give an example?
;-) indeed this is more of a theoretical issue. It is only to prevent
cases when some user who has sudo access (thus propagating env variables
into the shell) and has some custom link in his PATH for python (due to
various reasons, from specifics of his job to religion of using jpython
or smth like that) and he runs fail2ban restart. It would start fail2ban
using his custom python. But indeed this scenario is very unprobable and
I do not feel strong about keeping it. The patch is minimalistic though as
well ;-)
> So concluding, this update seems to mix security and non-security issues, and
> that is not acceptable to us. For an update through security.debian.org you
> need to make a version that only includes real security fixes.
Please let me know if you change your judgment on the issues I've
discussed. I will remove the ones which remain out of security scope
> Other critical fixes can be sent for review to the stable release managers at
> [EMAIL PROTECTED]
--
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
pgpbJb3WTPNuv.pgp
Description: PGP signature
