Hi Thijs,
I believe that our discussion on fail2ban security upload was stalled.
Could you help me to finalize set of changes desired to be in the
security upload?
Thank you in advance
On Wed, 07 Nov 2007, Yaroslav Halchenko wrote:
> 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]
--
.-.
=------------------------------ /v\ ----------------------------=
Keep in touch // \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User ^^-^^ [175555]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
