|
|
Log in / Subscribe / Register

Security response: how are we doing?

LWN.net needs you!

Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing.

By Jonathan Corbet
November 16, 2011
Linux, as a whole, has a pretty good security record. But software has bugs, and some of those are security-related bugs, so there will always be a need for security fixes. When a security problem arises, most of us are entirely dependent on our distributors to package those fixes and push them out; the number of users who can learn about security problems and build their own replacement packages is relatively small. Security response is, thus, an important point to consider when choosing a distribution for a specific task.

The following table looks at a number of vulnerabilities that were disclosed, or which prompted the issuance of advisories, in recent months. In each case, the response time for a set of distributions is listed. Before reading this table, though, it is important to understand how the choices were made and what the implications are. In particular:

  • The distributions considered are CentOS 5, Debian stable ("squeeze"), Fedora 15, openSUSE 11.4, Red Hat Enterprise Linux 5, Scientific Linux 5 and Ubuntu 11.04. The idea was to pick a recent release of each that is likely to have a significant number of users. The choice of RHEL 5 (and variants) could easily be questioned, but it is still likely to be in much heavier use than RHEL 6. Given that CentOS is still not issuing updates for CentOS 6, choosing that distribution would have led to an ugly column for CentOS below.

  • The vulnerabilities were chosen in an entirely non-rigorous way with an eye toward those that might pose a real threat.

In the table below, a numeric entry gives the number of days since the initial disclosure, if known, or (most often) the earliest distribution advisory. An entry of "NV" indicates that the distribution was not vulnerable to the indicated problem and, thus, did not need to issue an update. If the entry reads "none," instead, the distribution is vulnerable but has not yet pushed an update.

Vuln C5 Debian F15 openSUSE RH5 SL5 Ubuntu Notes
apache 16 0 17 3 2 2 3
crypt_blowfish 60 80 7 0 59 59 60 Debian only partially fixed
freetype 5 3 20 none 4 4 none
kdelibs 8 none 16 6 8 8 14 No Fedora advisory sent
kernel 43 0 NV none 42 42 34
krb5 NV NV 29 6 NV NV 0
libpng 66 10 0 30 10 10 8
mod_proxy 42 none none 57 42 42 64
openjdk 1 none 2 10 0 1 none
openssl NV NV 0 40 NV NV NV
pam 0 none 1 367 0 none 210
pam NV 0 NV 9 NV NV 0
php 127 0 81 110 126 126 111
quagga none 7 20 20 none none 46
rpm 0 none 2 31 0 0 none Debian/Ubuntu do package RPM
Xorg 15 none NV none 15 15 27 2010 CVE; F14 still vulnerable

Before launching into conclusions, your editor would like to point out that distributors have made it much easier to obtain this type of information in recent years. In many cases, it is possible to go directly to a distribution-specific page or bug-tracker entry for a given CVE number. For the most part, distributors are quite open about their exposure to specific vulnerabilities; that is exactly how it should be.

Ideally, a table like the above should have no "none" entries at all. There was no distributor without unpatched vulnerabilities, but some clearly have more than others. It is, in particular, sad to see so many missing updates in the Debian column. One could argue that, say, a lack of urgency to fix an rpm vulnerability on Debian's part is understandable, but one could also argue that, if the package is not worth fixing, it probably should not be shipped in the first place. Despite being based on Debian, Ubuntu has a more complete set of updates, but the smallest number of missing updates can be found in the Red Hat and Fedora columns; Red Hat continues to be relatively serious about getting fixes out there.

The best way to deal with a vulnerability, of course, is to not be vulnerable to it in the first place. It is interesting to note that the distributions with the most "not vulnerable" entries are the oldest ones (RHEL, Debian stable) and the newest ones. Distributions based on older software get to miss out on more recently introduced bugs, but they also miss the most recent fixes, some of which unknowingly close security holes. There are limits to the conclusions that can be drawn from such a small sample, but there does appear to be a difficult "middle age" for distributions where they are subject to the largest number of known vulnerabilities.

Finally, we still are clearly not doing well enough. There are too many vulnerabilities in the first place, and too many of them sit unfixed for too long. The security situation is not getting any more friendly or forgiving; we cannot afford to sit back and think that the security problem is even close to being solved. A lot has been accomplished in this area, but quite a bit remains to be done.

Index entries for this article
Security Distribution security


The LWN site is currently under high scraper load, so comment display has been suppressed for anonymous users. If you are a human, you may read the comments by clicking the button below:

Note: you can avoid this step in the future by logging into your LWN account.


Copyright © 2011, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds

AltStyle によって変換されたページ (->オリジナル) /