Re: Update of security-critical outdated packages
Arrrrgh!
I had written down a lengthy reply, and just before sending it, a fuse
blew and took my machine down with it. Why don't we get PSUs with
built-in UPSes that last a minute or so, enough to change the fuse or
take a clean shutdown...? Probably because most PCs run an OS that goes
down so often, an occasional fuse is just one-in-many... Oh well...:
On Thursday 15 January 2004 19:51, Rich Puhek wrote:
> Kjetil Kjernsmo wrote:
> > Again, that's not how I read DSA-297.
>
> They advise using newer versions of snort because it recognizes newer
> attacks. Any security holes in snort will continue to be patched. In
> other words, if someone discovered today that woody's snort version
> has a buffer overflow, you can bet that snort will be updated in
> security within a few days.
Yes, of course. But it is completely irrelevant to my point.
> The key difference here is in the use of the term "security issues".
> The security release is used to patch holes in a server. The version
> of snort in stable has no "security issues" in the sense that
> installing it does not open you up to attack.
But you'd never know if you were attacked, would you...? :-)
YMMV, but using an old NIDS is a security issue by my standards... I
mean, why are you running a NIDS in the first place? If your system is
so rock hard nobody can break in, you don't need it, unless you install
it just for the laughs of looking at script kiddies getting spanked by
your countermeasures... :-) That's not why I run a NIDS...
> On a general production server, no. Now think about why: you might
> have to upgrade lots of dependancies, you might get stuck with
> incompletely tested software, it's more difficult to maintain
> security updates. Those are also the arguements used for not
> arbitrarily upgrading packages in stable!
Exactly! But that's why I addressed this argument in my initial post,
re-read it.
> You may find that upgrading to unstable (or a hibrid of unstable
> packages) is just about ideal for something like an IDS or an
> antispam server. Machines like that tend to need bleeding-edge
> software, so almost by definition, they end up runing unstable.
Yup, sure, if I could, I'd have that. But I have neither the hosting
capacity nor the hardware to do that. I have to settle for a single
system for all these things, and I'm sure I'm not alone.
> > Yep, but it is still besides the point: Really good reason for
> > keeping outdated packages in the archive (ok, you provided one
> > above)?
>
> Is the arguement that "old" packages like snort should be removed
> altogether, or that "packages I really find important" should be
> upgraded more aggressively?
No no. Neither, of course.
I have not advocated the complete removal of a package. I have just
asked the question, what is the point of having a package that you
shouldn't use in the archive? There are many things you can do, for
example replace it with a well-tested update, or yes, you could remove
it, or something entirely different...
> should SpamAssassin be
> upgraded because I don't want to receive spam that's been catchable
> for a year?
I've addressed exactly the case of SA in my initial post. It is a
completely different matter. SA must be kept up-to-date, indeed, but
there are no security issues with using the old package.
> Should PHP be upgraded because I want to be able to serve
> pages that have been written in a language version supported for the
> last year (like $_FILES['userfile']['error'] ). Should perl be
> upgraded because it's a very important language?
No, no, no. Again, this is something I addressed in my initial post, but
I'll answer to hopefully clear up some misunderstandings: These
packages are usuable, and there are no security issues with using them
(probably to the contrary). If you want the latest and greatest, you
can always do a backport or use somebody elses backport, but you may
have to suffer some instability. But nobody is going to tell you
shouldn't use old versions PHP or Perl, because they still do the job
they were designed to do when they were released.
A NIDS, OTOH, was designed to report known attacks when it was released,
and it doesn't do that job anymore, because many more attacks are
known. In the worst case, it could result in a successful and
not-easy-to-see breakin into your system, that an updated NIDS would
trivially catch.
These two things are very, very, very different.
So, let us get back to this question:
> Also, how do we decide what's
> important enought to be upgraded immediately?
Well, it is not easy to formulate, but the intent with my post is to
initiate some discussion on the point. Let me try a starting point:
If a package that harden* depends on (or even recommends) is so outdated
the security team finds that it must recommend that users install a
backport, then that backport should be included in the next point
release.
> > Big difference: If the WM is a bit unstable, or it has a bit weird
> > performance at times, I don't care. It's the cost of running
> > unstable software. But if the NIDS fails to recognize an attack
> > that's been known for two years, it is pretty serious.
>
> It sounded like your main objection to backports was that someone
> could trojan a package on an unofficial backport site.
It is part of the equation, yes.
The main objection is the other way around, however, what's the point of
having an outdated package in stable, when using it just gives users a
false sense of security? There is absolutely nothing to gain by having
it there. There are issues with replacing it, but I'm arguing, the
gains are probably greater than the problems.
> My point
> wasn't stability, the question is, if you download a trojaned
> backport of KDE, how is that less of an issue than downloading a
> trojaned backport of snort? Either way, your system is trojaned.
> Plus, a trojaned version of a popular WM would probably have a more
> severe impact than a trojaned IDS, just based on the number of
> infected machines (I'm assuming that more prople run KDE than run
> snort, just a guess on my part).
>
> If you are able to trust a backport site, then what's the problem
> with using it for secuity related packages?
OK, good point.
For one thing, many users may not use backports at all unless explicitly
instructed to do so. It is a rather great leap to go from no sources
out of Debian to one. This may be changing with the availability of
apt-get.org, etc, I guess.
But I say I am in the position that I'm in the position where I have the
WOT to verify the signature on the backports I use, but not the
signature on the backport recommended by the security team. Clearly, it
makes the situation different.
But the question remains: Why should I be compelled to use a backport
site at all? And when security team first do recommend a backport, the
backport is trivial, why not just test it well and put it in the
archive, replacing the outdated package?
> How does the end use of the package change the debate over things
> like: *) how to limit the impact of dependancies
That was Tom's argument too. It is a good one, but the point is that if
the backport is trivial, then there should be no problem with
dependencies. In the case of a non-trivial backport, we have a lot more
serious problem, and one that can not be addressed, I would guess.
However, I would presume that most backports (of relevant packages) are
trivial, like they have been to the present.
> *) how to avoid breaking other installed programs
Well, again, if you really shouldn't use it anyway, what's the point?
You'd need to deal with it anyway.
> *) how to support critical security updates while putting newer
> versions in stable
Well, since it is probably just 1 in 1000 packages that would ever fall
under consideration, it shouldn't be so much of an issue, should it?
But I know, the security team has a lot to do, so perhaps it is. It
could be worth it, though, if it makes the stable platform more secure.
> *) how to limit the need to unexpectedly reconfigure a package in
> stable (apt-get update; apt-get upgrade should just *work* on stable,
> if you suddenly have to stop and redo a config file because it
> supports a few 100 new options... that's not too cool).
Nope! :-) But so what? You'd have to deal with it anyway. Remember, I'm
talking about situations where the security team has advised you to
upgrade. If you don't do it, you'd have a insufficiently hardened
system. It may be painful, yes, but there's no other way.
>
> I think the concept got covered fairly well the last time you brought
> it up (Nov, 2003).
No, not really. Tom was the only one who understood my argument, we
continued offline untill he also found that he couldn't explain it
well.
> The issue of snort, specifically, recieved quite a bit of discussion
> about a year ago:
>
> http://lists.debian.org/debian-security/2002/debian-security-200212/m
>sg00063.html
OK, thanks, relevant thread.
Basically the summary there is that the best way to do it is to
(automatically) build source packages from unstable from snort.
Which only serves to reinforce my point:
What point is there to have an old, outdated package in stable when you
really shouldn't use it?
I haven't advocated the complete removal, but Noah L. Meyerhans thinks
that it shouldn't be in Debian at all, and perhaps he has a point
there. He thinks Debian does disservice by having it there, and the
argument seems reasonable.
Matt advocates that you only should build it from sources, and what I'm
suggesting is sort of a middle ground: If the security team advices
people to use a backport, that backport should be included in the next
point release.
> > Basically, I just like to hear your thoughts, because I really
> > haven't found any good answers.
>
> As with any issue this complicated, there's probably no "best"
> answer. The consensus over past issues of updating software has been
> that you're on your own with having to do one of pining, outright
> upgrading to testing|unstable, using a backported .deb, doing apt-get
> source and building the package (and all deps), or getting the source
> and rolling your own.
Yeah... OK. Well, my point boils down to that there is no point of
having an outdated package in the archive when it is deprecated by the
security team, and I suggest adding a well-tested backport package at
point releases.
> I think it usually ends up being people like myself who do most of
> the arguing on the topic. If I was a decent programmer, I'd just shut
> up and try to close RC bugs :-)
Hehe, AOL.... :-) But then, argument is also a way of progress too...
Best,
Kjetil
--
Kjetil Kjernsmo
Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer
kjetil@kjernsmo.net webmaster@skepsis.no editor@learn-orienteering.org
Homepage: http://www.kjetil.kjernsmo.net/ OpenPGP KeyID: 6A6A0BBC
Reply to: