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.
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.
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 example CVE-2005-4268 relies on an attacker giving a victim a
carefully crafted rather large cpio file, and getting the victim to open
it using the cpio command on a 64-bit platform. Even if the attacker
manages that, the ability to lead to code execution is unlikely. So we
defer these issues; customers don't want to go through an update and test
cycle just to fix such an issue. Then, when other issues of a higher
severity come up in the same package, or if we are to release an update
to that package for any other reason, we also pick up any fixes we
Red Hat Enterprise Linux errata are batched into periodic 'updates'; what
was released this week was Update 5 for Red Hat Enterprise Linux 4.
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.
to post comments)