Rate this page del.icio.us  Digg slashdot StumbleUpon

Enterprise Linux 5.2 to 5.3 risk report

by Mark J Cox

Red Hat Enterprise Linux 5.3 was released today, around 8 months since the release of 5.2 in May 2008. 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 chart below shows the total number of security updates issued for Red Hat Enterprise Linux 5 Server as if you installed 5.2, up to and including the 5.3 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 probably be somewhere between the two.

missing graph

For a default install, from the release of 5.2 up to and including 5.3, we shipped 45 advisories to address 127 vulnerabilities. Seven advisories were rated critical, 21 were important, and the remaining 17 were moderate and low.

For all packages, from the release of 5.2 up to and including 5.3, we shipped 61 advisories to address 181 vulnerabilities. Seven advisories were rated critical, 28 were important, and the remaining 26 were moderate and low.

The 7 critical advisories were for just 3 different packages:

1. Five updates to Firefox (July, July, September, November, December) where a malicious web site could potentially run arbitrary code as the user running Firefox. Given the nature of the flaws, ExecShield protections in Red Hat Enterprise Linux 5 should make exploiting these memory flaws harder.

2. An update to Samba (May) where a remote attacker who can connect and send a print request to a Samba server could cause a heap overflow. The Red Hat Security Response Team believes it would be hard to remotely exploit this issue to execute arbitrary code due to the default enabled SELinux targeted policy and the default enabled SELinux memory protection tests. We are not aware of any public exploit for this issue.

3. An update to OpenSSH (August), provided to mitigate an intrusion into certain Red Hat computer systems. The attacker was able to sign a small number of tampered packages, but they were not distributed on the Red Hat Network. We classified this update as critical to ensure any tampered packages would be replaced with official packages.

Although not of critical severity, also of interest during this period were the spoofing attacks on DNS servers. We provided an update to BIND (July) adding source port randomization to help mitigate these attacks.

Updates to correct all of these critical vulnerabilities (as well as migitate the BIND issue) were available via Red Hat Network either the same day or one calendar day after the issues were public.

In fact, for Red Hat Enterprise Linux 5 since release and to date, every critical vulnerability has had an update to address it available from the Red Hat Network either the same day or the next calendar day after the issue was public.

To compare this with the last updates, we need to take into account that the time between each update is different. So looking at a default installation and calculating the number of advisories per month gives the following chart:

missing graph

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 5.2 to 5.3 there were two flaws blocked that would otherwise have required updates:

1. A double-free flaw in unzip. The glibc pointer checking limited the exploitability of this issue to just a crash of unzip, a client application, which does not
have security implications. No security update was needed.

2. Two format string flaws in c++filt. The format string protection caused these issues to have no security implications. No security update was needed.

This data is interesting to get a feel for the risk of running Enterprise Linux 5 Server, but it isn’t really useful for comparisons with other versions, distributions, or operating systems. For example, a default install of Red Hat Enterprise Linux 4 AS did not include Firefox, but 5 Server does. You can use our public security measurement data and tools, and run your own custom metrics for any given Red Hat product, package set, timescales, and severity range of interest.

See also: 5.1 to 5.2 risk report

7 responses to “Enterprise Linux 5.2 to 5.3 risk report”

  1. Jason Mock says:

    Those of us whom work for businesses that block flickr, cannot benefit from your provided graphs…

  2. Fill says:

    Is it possible to upgrade red hat enterprise 5 without a RHN subscription????

    Thanks

  3. Red Hat Enterprise Linux 5.3 with new features and more security - Enterprise Linux Log says:

    […] company released a risk report comparing RHEL 5.2 to RHEL 5.3. Briefly, the report explains that 61 advisories were released to address the 181 vulnerabilities […]

  4. Jim Wildman says:

    Why are you posting corporate information on flickr? It is blocked by our firewalls (besides being a rather transient place to put important content).

  5. Mark Cox says:

    A version without flickr graphics is available at:

    http://www.awe.com/mark/blog/2009012017.html

  6. roadrunner_gs says:

    @Fill: You could download the source-code of the packages (ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS) and rpmbuild them for yourself or you wait for CentOS to rebuild the packages for you. CentOS 5.3 should be around in a month or so. But RHN has the benefit of managing your systems and granting updates from a central place. Besides the fact that you have support – sometimes very very important for companies.

  7. Ray says:

    Maybe the default install needs to be pared down or a stripped-down version made selectable. For example, why does a server need Firefox? No one should be browsing anything from a server. With all of the recent hacks related to packet sniffers getting installed by malware, why is tcpdump part of the default install? I prefer to not make it easier for hackers.

    And, since I specifically deselected BIND during the install, why the heck does the RHN system give me patched BIND libraries? Why, if I uninstall CUPS, does the RHN put it back? I always update the RHN profile after removing a package, but it seems that some files are forced down whether they are are needed or not.