|Risk report: Four years of Red Hat Enterprise Linux 4|
|Written by Mark Cox|
|Tuesday, 10 March 2009 18:06|
Red Hat® Enterprise Linux® 4 was released on February 15th, 2005. This report takes a look at the state of security for the first four years from release. We look at key metrics, specific vulnerabilities, and the most common ways users were affected by security issues. We will show some best practices that could have been used to minimise the impact of the issues, and also take a look at how the included security innovations helped.
This report is an update to the three-year risk report published in Red Hat Magazine in February 2007.
We measure the overall risk of running Enterprise Linux 4 as a function of two factors; the vulnerabilities and the threats. Our first section covers the security vulnerabilities found in packages that are part of Enterprise Linux 4 and the advisories that address them. Our second section covers the threats by examining actual exploitation of those vulnerabilities through exploits and worms.
All the data used to generate this report, tables, and graphs, apply to Red Hat Enterprise Linux 4 AS from release day, 15 February 2005 to 14 February 2009 unless otherwise stated.
At first sight it may appear that Red Hat have released a lot of updates for Enterprise Linux 4; in the last twelve months publishing a total of 107 security advisories to address 251 individual vulnerabilities. But in reality this is by far a worst-case metric, as it treats all vulnerabilities as equal, regardless of their severity and assumes a system that has installed every available package – which is not a default or even a likely installation.
With the release of Enterprise Linux 4, we started publishing severity levels with package errata to help users determine which advisories were the ones that mattered the most. Providing a prioritised risk assessment helps customers to understand and better schedule upgrades to their systems, being able to make a more informed decision on the risk that each issue places on their unique environment. Red Hat rates the impact of individual vulnerabilities on a four-point scale designed to be an at-a-glance guide to how worried Red Hat is about each security issue.
2.1. Vulnerability Counts
There are four variants of Red Hat Enterprise Linux 4; two targeted at server solutions with Enterprise Linux AS and ES, and two targeted at client solutions with Enterprise Linux WS and Red Hat Desktop. The package set available in Enterprise Linux WS and Red Hat Desktop is a subset of that available in Enterprise Linux AS.
During Enterprise Linux 4 installation, the user gets a choice of installing either the default selection of packages, or making a custom selection. Table 2 shows the vulnerability counts, normalised by CVE name, for some selected configurations.
Table 2. Vulnerabilities by severity, 4 years
A default install of Enterprise Linux 4 AS was only vulnerable to ten critical flaws in the whole four years. This is because most of the critical flaws have been in web browsers and their plug-ins: Firefox and Mozilla/SeaMonkey packages are not installed by default on distributions intended for server systems.
Client systems (Enterprise Linux WS and Red Hat Desktop) do include Firefox, Mozilla, and Helixplayer by default, leading to 126 critical vulnerabilities. A custom installation of AS, selecting every available package, would yield a system affected by the maximum possible number of critical vulnerabilities for the four years, 130.
For the purposes of this study we consider the worst-case scenario, a version of Red Hat Enterprise Linux 4 obtained on the day of release. During the first four years, six Update releases were made (Update 1 in June 2005, Update 2 in October 2005, Update 3 in March 2006, Update 4 in August 2006, Update 5 in May 2007, Update 6 in November 2007, Update 7 in July 2008). The Update releases are similar to a “service pack” and contain a roll-up of all security advisories. So, for example, a user who installed Enterprise Linux 4 in August 2008 would use Update 7 and be affected by only a subset of the issues. We’ve also counted vulnerabilities not advisories; it’s usual for a single security update of a package to fix a number of vulnerabilities at the same time, so the number of advisories and updates needed to be installed is far lower.
2.2. Critical Flaws
Vulnerabilities rated critical severity are the ones that can pose the most risk to an organisation. By definition, a critical vulnerability is one that could potentially be exploited remotely and automatically by a worm. However we also stretch the definition to include those flaws that affect web browsers or plug-ins where a user only needs to visit a malicious (or compromised) web site in order to be exploited. Since the vast majority of critical severity issues occurred due to web browsers or plugins, this is why there is such a difference between the number of critical issues that affects a default install of Enterprise Linux 4 AS and WS.
For the purposes of the severity classification we ignore what privileges the attacker would be able to gain: a remote root compromise via something like Samba would be of a much higher risk than a user-complicit Firefox flaw that results in running code as an unprivileged user, but both would be rated as critical on this scale.
To help qualify the risk we’ve split up the critical vulnerabilities into those that require some minimal user interaction to be exploitable (such as if a user visits malicious web page), and those that require no user interaction at all (and therefore could potentially be exploited by a worm).
For Enterprise Linux 4 AS with every package installed, Table 3 summarises all critical issues, and Table 4 breaks out the critical, non-browser flaws.
Table 3. All critical flaws
Table 4. Non-browser critical flaws
We’ve included in these tables the “days of risk” metric. This is commonly defined as the number of calendar days it takes for a vendor to produce updates that correct a flaw after the flaw is first known to the public.
Fixes for 87% of critical flaws were available from Red Hat Network the same day or next calendar day after public disclosure of the flaw. This fast response time is a deliberate goal of the Red Hat Security Response Team and forms an essential part of reducing customer risk from critical flaws.
2.3. Expanding “days of risk”
The “days of risk” metric has it’s limitations and so it isn’t particularly useful for comparing different software vendors against each other. The software that makes up the Enterprise Linux 4 distribution is open source, so we’re not the only vendor shipping each particular application. Unlike companies shipping proprietary software, Red Hat is not in sole control over the date each flaw is made public. This is actually a good thing and leads to much shorter response times between flaws being first reported to being made public. It also keeps us honest; Red Hat can’t play games to artificially reduce our #8220;days of risk” statistics by using tactics such as holding off public disclosure of important flaws for a long period, or until some regularly scheduled patch day.
A more useful metric to help assess risk would also take into account the amount of time that each issue was known to the vendor in advance. As part of our security measurement work since Enterprise Linux 4 we’ve been tracking how the Red Hat Security Response Team first found out about each vulnerability we fix. This information is interesting as it can also show us which relationships matter the most to us, and identify trends in vulnerability disclosure.
For each of the 1269 total vulnerabilities, across every package in Enterprise Linux in the 4 years, we determined if the flaw was something we knew about a day or more in advance of it being publicly disclosed, and how we found out  about the flaw. The results are summarised in Figure 2 and Figure 3.
Figure 2. Source of vulnerabilities known in advance
Figure 3. Source of vulnerabilities already public
Red Hat knew about 51% of the security vulnerabilities that we fixed at least a day in advance of them being publicly disclosed. For those issues, the average notice was 21 calendar days, although the median was much lower, with half the private issues having advance notice of 9 days or less. Figure 4 shows the distribution of notice periods in more detail.
Figure 4. How much time in advance Red Hat knew about issues before they were publicly disclosed
2.4. Riskiest packages
In our work tracking and fixing vulnerabilities it sometimes seems like we produce a security advisory for the same packages every month. We therefore analysed Enterprise Linux 4 to find out which packages were
Table 5. Top 10 packages with the worst security history, 4 years
These top 10 packages together totaled 79% of all the weighted vulnerabilities. The kernel, cups, php, krb5, and samba packages are part of the default installation of Enterprise Linux 4 AS.
2.5. Advisory Workload
In previous reports we’ve graphed the vulnerability workload, a measure of the number of vulnerabilities that security operations staff would need to worry about every day, weighted by severity. But the actual effort in maintaining an Enterprise Linux system is more related to the number of advisories we released, rather than the number of vulnerabilities: A single Firefox advisory may fix ten different issues of critical severity, but takes far less total effort to manage than ten separate advisories each fixing one critical Samba vulnerability.
Our Advisory Workload index gives a measure of the number of important advisories that users would need to worry about every day. The higher the number, the greater the workload, and the greater the general risk represented by the vulnerabilities addressed. This workload index is calculated in a similar way to the NIST workload index.
For a given month, Advisory Workload = weighted number of advisories  / days in the month. A workload of 1.0 would mean one important advisory a day.
Figure 5. Advisory Workload
Figure 5 shows the advisory workload index for a installation of Enterprise Linux 4 including every package. The initial peak during the first month looks surprising, but is easily explained, as the packages for Enterprise Linux 4 had a code freeze a few months prior to release. This led to a backlog of security issues that were fixed with updates on the date of release. The small peak in August 2005 aligns with the release of Update 1, and the other peaks align with Update releases or months during which there were several Firefox and SeaMonkey
The first part of this report analysed the total vulnerabilities found affecting Enterprise Linux 4. But to get a better evaluation of platform risk we also need to take into account the threat. This part therefore looks at
Red Hat is continually developing technologies to help reduce the risk of security threats, and a number of these were consolidated into Red Hat Enterprise Linux 4. The most significant technologies were SELinux and
An exploit is the way that an attacker makes use of a vulnerability. The Red Hat Security Response Team monitor numerous sources to track which vulnerabilities are being exploited. For this report we compiled a list of the publicly available exploits for the vulnerabilities that affected the first four years of Enterprise Linux 4.
We are interested in those exploits that have the potential to cause remote damage to the confidentiality or integrity of a system and we therefore don’t include exploits for vulnerabilities that are limited to a denial of service (affecting availability). We do, however, include exploits which are labeled “proof of concept”. A proof of concept exploit may only cause a crash or not quite work properly without modification, but in theory the vulnerability could be exploited properly leading to greater consequences. These proof of concept exploits often show techniques that a skilled attacker can turn into a full exploit.
We found exploits for 59 vulnerabilities for the first four years. 24 (40%) of these exploits are for buffer overflow vulnerabilities where in most cases the Exec-Shield technology should help prevent remote exploitation due to protections such as ASLR and enforcement of a non-executable stack.
3.1.1. Kernel exploits
The public exploits for the Linux kernel lead to one of two consequences: either a local unprivileged user can cause the machine to crash, or a local user can gain privileges.
We found exploits for nine vulnerabilities that had the potential to allow an unprivileged user to gain privileges on an unpatched Enterprise Linux 4 system. Of the nine, one required the target system to be using bluetooth drivers (CVE-2005-0750), another was exploitable only on systems with more than one CPU (CVE-2005-0001), one affected only x86_64 architectures (CVE-2007-4573), and one required a writable sgid directory (CVE-2008-4210).
The remainder (CVE-2006-3626, CVE-2006-2451, CVE-2005-0736, CVE-2004-1235, and CVE-2005-0531) could work on any default, unpatched system. Some of those exploits need unpublished source code adjustments in order to work against an Enterprise Linux 4 kernel.
3.1.2. Browser exploits
Table 6. Exploits for browser flaws
3.1.3. Other user-complicit exploits
The next class of exploits are those we term ‘user-complicit’, in that they need some involvement from the victim to be exploited. Some examples of user involvement would be opening a malicious file with a vulnerable application, or viewing an instant message from an unknown user. Table 7 lists the exploits we discovered that require some user involvement.
Table 7. Exploits for user-complicit flaws
3.1.4. PHP exploits
During March 2007 the “Month of PHP bugs” uncovered a number of issues, some of which affected the PHP packages as distributed with Enterprise Linux 4. The PHP interpreter does not offer a reliable sand-boxed security layer (as found in, say, a JVM) in which untrusted scripts can be run, so any script run by the PHP interpreter must be trusted with the privileges of the interpreter itself. Therefore, in analysis of these issues, exploits which relied on an “untrusted local attacker” were not classified as security-sensitive since no trust boundary was crossed.
This leaves us with the exploits shown in Table 8. These exploits rely on the victim having PHP scripts installed that use the vulnerable PHP functions in a particular way or with untrusted data. In each case the default SELinux targeted policy for Apache would restrict what a successful exploit is able to do.
Table 8. Exploits for PHP flaws
3.1.5. Servers and services exploits
Our final class of exploits are those that affect server applications and services, in Table 9. These are the most serious threats.
Table 9. Exploits for flaws in servers and services
Worms take advantage of vulnerabilities in order to compromise systems, then use the compromised system to seek out other systems to infect. By our definition, any vulnerability that could be exploited in this way would be classed as severity critical. In the first section of this report we listed every vulnerability that was rated as critical severity and showed that only a subset of those vulnerabilities could be actually used by worms. This is because we also class as critical some browser vulnerabilities where a victim has to take action (for example visiting a malicious web page) and therefore are not exploitable by a worm.
Worms affecting Linux platforms have been quite scarce in the last few years, and the anti-virus vendors who track malware recorded only two (although some variants of each exist) during the four year period of this study:
Without critical vulnerabilities to allow attackers to remotely exploit machines, we saw attackers instead try to focus on exploiting weak configurations. During the period of this study we tracked attempts by attackers to exploit machines with stolen passwords and brute-force password tools. The tools simply looked for internet-accessible SSH services they could connect to, then tried to log in with lots of combinations of common usernames and passwords. Restricting access to SSH remotely, moving the SSH daemon to a different port, and making sure all your users have strong passwords or use key authentication are all useful defenses against this particular attack.
The aim of this report was to get a measure of the security risk to users of Red Hat Enterprise Linux 4 during the first four years since release. We’ve shown that although on the surface it looks like Red Hat released a large number of security advisories, many of them do not apply to usual or default installations, and only a very small subset are a high risk. We’ve shown:
It would be foolish to draw conclusions about the future state of security in Red Hat Enterprise Linux 4 solely on the basis of this analysis of the past, however what we’ve tried to do is to enumerate the level of vulnerability and threat and hence overall platform risk. Red Hat treats vulnerabilities in our products and services seriously and the policies of the Red Hat Security Response Team are specifically designed to reduce the risk from security vulnerabilities:
All of the raw data used to generate the statistics in this report along with some tools to analyse them are available from the Red Hat Security Response Team. We also provide other tools and data that can help security measurement including CVE mappings for all our advisories and OVAL definitions.
5. Further Reading
6. About the author
 We count the first place that the security team heard about a security issue. ‘Peer vendors’ are other distributors of open source software who are part of vendor-sec. ‘Upstream relationship’ covers issues told to us because we work on the upstream
 To rank the riskiest packages we use a weighting of “Critical + Important/5 + Moderate/25 + Low/100″
 To weight the effort of dealing with advisories, Critical and Important advisories are scored as 1.00, Moderate advisories as 0.20, and Low advisories as 0.05. This is designed to be similar to the way that NIST calculate their workload metrics.
The script is installed correctly. Please login at seoslave.com to configure your website.
|Last Updated on Saturday, 20 June 2009 19:28|
|1.||Configuring VMware vCenter with SQL Server|
|2.||Red Hat Enterprise Linux Kernel Upgrade|
|3.||How Do I: Import Text Files with SQL Server Integration Services?|
|4.||How Do I: Using the HierarchyID Data Type in SQL Server 2008 to manage data hierarchies?|
|5.||Ubuntu Kernel Upgrade Procedure|