Two years of RHEL4 risk

A recently released report on the security track record of Red Hat Enterprise Linux 4 (RHEL4) sets out to quantify the risks that an administrator would have faced when using the distribution. It takes a comprehensive look at all of the vulnerabilities that were classified as 'critical' in the two years since RHEL4 was released. A measure of pride is evident in the recognition that there were only three critical vulnerabilities in the default server install, a rather nice accomplishment; the study itself is an even better result and it should set the bar for other similar studies in the future.

In stark contrast to almost daily studies that purport to 'prove' that Redmond's latest offering is vastly superior to Linux in the security arena, the RHEL study simply looks at the reported vulnerabilities in that distribution and leaves any comparisons for others. The study mainly focuses on the critical vulnerabilities, but it does look at the 'Vulnerability Workload Index' for a server install with all available packages. This index is meant to give a rough measure of the amount of work an administrator would need to do to keep a system free from all vulnerabilities. The most interesting conclusion that can be drawn from the graph is that the overall workload is pretty flat, there are certainly peaks, but it is neither increasing nor decreasing over time. Because the software released with RHEL4 is, of course, getting older and the upstream projects are likely to be releasing newer versions, a case could be made either way regarding increasing stability vs. more security issues found over time and it would appear that the two roughly balance each other.

Flaws that get the 'critical' designation are those that can lead to a system compromise in an automatic way without any user action. These are the kinds of bugs that could be exploited by worms to invade and propagate. The critical designation has been stretched to cover web browser bugs that are exploited when a user visits a site with malicious code. The vast majority of critical bugs fall into the latter category and that difference leads to 60 flaws in a system with all packages installed, 50 of which can be traced to Mozilla products or the HelixPlayer plugin.

The study goes into the 60 critical flaws in some depth, categorizing them by type and reporting on the so-called 'days of risk' (number of days after a vulnerability report before a fix is available). All critical flaws were fixed within two calendar days and 60% were fixed on the same day. The riskiest packages are also listed using a weighted score based on the number and severity of bugs in that package with various Mozilla projects coming out on top. Interestingly, the kernel dropped from #1 last year to #4 in the current report.

The risk to a system is not only a function of the vulnerabilities in the packages it has installed; exploits 'in the wild' also factor into it. The report looks in detail at exploits for 37 vulnerabilities, many of which are, unsurprisingly, either browser or 'user complicit' exploits. Triggering a user complicit exploit requires convincing a user to perform some action with a malicious file; because administrators should be wary of such things or even of running a browser from a privileged account, the impact of those exploits are limited. The seven kernel and six server exploits represent a more dangerous class, with system compromise a distinct possibility. None of the kernel exploits were remote and all were either denial of service or privilege escalation bugs. Each of the server application exploits could lead to compromise of the non-root user that runs the service.

It is interesting to note that SELinux and Exec-Shield are specifically mentioned as either eliminating or reducing the impact of eleven of these exploits. Both of these security tools are installed by default with RHEL4 and are targeted at stopping or reducing the effectiveness of just these kinds of attacks. Exec-Shield uses address space randomization and protection against executing code from the stack to avoid executing arbitrary code in the presence of a buffer overflow or similar flaw. The SELinux policy that ships with RHEL4 restricts users and processes to only that set of resources they need for their normal function and that can reduce the kinds of problems an exploited process can cause. While they are no substitute for correctly written code, these technologies are clearly helpful to reduce security threats; with luck other techniques will come along that continue this kind of work.

This is the second report on RHEL4 security; the first covers the first year of release. Based on a comment on his original article, the author is planning a four year retrospective on RHEL3 in November which should be interesting as well. The comment indicates only six critical vulnerabilities in the RHEL3 default install in its three and a half years.

It is difficult to put a label on the level of 'security risk' that a particular system has, but RHEL4 would seem to have a fairly low risk overall. If one keeps up with the patches and is reasonably cognizant of security practices, the chances for a system compromise are low. This is a real accomplishment by the Red Hat team and should be a feather in the cap for Linux in general. No software is perfect and an operating system or distribution is just a collection of software so vigilance is required. Without examining our track record, it is difficult to gauge progress and this kind of report is an excellent way to track that progress; hopefully other distributions will follow suit.