[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Updating scanners and filters in Debian stable (3.1)

This one time, at band camp, Thomas Bushnell BSG said:
> Stephen Gran <sgran@debian.org> writes:
> > I thought that 'issues related to the development of debian' was on topic
> > for this list.  It is not at all clear to me that this is a security
> > issue, because outdated A/V software usually does not place the server
> > it runs on at risk for compromise.  
> We have been told that:
> 1) Outdated A/V software must be upgraded, because the upgrading is
>    critical to the security of the machine that relies on it.

Yes, but see below for the problem.

> 2) If it is not upgraded, then it is better not to have it at all.
> Both of those seem to be true to me of, say:
> A) Outdated ssh binaries must be ugraded, because the upgrading is
>    critical to the security of the machine that relies on them.

An outdated ssh may allow access to the machine that has sshd running
on it.  The same is not true of a machine running clam (in the case of
this particular general discussion - if a compromise was found in clam
itself, that would be grounds for a security upgrade).  Clam protects
(largely windows) clients behind it, and not, generally speaking, the
machine that it runs on.  It does not sound like this is suitable for
the security folks, who are already overworked as it is.

> B) If they are not upgraded, then it is better not to have them at
>    all.

True.  For the class if software I am talking about, though, it is not
so much that the outdated software is a potential avenue of attack in
and of itself, as it is a waste of CPU cycles and a false sense of

> Now in the case of ssh, we have set up a special security archive to
> deal with the case.
> I think (1) is true, and I think both (A) and (B) are true.  I am not
> sure about (2), but I do understand why people are arguing for it.  If
> they are correct, then it seems to me that the security archive is
> already an excellent place for the updates.

I think the difference is that, up to this point, the security archive
has been used for fixing software that had a bug with the potential
to compromise the local machine.  These uploads are (AFAIK) always
accompanied by a DSA, and usually have CAN advisories associated with
them.  The upgrades that I am talking about are a different class of
upgrades, as they generally make no difference to the local machine in
most cases, and there is no need for a DSA, and certainly no CAN advisory
for uploads of this type.

So what we have now is:
1) stable: no new code, no changes so as to be as stable to administer
   as possible.
2) security.d.o: only fixes that have to go in - no API or ABI changes,
   backport only relevant bugfixes to fix possibility of compromise

What I (and it seems, others) would like to see is:
3) some other method to upgrade software that has to change rapidly to
   meet new classes of threats, even though these threats may not affect
   the machine running the software itself.  This category seems to me 
   to be composed of A/V scanners, anti-spam suites, and IDS-type software.  
   I may be missing some, and I'm sure someone will chime in with it.

The problem with not having 3) is that you end up shipping software that
doesn't keep pace with the new threats in the wild.  At work, we have to
keep a rather large private repository of backports towards the end of a
stable release to cope with this, and I'm sure many other places do the
same.  It seems counter productive to have people redo the same work in
many places, instead of doing it right in a single place.
|   ,''`.					     Stephen Gran |
|  : :' :					 sgran@debian.org |
|  `. `'			Debian user, admin, and developer |
|    `-					    http://www.debian.org |

Attachment: pgppduJq5WqHs.pgp
Description: PGP signature

Reply to: