Stability v. security fixes

A whole pile of security fixes for Red Hat Enterprise Linux 4 (RHEL4) was released at the beginning of May; this event might not be noteworthy except that some of the vulnerabilities were nearly two years old. This stands in contrast to a recent Red Hat article describing the security track record of RHEL4, which was covered on this page, and made no mention of delays of this sort. Digging in a bit deeper to try and understand why seems logical.

Of the thirteen fixes listed by LWN for that day, eleven are categorized as having low severity by Red Hat, one is moderate and one is important. The latter is a recently reported vulnerability in xscreensaver that was given a CVE number less than a month ago. Of the dozen others, eight had CVE numbers from 2006 and four from 2005.

Red Hat classifies security issues based on their analysis of their impact; both "low" and "moderate" vulnerabilities are unlikely to be exploitable, with "moderate" vulnerabilities having worse consequences if it does happen. Under those definitions, it would certainly seem less important to get those fixes out, but it would also seem like a headache to keep track of them. Fedora Core released fixes for these issues ages ago and those seem to have worked out, why did Red Hat sit on them for RHEL4 for so long? Mark Cox, from the Red Hat Security Response Team explains:

So, for low and some moderate impact bugs, RHEL4 users must wait for patches until some other issue with that package requires attention and then await the next batch of fixes as an update release. An intervening update cycle is not necessarily enough to push these fixes out as there have been several update releases to RHEL4 since they were reported. RHEL customers prize stability, and delayed security updates is part of Red Hat's process for delivering that stability.

Security issues (and bugs in general) are funny beasts and sometimes their implications do not become clear for a long time. Something that seems to have a low impact is suddenly used in an unexpected way by a worm or some other exploit and the impact needs to be recalculated. By holding back these fixes for seemingly trivial security issues, Red Hat could be setting itself up for an unpleasant security surprise someday.

Some customers may also feel that they are more at risk for a particular issue than Red Hat thinks they are. Perhaps they use cpio frequently on possibly untrusted data on their 64-bit machines. As things currently stand, they had no fix available to them (at least via the normal Red Hat update means) for more than a year; there was no easy way for them to even know there is a problem. Red Hat tracks these bugs via bugzilla which is open for anyone to use, but they only put out announcements when they release a fix. It is hard to argue that customers should be trolling security lists and/or bugzilla looking for security issues that might affect them; this is, after all, what they pay Red Hat for.

As with seemingly everything in the world of computers, there is a trade-off here; very few customers would want to be upgrading their production systems frequently for low impact bugs. On the other hand, they may not want to be exposed forever to those same low impact bugs. Batching these kinds of fixes up into security updates once or twice a year seems like a reasonable plan, but holding on to updates for over a year may be just a bit more stability than some customers were looking for.