Thank you guys for your time. Let me drop few comments > > + * Propagated fix for not closed log files from 0.7.8-1 > > + (closes: #439962,434368) > > + * Propagated fix for "reload" bug which is as sever as #439962 and just > > + never was hit by any Debian user yet > > As you said in your other mail, these issues are related to fail2ban > > stalling upon reload. That is a serious bug but not a security issue. Of > > course fail2ban not functioning in itself can be considered as a security > > issue because it's specifically designed to prevent other attacks. However, > > there's no concrete attack possible because of fail2ban failing to ban. > How long have these changes been in unstable/testing? Were there any problems > with it? I'm willing to include them if they are reasonably well tested. 0.7.8 is there since March 2007, and I just want to point again that stalled (malfunctioning) fail2ban in this case might lead to stalled logrotate and cron which impacts the functionality of the whole system. So imho it is a point of a concern. Since the main point is to make sure that this change is 'stable' I want to check for that with additional care -- I want to go through the changes which happened since 0.7.8 and see if anything touched that part (may be indirectly), so I am sure that the patch is complete and provides stable functionality. Most probably everything is alright... I just want to give a 2nd look...
> > + * Added patch 00_numeric_iptables-L to avoid possible DoS attacks
> > + (introduced upstream in 0.7.6)
> > If I understand this correctly, this makes iptables not do DNS lookups.
> > While that's obviously a useful fix, I think it's not a serious security
> > issue. There's lots of services doing one or more DNS lookup when something
> > external connects to them, and skipping that where possible is good, but
> > not something I would add to a security update, I'm sorry. Again, maybe the
> > SRM's are willing to include this.
> Ok, this fix is as I said not very security-related but on the other hand
> trivial. So let's include it.
indeed it is very limited but imho possibly DoS related. iptables
without -n does name resolution for each name found. If there is lots of
names logged, it places a burden on the system to resolve them... if
there are multiple abusers (happens during DoS I guess ;-)) 'attacking'
the server, for each of them to be banned iptables -L is ran... imho it
can lead to DoS (or considerable slowdown) of the system to
resolve the names for "valid" requests, unless some caching DNS server
serves the system a favor to provide quick name resolution.
> > + * Rigid call to python2.4 instead of via /usr/bin/env to prevent
> > + in-the-middle attack via environment poisoning
> > I think this is out of scope for a security update, or even a stable update
> > if you ask me. Please do not include it in the security update at least,
> > and discuss with the stable release team if you want it included in etch
> > still.
> I still think this is not appropriate, sorry.
no problem. I will gladly remove that piece
> Please do so with this revised information :-)
ok doki -- I will just check on that most intrusive patch to assure that
it is the same code/logic as used in current version (ie that
piece was tested appropriately)
> Thijs
Cheers and happy new year to everyone
--
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
pgpcqIX6gAYEw.pgp
Description: PGP signature
