Red Hat Enterprise Linux 5.2 was released last week, around 6 months since the
release of 5.1 in November 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 starting at 5.1 up to and including the 5.2 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.

So for a default install, from release of 5.1 up to and including 5.2, we shipped 46
updates to address 119 vulnerabilities. 8 advisories were rated critical, 24
were important, and the remaining 14 were moderate and low.

For all packages, from release of 5.1 to and including 5.2, we shipped 62 updates
to address 179 vulnerabilities. 9 advisories were rated critical, 29 were
important, and the remaining 24 were moderate and low.

The nine critical updates were in five different packages:

Four updates to Firefox (November, February, March, April)
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.

An update to the GnuTLS library (May), where
a remote attacker who can connect to a server making use of GnuTLS could
cause a buffer overflow. In Red Hat Enterprise Linux 5, the CUPS print
server uses GnuTLS.

An update to MIT Kerberos (March),
where a remote attacker who can conect to the krb5kdc or kadmind
services could cause a buffer overflow.

An update to OpenPegasus
(January), where
a remote attacker who can connect to OpenPegasus could cause a buffer overflow.
The Red Hat Security Response Team believes that it would be hard to remotely
exploit this issue to execute arbitrary code, due to the default SELinux
targeted policy, and the default SELinux memory protection tests.

Two updates to Samba (November, December) where
a remote attacker who can connect to the Samba port could cause buffer
overflows. In addition to
ExecShield making this harder to exploit, the impact of any sucessful
exploit would be reduced as Samba is constrained by an SELinux targeted
policy (enabled by default).

Updates to correct all of these critical issues were available via Red Hat
Network either the same day, or one calendar day after the issues were public.

To get a better idea of risk we need to look not only at the vulnerabilities but
also the exploits written for those vulnerabilities.
A proof of concept exploit exists publicly for one of the
Samba flaws,
CVE-2007-6015,
but we are not aware of public exploits for any other of those critical
vulnerabilities. Also of high risk was an important "zero-day" exploit affecting the Linux
kernel where a local unprivileged user could gain root privileges.
Red Hat Enterprise Linux 5.1 was affected and
a fix was
available two calendar days after public disclosure.

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 updates:

A double-free flaw in CUPS. The glibc pointer checking limited the
exploitability of this issue to just a crash of CUPS and not the ability to
execute arbitrary code. code execution. We
still issued an
update, as a remote attacker could trigger this flaw and cause CUPS to
crash.

An uninitialized pointer free flaw in unzip, caught by the glibc pointer
checking. As exploitation of this flaw results in just
a crash of a
user application, no updates were needed.

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 custom metrics for any
given Red Hat product, package set, timescales, and severities.