Red Hat Enterprise Linux 5.8 was released today (February 2012), seven
months since the release of 5.7 in July 2011. So let's use this opportunity to
take a quick look back over the vulnerabilities and security updates made in
that time, specifically for Red Hat Enterprise Linux 5 Server.

Errata count

The chart below illustrates the total number of security updates issued for Red
Hat Enterprise Linux 5 Server if you had installed 5.7, up to and including the
5.8 release, broken down by severity. It's split 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 quite a bit of
manual effort to select every one). For a given installation, the number of
package updates and vulnerabilities that affected you will depend on exactly
what packages you have installed or removed.

So, for a default install, from release of 5.7 up to and including
5.8, we shipped 42 advisories to address 118 vulnerabilities. 4
advisories were
rated critical, 13 were important, and the remaining
25 were moderate and low.

Or, for all packages, from release of 5.7 up to and including 5.8, we
shipped 71 advisories to address 177 vulnerabilities. 7 advisories
were rated critical, 16 were important, and the remaining 48 were
moderate and low.

An update to the
MIT krb5 telnet daemon
(December 2011) where
a remote attacker who can access the telnet port of a target machine could use
this flaw to execute arbitrary code as root. Note that the krb5 telnet daemon
is not installed or enabled by default, and the default firewall rules block remote access to
the telnet port. This flaw did not affect the more commonly used telnet daemon distributed in the
telnet-server package.

Updates to
PHP
and
PHP 5.3
(February 2012)
where a remote attacker could send a specially-crafted HTTP request to cause the
PHP interpreter to crash or, possibly, execute arbitrary code. This flaw was
caused by the fix for CVE-2011-4885.

Updates to correct 19 out of the 20 critical vulnerabilities were
available via Red Hat Network either the same day or the next
calendar day after the issues were public. The update to krb5
took 2 calendar days because it was public on Christmas day.

Overall, for Red Hat Enterprise Linux 5 since release until 5.8, 98%
of critical vulnerabilities have had an update available to address
them available from the Red Hat Network either the same day or the
next calendar day after the issue was public.

Other significant vulnerabilities

Although not in the definition of critical severity, also of interest during
this period were a couple of remote denial of service flaws that were easily exploitable:

Previous update releases

To compare these statistics with previous update releases we need
to take into account that the time between each update release is different.
So looking at a default installation and calculating the number of
advisories per month gives the following chart:

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 major
versions, distributions, or operating systems -- for example, a default install
of Red Hat Enterprise Linux 4AS 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.

Red Hat Enterprise Linux 5.7 was released last week (July 2011), six months
since the release of 5.6 in January 2011. So let's use this opportunity to take
a quick look back over the vulnerabilities and security updates made in that
time, specifically for Red Hat Enterprise Linux 5 Server.

Errata count

The chart below illustrates the total number of security updates issued for Red
Hat Enterprise Linux 5 Server if you had installed 5.6, up to and including the
5.7 release, broken down by severity. It's split 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 quite a bit of
manual effort to select every one). For a given installation, the number of
package updates and vulnerabilities that affected you will depend on exactly
what packages you have installed or removed.

So, for a default install, from release of 5.6 up to and including
5.7, we shipped 27 advisories to address 109 vulnerabilities. 3
advisories were rated critical, 12 were important, and the remaining
12 were moderate and low.

Or, for all packages, from release of 5.6 to and including 5.7, we
shipped 58 advisories to address 172 vulnerabilities. 4 advisories
were rated critical, 20 were important, and the remaining 34 were
moderate and low.

Critical vulnerabilities

The 4 critical advisories addressed 34 critical vulnerabilities across just 2 different packages:

An update to OpenJDK 6 Java Runtime Environment,
(June 2011)
where a web site hosting a malicious Java applet could potentially run
arbitrary code as the user.

Three updates to Firefox (March 2011, April 2011, June 2011)
where a malicious web site could potentially run arbitrary code as the user
running Firefox.

Updates to correct all of the 34 critical vulnerabilities were
available via Red Hat Network either the same day or the next
calendar day after the issues were public.

Overall, for Red Hat Enterprise Linux 5 since release until 5.7, 97%
of critical vulnerabilities have had an update available to address
them available from the Red Hat Network either the same day or the
next calendar day after the issue was public.

Other significant vulnerabilities

Although not in the definition of critical severity, also of interest during
this period were a couple of flaws that were easily exploitable:

A flaw in dhcp,
CVE-2011-0997,
fixed by
RHSA-2011:0428, where a malicious DHCP
server could send a response that could lead to arbitrary code execution on connecting clients.

Previous update releases

To compare these statistics with previous update releases we need
to take into account that the time between each update release is different.
So looking at a default installation and calculating the number of
advisories per month gives the following chart:

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 major
versions, distributions, or operating systems -- for example, a default install
of Red Hat Enterprise Linux 4AS 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.

Red Hat Enterprise Linux 5.6 was released last week (January 2011), nearly ten
months since the release of 5.5 in March 2010. So let's use this opportunity to
take a quick look back over the vulnerabilities and security updates made in
that time, specifically for Red Hat Enterprise Linux 5 Server.

Errata count

The chart below illustrates the total number of security updates issued for Red
Hat Enterprise Linux 5 Server if you had installed 5.5, up to and including the
5.6 release, broken down by severity. It's split 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). For a given installation, the number of
package updates and vulnerabilities that affected you will depend on exactly what you
have installed or removed.

So, for a default install, from release of 5.5 up to and including
5.6, we shipped 57 advisories to address 206 vulnerabilities. 10
advisories were rated critical, 27 were important, and the remaining
20 were moderate and low.

Or, for all packages, from release of 5.5 to and including 5.6, we
shipped 80 advisories to address 300 vulnerabilities. 12 advisories
were rated critical, 34 were important, and the remaining 34 were
moderate and low.

Critical vulnerabilities

The 12 critical advisories addressed 49 critical vulnerabilities across just 3 different packages:

An update to the Exim Internet Mailer,
(December 2010),
where an unauthenticated remote attacker could run arbitrary code as root on a
server.
Exim is not a default package or enabled by default. There is a
public exploit for this issue which worked on Red Hat Enterprise Linux 5.

Updates to correct 48 out of the 49 critical vulnerabilities were
available via Red Hat Network either the same day or the next
calendar day after the issues were public. The update to fix Exim took
3 calendar days from
the date of the report
to the Exim developers.

Overall, for Red Hat Enterprise Linux 5 since release until 5.6, 97%
of critical vulnerabilities have had an update available to address
them available from the Red Hat Network either the same day or the
next calendar day after the issue was public.

Other significant vulnerabilities

Although not in the definition of critical severity, also of interest during
this period were several kernel flaws that where an local user could gain
root privileges. The following had publicly available exploits:

A fix
for CVE-2010-2240
was provided
by RHSA-2010-0661
(August 2010). The public exploit did not work against Red Hat Enterprise
Linux 5, but it may be possible to create one that does.

A fix
for CVE-2010-3904
was provided
by RHSA-2010-0792
(October 2010). The public exploit did not work against Red Hat Enterprise
Linux 5 but it is possible to create one that does.

Previous updates

To compare these statistics with previous update releases 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:

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 major
versions, distributions, or operating systems -- for example, a default install
of Red Hat Enterprise Linux 4AS 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.

Red Hat Enterprise Linux 5.5 was released at the end of March 2010,
just under 7 months since the release of 5.4 in September 2009. 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.

Errata count

The chart below illustrates the total number of security updates issued for Red
Hat Enterprise Linux 5 Server if you had installed 5.4, up to and including the
5.5 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). For a given installation, the number of
package updates and vulnerabilities that affected you will depend on exactly what you
have installed or removed.

So for a default install, from release of 5.4 up to and including
5.5, we shipped 52 advisories to address 140 vulnerabilities. 5
advisories were rated critical, 14 were important, and the remaining
33 were moderate and low.

Or, for all packages, from release of 5.4 to and including 5.5, we
shipped 75 advisories to address 187 vulnerabilities. 6 advisories
were rated critical, 18 were important, and the remaining 51 were
moderate and low.

Critical vulnerabilities

The 6 critical advisories were for 3 different packages. Given the
nature of the flaws, ExecShield protections in RHEL5 should make
exploiting the memory flaws harder.

An update to kdelibs
(November 2009),
where a malicious web site could potentially run arbitrary code as the
user running the Konqueror browser. kdelibs is not a default
installation package.

An update to krb5, the Kerberos network authentication system
(January 2010),
where a remote KDC client could cause a crash or run arbitrary code as
root. This issue only affected users that have configured and enabled
krb5.

Updates to correct 24 out of the 25 critical vulnerabilities were
available via Red Hat Network either the same day, or up to one
calendar day after the issues were public. The update to fix Konqueror took
us 4 calendar days.

Overall, for Red Hat Enterprise Linux 5 since release to date, 98%
of critical vulnerabilities have had an update available to address
them available from the Red Hat Network either the same day or the
next calendar day after the issue was public.

Other significant vulnerabilities

Red Hat Enterprise Linux since 5.2 contained backported patches
from the upstream Linux kernel to add the ability to restrict
unprivileged mapping of low memory, designed to mitigate NULL pointer
dereference flaws. In the last risk report we mentioned it was found
that this protection was not sufficient, as a system with SELinux
enabled was more permissive in allowing local users in the
unconfined_t domain to map low memory areas even if the mmap_min_addr
restriction is enabled. This is
CVE-2009-2695
and was addressed in a kernel update in November 2009.

Previous updates

To compare these statistics with previous update releases 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 results illustrated by the following
chart:

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, distributions, or operating systems -- for
example, a default install of Red Hat Enterprise Linux 4AS 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.

Red Hat Enterprise Linux 5.4 was released today, just over 7 months since the
release of 5.3 in January 2009. 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.

Errata count

The chart below illustrates the total number of security updates issued for Red
Hat Enterprise Linux 5 Server as if you installed 5.3, up to and including the
5.4 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). For a given installation, the number of
package updates and vulnerabilities that affected you will depend on exactly what you
have installed or removed.

So for a default install, from release of 5.3 up to and including 5.4, we shipped 51
advisories to address 166 vulnerabilities. 8 advisories were rated critical, 18
were important, and the remaining 25 were moderate and low.

Or, for all packages, from release of 5.3 to and including 5.4, we shipped 78 advisories
to address 251 vulnerabilities. 9 advisories were rated critical, 28 were
important, and the remaining 41 were moderate and low.

Critical vulnerabilities

The 9 critical advisories were for just 3 different packages. In all the
cases below, given the nature of the flaws, ExecShield protections in RHEL5
should make exploiting these memory flaws harder.

An update to kdelibs
(June),
where a malicious web site could potentially run arbitrary code as the
user running the Konqueror browser. kdelibs is not a default installation package.

An update to the NSS library
(July), where
a service could present a malicious SSL certificate causing
a heap overflow which could potentially run arbitrary code as the user running
a browser such as Firefox.

Updates to correct all of these critical vulnerabilities were available via
Red Hat Network either the same day, or up to 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 available to address it available from
the Red Hat Network either the same day or the next calendar day after the issue
was public.

Other significant vulnerabilities

Although not in
the definition
of critical severity, also of interest during this period were several NULL
pointer dereference kernel issues. NULL pointer dereference flaws in the Linux
kernel can often be easily abused by a local unprivileged user to gain root
privileges through the mapping of low memory pages and crafting them to contain
valid malicious instructions:

CVE-2009-2698
was public on August 24th and a working privilege escalation exploit was
published about a week later. This issue was addressed for Red Hat Enterprise
Linux 5 by
a kernel update on
August 24th.

CVE-2009-2692
was public on August 13th and a working privilege escalation exploit was
published the same day.
This issue was addressed for Red Hat Enterprise Linux 5 by
a kernel update on
August 24th.

CVE-2009-1897
was public on July 16th along with a working privilege escalation exploit. This issue
affected only beta versions of the Red Hat Enterprise Linux 5.4 kernel and
it was addressed prior to the release of Red Hat Enterprise Linux 5.4.

Red Hat Enterprise Linux since 5.2 has contained backported patches from the
upstream Linux kernel to add the ability to restrict unprivileged mapping of low
memory, designed to mitigate NULL pointer dereference flaws. However it was found that
this protection was not sufficient, as a system with SELinux enabled is more
permissive in allowing local users in the unconfined_t domain to map low memory
areas even if the mmap_min_addr restriction is enabled. This is
CVE-2009-2695
and will be addressed in a future kernel update.

Mitigations

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. From 5.3 to 5.4 there
were three flaws blocked that would otherwise have required critical updates:

