Security response: how are we doing?

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.

---

(Log in to post comments)