Here at LWN, we get a chance to see a fair number of security advisories in
the course of a week—sometimes even in just a single day—so we tend to
notice the quality, or lack thereof, of these important announcements.
There are a few important pieces of information that need to be a
part of any security update announcement, but sadly sometimes they aren't
included. Overall, the quality of advisories seems to be declining, which
is something that we would like to see change. While it clearly would make
collecting security advisories easier for us, that is not the primary
motivation for this look at security reporting—users are not being
well-served by the current state of affairs.
Distributions need to remember that the audience for their security
announcements is their users. Those users require some basic information
to make an informed choice about whether they need to apply the update as
well as how urgently. In order to make those decisions, the following
should be present in advisories:
- the package affected
- the problem that is being fixed
- the impact of the vulnerability
- some kind of unique identifier for the alert
- links to relevant additional information (CVE,
- where and how to update the package
- consistent formatting of advisories is a definite plus
Users are not as familiar with either the package or the distribution as
the person writing the alert is, so it should be written with that in
mind. The most important thing is to concisely communicate the severity
and urgency of the problem in a way that the reader can
understand—and figure out what to do about it.
The biggest problem seen with alerts of late is a lack of information about
the problem they are fixing. As an example, consider the recent Fedora advisory on kvm. It
refers to a recent CVE number (CVE-2008-4539)
which is "reserved", but no details are present, and says that it fixes a
"cirrus vulnerability". It also references a bugzilla
entry that apparently addresses a separate CVE from 2007 (CVE-2007-1320),
if you follow that link in
the bugzilla, you finally end up somewhere with actual information, though
the connection between the two problems is not particularly obvious.
Another example of this is CentOS advisories, which suffer from a number of
problems, but the most vexing for folks trying to determine whether they
need to update is this lack of bug information. It is not all that hard to
get the information as a typical
alert has a link to the appropriate Red Hat advisory, but why make
users take that step? A concise summary of the bug(s), as well as a
reference to the—generally very complete—Red Hat errata, would
be quite useful. There is certainly nothing wrong with linking to sources
of additional information, but the basics of the problem and its impact
should be available in the alert.
Unique identifiers for advisories are useful for a number of reasons:
keeping track of which have been addressed, having a unique search string to
use, or referring to them in conversations, bug reports, etc. When the
identifier is not unique, it muddies the waters a bit, making it more
difficult than it needs to be. Sometimes mistakes are made (like the spate
of recent Fedora alerts with the same FEDORA-2008-10000 identifier), but
there appear to be distribution policies about using identifiers multiple times.
CentOS uses the same identifier on multiple advisories, one per
architecture, but also shared between CentOS releases. So the same
identifier will be applied to an s390 update for CentOS 4 as is applied to
x86_64 for CentOS 5.
Another identifier reuse problem comes from Fedora. When mozilla (or more
recently xulrunner) library vulnerabilities occur, Fedora pro-actively
rebuilds and updates all of the packages that depend on those libraries.
This is very much to its credit as the API is not (yet) stable, but all of
the resulting alerts refer to the same identifier. For those who try to
track vulnerabilities along with alerts, that results in messy listings that don't
provide much in the way of helpful information. Other library bugs result
in much saner listings where
one could relatively easily track down—and keep straight—the
advisories for various packages.
There are others problems as well. Alerts that combine unrelated
fixes do "avoid flooding mailing lists", but they are a bit painful to
tease apart for users that are tracking specific packages. Too much
history, in the form of changelogs (example) can also be confusing.
If there is only a link to provide vulnerability information, as is the
CentOS way, it
should probably go directly to a page about the flaw, not to some page that
lists all recent upstream flaws (example). And on and on.
Certain distributions have been singled out here, but that is not really
the point. These are just recent examples of problems that are regularly
seen in distribution security alerts. It should be noted that the
commercial distributions (SUSE, Ubuntu, Red Hat, Mandriva) seem to do a
much better job overall, which is not surprising, but sometimes they fail
as well. The key thing to remember is that security announcements are
meant to be read by users and acted upon. If information is lacking, the
communication will fail.
This is not the first time we have looked at the problem, way back in 2000
security page editor Liz Coolbaugh took a look at security
advisories, and had some of the same complaints seen here. Her
conclusion is still valid: it is not that distributions are not trying or
that they don't care, but at times the contents of their advisories slip
below the radar. After her article, things got better with security
alerts, hopefully this gentle prodding will have a similar effect.
to post comments)