CVE-2009-0692,
a stack buffer overflow flaw in dhclient.
FORTIFY_SOURCE protection detects the overflow and causes dhclient to exit with
no security consequence. No security update for users of Red Hat Enterprise
Linux 5 was needed.

CVE-2009-1252
a buffer overflow flaw in NTP caught by FORTIFY_SOURCE.
We issued an
update as a remote attacker could still cause a denial of service.

CVE-2009-0846,
a uninitialized pointer free in krb5. glibc provides a hardened malloc/free
implementation which mitigates the exploitability of this flaw, however we
issued an update as a remote attacker could still cause a denial
of service.

Previous updates

To compare these statistics with previous update releases 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 results
illustrated by the following chart:

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,
distributions, or operating systems -- for example, a default install of Red Hat
Enterprise Linux 4AS 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.

The National Vulnerability Database provides a public severity rating
for all CVE named vulnerabilities, "Low" "Medium" and "High",
which they generate automatically based on the CVSS score their
analysts calculate for each issue. I've been interested for some time to see
how well those map to the severity ratings that Red Hat give to
issues. We use the same ratings
and methodology as Microsoft and others use, assigning "Critical"
for things that have the ability to be remotely exploited automatically
through "Important", "Moderate", to "Low".

Given a thundery Sunday afternoon I took the last 12 months of all possible
vulnerabilities affecting Red Hat Enterprise Linux 4 (from 126 advisories across
all components) from my metrics page and compared to NVD using their provided XML
data files. The result broke down like this:

Red Hat

13% Crit

24% Important

39% Moderate

24% Low

NVD

30% High

20% Moderate

50% Low

So that looked okay on the surface; but the diagram above implies that
all the issues Red Hat rated as Critical got mapped in NVD to High. But
that's not actually the case, and when you
look at the breakdown you get this result: (in number of vulnerabilities)

&nbsp

NVD: High

23 Critical

24 Important

35 Moderate

8 Low

NVD: Moderate

9 Crit

18 Important

22 Moderate

12 Low

NVD: Low

7 C

32 Important

62 Moderate

51 Low

That shows nearly half of the issues that NVD rated as High actually only
affected Red Hat with Moderate or Low severity. Given our policy is to fix the
things that are Critical and Important the fastest (and we have a pretty impressiverecord
for fixing critical issues), it's no wonder that recent vulnerability studies
that use the NVD mapping when analysing Red Hat vulnerabilities have some
significant data errors.

I wasn't actually surprised that there are so many differences: my
hypothesis is that many of the errors are due to the nature of how
vulnerabilities affect open source
software. Take for example the Apache HTTP server. Lots of companies ship
Apache in their products, but all ship different versions with different
defaults on different operating systems for different architecture compiled with
different compilers using different compiler options. Many Apache
vulnerabilities over the years have affected different platforms in
significantly different
ways. We've seen an Apache vulnerability that leads to arbitrary code execution
on older FreeBSD, that causes a denial of service on Windows, but that was
unexploitable on Linux for example. But it has a single CVE identifier.

So if you're using a version of the Apache web server you
got with your Red Hat Enterprise Linux distribution then you need to
rely on Red Hat to tell you how the issue affects the version they
gave you -- in the same way you rely on them to give you an update
to correct the issue.

I did also spot a few instances where the CVSS score for a given vulnerability
was not correctly coded. CVSS version 2 was released last week and once NVD is
based on the new version I'll redo this analysis and spend more time submitting
corrections to any obvious mistakes.

But in summary: for multi-vendor software the severity rating for a given
vulnerability may very well be different for each vendors version. This is a
level of detail that vulnerability databases such as NVD don't currently
capture; so you need to be careful if you are relying on the accuracy of
third party severity ratings.

Earlier this month, Steve Christey posted a draft report of the Vulnerability
Type Distributions in CVE. The report notices, amongst other things, some differences between open and closed source vendors. I thought it would be more interesting to focus just on one of our released distributions to see if it made a difference to the trends. Steve kindly provided some reports based on a list of CVE names I gave him, and this led to the analysis and these two graphs.

First, the Vulnerability Type Distribution graph. This is not really a big surprise, the most common vulnerabilities we fix are buffer overflows.
Technologies such as ExecShield (PIE, support for NX, FORTIFY_SOURCE
and so on) were designed specifically to reduce the risk of being able
to exploit this flaw type. Secondly, compared to the industry as a whole we fix far less web application flaws
such as cross-site scripting or SQL injection. This result is to be expected as most of these are in PHP web applications we don't ship in our distributions.

