Enterprise Linux 5.0 to 5.1

Red Hat Enterprise Linux 5.1 was released today, around 8 months since the release of 5.0 in March 2007. So let's use this opportunity to take a quick look back over the vulnerabilities and security updates we've made in that time, specifically for Red Hat Enterprise Linux 5 Server.

The graph below shows the total number of security updates issued for Red Hat Enterprise Linux 5 Server up to and including the 5.1 release, broken down by severity. I've split it into two columns, one for the packages you'd get if you did a default install, and the other if you installed every single package (which is unlikely as it would involve a bit of manual effort to select every one). So, for a given installation, the number of packages and vulnerabilities will be somewhere between the two extremes.

So for all packages, from release up to and including 5.1, we shipped 94 updates to address 218 vulnerabilities. 7 advisories were rated critical, 36 were important, and the remaining 51 were moderate and low.

For a default install, from release up to and including 5.1, we shipped 60 updates to address 135 vulnerabilities. 7 advisories were rated critical, 26 were important, and the remaining 27 were moderate and low.

• These figures include ten updates we released on the day we shipped 5.0. This was because we froze package updates some months before releasing the product. Only one of those updates was rated critical, an update to Firefox.
• The six other critical updates were:
  1. Three more updates to Firefox (May, July, October) where a malicious web site could potentially run arbitrary code as the user running Firefox. Given the nature of the flaws, ExecShield protections in RHEL5 should make exploiting these memory flaws harder.
  2. An update to the Kerberos telnet deamon (April) A remote attacker who can access the telnet port of a target machine could log in as root without requiring a password. None of the standard protection mechanisms help prevent exploitation of this issue, however the krb5 telnet daemon is not enabled by default in Enterprise Linux 5 and the default firewall rules block remote access to the telnet port. This flaw did not affect the more common telnet daemon distributed in the telnet-server package.
  3. An update to Samba (May) where a remote attacker could cause a heap overflow. In addition to ExecShield making this harder to exploit, the impact of any successful exploit would be reduced as Samba is constrained by an SELinux targeted policy (enabled by default).
  4. An update to the PCRE library (November). This was labelled critical because the Konqueror web browser uses PCRE to handle regular expressions in JavaScript, and therefore a user browsing a malicious site in Konqueror could trigger this issue. (Konqueror is not part of a default install, but I've left this issue as critical in the results).
• Updates to correct all of these critical issues were available via Red Hat Network within a day of the issues being public.

Red Hat Enterprise Linux 5 shipped with a number of security technologies designed to make it harder to exploit vulnerabilities and in some cases block exploits for certain flaw types completely. For the period of this study there were two flaws blocked that would otherwise have required critical updates:

1. A stack buffer overflow flaw in the RPC library in Kerberos. This flaw was blocked by FORTIFY_SOURCE which removed the possibility of remote code execution. We still issued an update, as a remote attacker could trigger this flaw and cause Kerberos to crash.
2. Another flaw in Kerberos, this time due to the free of an invalid pointer. This flaw was blocked by glibc, although a remote attacker could still cause a crash, so we issued an update.

This data is interesting to get a feel for the risk of running Enterprise Linux 5 Server, but isn't really useful for comparisons with other versions or distributions -- for example, a default install of Red Hat Enterprise 4AS did not include Firefox. You can get the results I presented above for yourself by using our public security measurement data and tools, and run your own metrics for any given Red Hat product, package set, timescales, and severities.