Six years of RHEL 4 security

Red Hat does a good job of looking at the security problems found and fixed in its enterprise distributions. It issues periodic reports on those security problems to try to give its customers—and interested bystanders—a sense of how vulnerable their systems are over the lifetime of a particular release. The most recent report [PDF] looks at six years of security update data for RHEL 4.

The report was written by Red Hat security team lead Mark J. Cox, and looks at two broad categories of security concerns: vulnerabilities and threats. Even a cursory glance at the vulnerability information makes it clear that the most numerous flaws come in web browsers. That may not affect too many RHEL customers for a couple of reasons. Most RHEL installations are for servers where browsers are not installed by default and are probably rarely installed by administrators. In addition, browser vulnerabilities require visiting a malicious or compromised site and, even on systems where a browser is installed, one would think that administrators would be fairly careful about which sites are visited.

For desktop or workstation systems, of course, a web browser is standard fare. Over the six years, there have been nearly 200 critical flaws in Mozilla products (which includes Firefox, Seamonkey, and Thunderbird). By way of contrast, the default server install of RHEL 4 has only suffered from 20 critical flaws in that time.

Beyond the Mozilla products (which are the top three entries in the table of "worst security history" in the report), the packages that had multiple critical issues include Samba and Kerberos. Another desktop-oriented package appears in the list, HelixPlayer, which was eventually dropped from RHEL 4 because it was proprietary code that could no longer have its security problems fixed. While the kernel is number four on the list, it has had zero critical vulnerabilities during RHEL 4's lifetime (though there have been nearly 300 vulnerabilities at lower severity levels). It is clear that avoiding browsers and other desktop software will make for a system with fewer updates needed—something that's not really possible for many users, but should be for server systems.

But there clearly were flaws beyond the browser, and the report breaks out the two dozen or so critical flaws in the other packages. The list shows the CVE number (and Red Hat advisory number), whether it is a default package or not (most were), a short description of the vulnerability, and the so-called "days of risk". That measure is meant to give a rough guide of how long it was between the public release of the vulnerability information until Red Hat had a fix available. Those numbers were typically zero (a fix on the same day as the disclosure), though there were some outliers including a seven day risk window for a 2007 GnomeMeeting (now Ekiga) bug.

On the threats side of the ledger, Cox reports on the public exploits that were found that tried to take advantage of the vulnerabilities in RHEL. The exploits described were limited to those that "have the potential to cause remote damage to the confidentiality or integrity of a system". So, denial of service exploits were not considered. For the purposes of looking at the threats, "proof of concept" exploits were counted, and that led to 80 public exploits of RHEL 4 vulnerabilities being found.

There were 15 privilege escalation exploits, 22 web browser exploits (all but three for Mozilla products, though Links, Lynx, and HelixPlayer each had one), 17 "user-complicit" exploits (where the user needs to do something to make it happen, like opening a file with a vulnerable application), and 9 exploits for PHP vulnerabilities (many of which were reported during the "PHP month of bugs"). While some of those could certainly prove to be problematic, the privilege escalations in particular, they often require a hard-to-engineer set of circumstances—at least for widespread exploitation. The most dangerous group are the 17 public exploits that were found for services, many of which would be running on a default RHEL install.

The report also noted the lack of any known Linux worms since 2005. There were two in that year, but both were exploiting PHP flaws in applications that are not shipped with RHEL 4 (though could have been installed by the administrator separately).

The full report is well worth a read for those who are interested. It does a good job reporting on the security vulnerability landscape for RHEL 4, but, more importantly, gives even those who don't run RHEL a useful look at the type and severity of Linux security problems. It would be nice to see more distributions, especially those targeting enterprises, produce similar reports.