Earlier this month Red Hat started publishing Open Vulnerability and Assessment Language (OVAL) definitions for Red Hat Enterprise Linux security issues and today we obtained official compatibility. But what are these definitions, how do you use them, and why are they important?

One of the goals of Red Hat Enterprise Linux is to maintain backward compatibility of the packages we ship where possible. This goal means making sure that when we release security updates to fix vulnerabilities that we include just the security fixes in isolation, a process known as backporting. Backporting security fixes has the advantage that it makes installing updates safer and easier for
customers, but has the disadvantage that it can cause confusion to people unfamiliar with the process who try to use the version number of a particular piece of software to determine it's patch status.

In 2002, Red Hat started publishing Common Vulnerability and Exposures (CVE) vulnerability identifiers on every security advisory in order to make it easy to see what we fixed and how. Customers need only know the CVE identifiers for the vulnerabilities they are interested in and can then find out quickly and easily which of our updates addressed that particular vulnerability. CVE is now used on security advisories from nearly all the major vendors.

Red Hat has a single common mechanism for keeping systems up to date with security errata, the Red Hat Network. The Red Hat Network looks at a customers machines to determine which updates are required and gives anything from a customised
notification that an update is available through to automated installation. Third party patch auditing tools don't have such an easy time figuring out what up
dates are required: they have to maintain their own list of Red Hat package versions against vulnerability names. As this list is different for each operating system version from each potential vendors, these tools are prone to many errors and lag behind our updates.

We've also found customers that query the Red Hat Network errata pages directly to gather information about our security advisories and put them into a format
they can integrate with their own processes. Many customers take feeds of vulnerability data, usually in some XML format, from third party security vulnerability companies.

MITRE recognised both of these issues a number of years ago when they founded the Open Vulnerability and Assessment Language project, OVAL in 2002. The aim of OVAL is to provide a language for defining how to test for vulnerabilities and system configuration errors in an open and cross-platform manner. Red Hat was a founding board member of the OVAL project as part of our overall commitment to security quality.

So Red Hat now publishes OVAL 5 definitions for our Red Hat Enterprise Linux 3 and 4 security advisories. Each security advisory gets a separate XML OVAL file
which defines the steps needed to test if an update is required for the target system. In an ideal world every Red Hat Enterprise Linux system would be consuming every update from Red Hat Network automatically, but for those that don't or
where systems have been disconnected for some time, these definitions can help determine the patch status. In addition, these definitions contain selected info
rmation from our advisories which can be combined with vulnerability feeds from third parties.

For each Enterprise Linux version, a list of the packages and versions required to determine if the update is required

The actual OVAL definitions themselves are available from https://www.redhat.com/oval/ and are public within a couple of hours of an advisory being pushed to the Red Hat Network. OVAL definitions for all previous Red Hat Enterprise Linux 3 and 4 advisories are also available. At present we do not ship OVAL tools such
as a definition interpreter, but there are severalopen-source and commercial OVAL-compatible tools available.

For the future we encourage other vendors to publish definitive OVAL definitions for their products too, and we hope to work on compatibility testing with other operating system and tool vendors.

More information about the make-up of the OVAL patch definitions can be found at the MITRE OVAL site. An FAQ about our implementation and where to contact us with comments or questions is also available.

I've just finished a run to update Red Hat security advisories from
CAN- to CVE- names, 180 advisories were updated.

In security advisories we include references to the MITE Common
Vulnerabilities and Exposures dictionary for each vulnerability,
you'll see us link to names like CAN-2004-0111. The CAN- prefix shows
that the entry is a candidate that has been proposed for inclusion in
the dictionary. From time to time the editorial board (of which Red
Hat is a member) votes on the candidates and the ones that pass get
promoted to full CVE- prefixes, but only the prefix changes. In the
recent round of voting I accepted or modified 145 entries. Yesterday
the CVE project promoted 480 CAN names to CVE names. We've updated
our mappings so that if you look on the Red Hat Network or online at
our advisory texts you'll see reference to the promoted names. We've
not gone through and altered the text, or are we likely to, so you
might still see texts refer to CAN-2004-0111 for example, but all the
links are magically updated to CVE-2004-0111.