Distribution advisories

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, bugzilla, ...)
• where and how to update the package
• consistent formatting of advisories is a definite plus

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.

Comments (3 posted)

A "Grey Hat" guide for security researchers

Comments (21 posted)

cups: denial of service

Comments (none posted)

dovecot: access restriction bypass

Comments (none posted)

gvim: multiple vulnerabilities

Comments (none posted)

hf: arbitrary code execution

int main(int argc, char *argv[])
{
        // snip
        while ((c = getopt(argc, argv, "a:M:c:klhip:m:nt:s:r:Rf23")) != -1)
            switch (c) {

            // snip

                case 'k':
                    system ("killall hfkernel");

            //
}

Comments (none posted)

imlib2: buffer overflow

Comments (none posted)

imp: cross-site scripting

Comments (none posted)

kernel: multiple vulnerabilities

Comments (none posted)

libcdaudio: buffer overflow

Comments (none posted)

mozilla: denial of service

Comments (none posted)

nagios: authorization bypass

Comments (none posted)

openoffice.org: insecure temp files

Comments (none posted)

pidgin: multiple vulnerabilities

Comments (none posted)

tog-pegasus: authentication issues

Comments (none posted)

vim: heap-based overflow

Comments (none posted)

vim: sanitization flaws

Comments (none posted)

webkit: arbitrary code execution

Comments (none posted)

yast2-backup: code injection

Comments (none posted)