LWN.net needs you!Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing.
November 16, 2011
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.