Rate this page del.icio.us  Digg slashdot StumbleUpon

Risk report: Two years of Red Hat Enterprise Linux 4

by

Red Hat® Enterprise Linux® 4 was released on February 15th, 2005. This report takes a look at the state of security for the first two 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 risk report published in the March 2006 issue of Red Hat Magazine[1].

1. Introduction
2. Vulnerabilities
2.1. Critical Flaws
2.2. Riskiest packages
3. Threats
3.1. Exploits
3.1.1. Kernel exploits
3.1.2. Browser exploits
3.1.3. Other user-complicit exploits
3.1.4. Servers and services exploits
3.2. Worms
4. Mitigation
5. Conclusion
6. Further Reading
7. About the Author

1. Introduction

The overall risk of running Enterprise Linux 4 is a function of two factors; the vulnerabilities and the threats. Our first section therefore covers the security vulnerabilities found in packages that are part of Enterprise Linux 4. 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 applies to Red Hat Enterprise Linux 4 AS from release day, February 15, 2005 through February 14, 2007 unless otherwise stated.

2. Vulnerabilities

At first sight it may appear that Red Hat released a lot of updates[2] over the last 24 months, publishing a total of 289 security advisories to address 713 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.

Tip
Cut down on the number of alerts you receive. Register your systems with the Red Hat Network to get customized notifications for security updates for the packages your systems have installed. If you want to see all security updates for every version and package, subscribe to the enterprise-watch-list mailing list[3] as well

With the release of Enterprise Linux 4, we started publishing severity levels with package errata to help users figure out 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[4] designed to be an at-a-glance guide to how worried Red Hat is about each security issue. The scale shown in Figure 1 and Table 1 takes into account the potential risk of a flaw based on a technical analysis of the exact flaw and its type, but not the current threat level. Therefore the rating given to an issue will not change if an exploit or worm is later released for a flaw.

Low severity issues are the least impact, followed by moderate, then important, through to critical having the most impact

Figure 1. Severity scale

Impact Description
Critical This rating is given to flaws that could be easily exploited by a
remote unauthenticated attacker and lead to system compromise
(arbitrary code execution) without requiring user interaction. These
are the types of vulnerabilities that can be exploited by worms.
Important This rating is given to flaws that can easily compromise the
confidentiality, integrity, or availability of resources. These are
the types of vulnerabilities that allow local users to gain
privileges, allow unauthenticated remote users to view resources that
should otherwise be protected by authentication, allow authenticated
remote users to execute arbitrary code, or allow local or remote users
to easily cause a denial of service.
Moderate This rating is given to flaws that may be harder or more unlikely to
be exploitable but given the right circumstances could still lead to
some compromise of the confidentiality, integrity, or availability of
resources.
Low This rating is given to all other issues that have a security
impact. These are the types of vulnerabilities that are believed to
require unlikely circumstances to be able to be exploited, or where a
successful exploit would give minimal consequences.
Table 1. Severity Rating

We measure the number of vulnerabilities customers need to deal with using two metrics: the number of critical vulnerabilities, and the vulnerability workload index.

The vulnerability workload index[5] gives a measure of the number of important vulnerabilities that security operations staff 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. This workload index is calculated in a similar way to the workload index from NIST[6].


A graph showing the workload index decrease from an initial high to a low average over the two years

Figure 2. Vulnerability Workload for Enterprise Linux 4 AS full install

Figure 2 shows the workload index for a full installation of Enterprise Linux 4 AS. 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. There is also a peak around August 2006 due mostly to a large number of vulnerabilities fixed in an updated version of Firefox, and the replacement of the Mozilla browser with SeaMonkey[7].

An interesting observation you can make from this graph is that the number of weighted vulnerabilities has no particular upward trend; isn’t increasing over time.

During Enterprise Linux 4 installation, the user gets a choice[8] of installing either the default selection of packages, or making a custom selection. Table 2 shows that a default install of Enterprise Linux 4 AS[9] was only vulnerable to 3 critical flaws. This is because most of the critical flaws have been in web browsers or 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 53 default critical vulnerabilities. A non-default installation of AS, selecting every available package, would yield a system with the maximum possible number of critical vulnerabilities for the two years, 60.

Severity Enterprise Linux 4 AS, default install Enterprise Linux 4 WS, default install Enterprise Linux 4 AS (all possible packages)
Critical 3 53 60
Important 160 189 225
Moderate 117 161 276
Low 82 82 152
Total 362 485 713
Table 2. Number of vulnerabilities for each severity

For the purposes of these metrics we consider the worst case scenario, a version of Red Hat Enterprise Linux 4 obtained on the day of release. During the first two years four Update releases were made (Update 1 in June 2005, Update 2 in October 2005, Update 3 in March 2006, Update 4 in August 2006). The Update releases are similar to a service pack and contain a roll-up of all security advisories to date. So for example, a user who installed Enterprise Linux 4 Update 4 would be vulnerable only to a subset of the issues.

2.1. 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.

To help examine the risk we’ll split the critical vulnerabilities into two categories: 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 could be exploited by a worm).

Table 3 itemizes the critical non-browser vulnerabilities for a full install of Enterprise Linux AS, whilst Table 4 summarises for all issues rated critical.

Package Default Install? References Description “Days of Risk”
sendmail Yes CVE-2006-0058 RHSA-2006:0264 A flaw in the handling of asynchronous signals was discovered in Sendmail. A remote attacker may be able to exploit a race condition to execute arbitrary code as root. 0
mod_auth_pgsql No CVE-2005-3656 RHSA-2006:0164 Several format string flaws were found in the way mod_auth_pgsql logs information. It may be possible for a remote attacker to execute arbitrary code as the ‘apache’ user if mod_auth_pgsql is used for user authentication. 0
gaim No CVE-2005-2103 RHSA-2005:627 A heap based buffer overflow issue was discovered in the way Gaim processes away messages. A remote attacker could send a specially crafted away message to a Gaim user logged into AIM or ICQ that could result in arbitrary code execution. 2
kopete Yes CVE-2005-1852 RHSA-2005:639 Multiple integer overflow flaws were found in the way Kopete processes Gadu-Gadu messages. A remote attacker could send a specially crafted Gadu-Gadu message which would cause Kopete to crash or possibly execute arbitrary code 1
gaim No CVE-2005-1261 RHSA-2005:429 A stack based buffer overflow bug was found in the way gaim processes a message containing a URL. A remote attacker could send a carefully crafted message resulting in the execution of arbitrary code. 0
Table 3. Non-browser critical flaws (Enterprise Linux 4 AS first two years, all packages)

Type Number of vulnerabilities “Days of Risk” Fix within one day
Mozilla products (Firefox, Mozilla, SeaMonkey, Thunderbird) 44 3 75%
Media Player Plugins (HelixPlayer) 6 1.5 83%
Other browser (Lynx, Links, KDE, Qt) 5 1.2 80%
Non-Browser (see table 3) 5 0.6 80%
Total 60 3 75%
Table 4. All critical flaws (Enterprise Linux 4 AS first two years, all packages)

From time to time, research reports rate the response times of vendors with a “days of risk” metric. This is the number of days it takes for a vendor to produce a patch for a vulnerability after the patch is first known to the public.

The data in Table 3 shows that fixes for 100% of the critical flaws were available from Red Hat Network within two calendar days of public
disclosure of the vulnerability. 60% of the critical flaws were fixed on the very same day. This fast response time is deliberate and forms an
essential part of reducing customer risk from these critical vulnerabilities.

The “days of risk” metric has it’s limitations and it isn’t particularly useful for comparing different software vendors against each other. Because the software in Enterprise Linux 4 is open source we’re likely not to be the only company shipping each particular application. So unlike other commercial companies, Red Hat is not in sole control over the date the issue is made public. This is actually a good things and leads to much shorter response times between issues being first reported to being made public. It also means Red Hat can’t try to artificially reduce our “days of risk” statistics by using tactics such as holding off disclosure of important issues for a long period until a regularly scheduled patch day.

2.2. Riskiest packages

It sometimes seems like we produce a security advisory for some packages every month; Indeed, a quick scan of the list of security updates shows a few packages appear again and again. We therefore analysed Enterprise Linux 4 to find out which packages we responsible for the most vulnerabilities. We weighted the vulnerabilities[10] to take into account their severity.

Rank (vs last year) Package Critical Important Moderate Low
1 (was 3) mozilla/seamonkey 44 21 37 8
2 (-) firefox 42 30 40 9
3 (was 5) thunderbird 22 22 38 4
4 (was 1) kernel 0 83 42 17
5 (was 4) HelixPlayer 7 6 0 1
6 (-) gaim 2 6 3 2
7 (-) cups 0 15 2 0
8 (new entry) kdelibs 2 3 3 1
9 (-) kdegraphics 0 13 1 0
10 (was 8 ) xpdf 0 12 1 0
Table 5. Top 10 packages with the worst Enterprise Linux 4 security history

Table 5 shows the top 10 packages which in total counted for 80% of all the weighted vulnerabilities. Only the kernel and cups are part of the default installation of Enterprise Linux 4 AS.

We often do security updates for ethereal/wireshark, and although that package had 75 vulnerabilities through the two years, they were all moderate or low severity and therefore the overall weighted risk kept it out of the top 10.

Tip
Reduce the number of security alerts that apply to your system by removing packages that you don’t need, particularly those that have the worst security history. When installing a new system, carefully choosing the right Enterprise Linux variant and package set to match the task will cut down on the number of issues that apply to your system.

3. Threats

The first section of this paper analysed the total vulnerabilities found affecting the platform. But to get an estimation of risk we also need to take into account the threat. This section therefore looks at exploits and worms written to exploit those vulnerabilities.

3.1. Exploits

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 available exploits for the vulnerabilities that affected the first two years of Enterprise Linux 4.

We are interested in those exploits that have the potential to cause damage to the confidentiality or integrity and we don’t include exploits for vulnerabilities that are limited to denial of service (affecting availability). We do however include exploits which are labeled “proof of concept” (where the published exploit may only cause a crash or doesn’t quite work properly but in theory the vulnerability if exploited properly could lead 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 37 vulnerabilities for the first two years of vulnerabilities. Just over half of the exploits are for buffer overflows vulnerabilities where in most cases the Exec-Shield technology should help prevent remote exploitation of these vulnerabilities due to both the randomisation and enforcement of a non-executable stack.

3.1.1. Kernel exploits

The subset of vulnerabilities affecting the Linux kernel mostly 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 seven vulnerabilities that had the potential to allow an unprivileged user to gain privileges on an un-patched Enterprise Linux 4 system. Of the seven, one required the target system to be using bluetooth drivers (CVE-2005-0750), and another was exploitable only on systems with more than one CPU (CVE-2005-0001).

The remainder (CVE-2006-3626, CVE-2006-2451, CVE-2005-0736, CVE-2004-1235, and CVE-2005-0531) could work on any un-patched system.
Some of those exploits needed code adjustments in order to work against an Enterprise Linux 4 kernel.

3.1.2. Browser exploits

Over a third of the public exploits we found were for flaws in web browsers; and all but two targeted the Mozilla suite (Mozilla, Firefox, Thunderbird). These are detailed in Table 6. For each exploit, any resultant code execution would be limited to being run with the same rights as the user that is running the vulnerable browser. It is best practice to never use a web browser or graphical email client as root.

Vulnerabilities Description
CVE-2005-0399 An exploit for a flaw where a malicious GIF image could cause an overflow. This issue is more serious in Thunderbird, where opening a malicious email could trigger this flaw.
CVE-2006-0295, CVE-2005-2871 Exploits for flaws where a malicious web page could run arbitrary code. The public exploit for CVE-2005-2871 was designed for Windows
platforms, exploiting this flaw on Linux would require different techniques.
CVE-2005-1476, CVE-2005-1531, CVE-2005-2264, CVE-2005-1160, CVE-2005-1155, CVE-2005-1157 Exploits for flaws where a malicious web page could run arbitrary JavaScript, doing things like changing home pages, stealing cookies, cross-site scripting, or creating files on the system.
CVE-2005-2262, CVE-2005-2269 Exploits for two user-complicit overflow flaws that require the victim to use the ‘set as wallpaper’ option on a malicious image.
CVE-2006-3677 An exploit for a JavaScript code flaw. This could result in the execution of arbitrary code if a victim visits a malicious website.
CVE-2005-3120 An exploit in the Lynx optional text-based browser. The public exploit is a proof of concept only.
CVE-2006-5925 An exploit in the Links text web browser which could allow arbitrary commands to be executed if a victim visits a malicious web site.
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 a user 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.

Vulnerabilities Description
CVE-2005-3243, CVE-2005-2367, CVE-2005-1461, CVE-2005-0699 Exploits for several vulnerabilities in Ethereal/Wireshark. In order to be exploited a victim with privileges (root) would have to be running Ethereal and monitoring a network onto which an attacker could inject carefully crafted malicious packets. The protocols affected by the vulnerabilities (SLIMP3, AFP, SIP, and RADIUS) are unlikely to be allowed through a border firewall, so the ability to exploit this flaw remotely is restricted. Additionally, attempts to remotely exploit these flaws would be caught by Exec-Shield.
CVE-2005-2710 An exploit for a format-string vulnerability in HelixPlayer. An attacker could create a carefully crafted media file that would execute arbitrary code when opened by a victim. Since HelixPlayer can be embedded within a web browser, this flaw could be triggered by a victim simply visiting a malicious web page. Any code execution would however be limited to being run with the same rights as the user that is running the vulnerable browser.
CVE-2005-1261 An exploit for a flaw in the Gaim instant-messaging client. For some instant messaging protocols, an attacker could send a carefully crafted message which could trigger the flaw and cause code execution. The public exploit is only a proof of concept and causes a crash. In addition, attempts to remotely exploit this flaw should be caught by Exec-Shield.
CVE-2005-0156 An exploit for a flaw in the setuid Perl package. Where perl-setuid is installed, an unprivileged local user could gain root privileges. The
exploit as published needs minor changes to work on un-patched Enterprise Linux 4 systems.
CVE-2006-2656 An exploit for a flaw in libtiff. If an attacker can force a victim to run the ‘tiffsplit’ executable with a malicious filename they could cause code to run as that user. This is a low severity flaw as nothing we ship would run ‘tiffsplit’ with an arbitrary filename.
CVE-2006-1542 An exploit for a flaw in Python. This is a low severity issue as the user would need to be tricked into running python with a very long script name, an unlikely scenario.
CVE-2005-1704 An integer overflow can allow a carefully crafted executable to execute arbitrary code. This is low severity as you need to convince the victim to run your malicious binary (and any malicious binary could perform arbitrary actions anyway).
Table 7. Exploits for user-complicit flaws

3.1.4. Servers and services exploits

Our final class of exploits are those that affect server applications and services, in Table 8. These have the potential to be the most serious threats.

Vulnerabilities Description
CVE-2005-0022 An exploit for a buffer overflow in the Exim mail server. A remote attacker could trigger this vulnerability and execute arbitrary code as the ‘exim’ unprivileged user. In order to exploit this vulnerability the non-default Exim mail server needs to be installed and SPA authentication specifically enabled, which is not a usual configuration. Attempts to remotely exploit this flaw should also be caught by Exec-Shield.
CVE-2005-1921, CVE-2005-2498 Two exploits for flaws in the PHP PEAR XML-RPC code. These exploits require a server to be running a third-party PHP application that
exports an XML-RPC interface. A successful exploit will cause arbitrary PHP commands to be executed as the ‘apache’ user. The default SELinux targeted policy for Apache will restrict what a successful exploit is able to do.
CVE-2005-0710, CVE-2005-0709 Two exploits for flaws in the MySQL server. A remote authenticated user with privileges to insert or delete from a database table could execute arbitrary code on the MySQL server as the unprivileged ‘mysql’ user. The default SELinux targeted policy for MySQL would restrict
what a successful exploit is able to do.
CVE-2006-4020 Two exploits for a flaw in the PHP sscanf() function. If a PHP script was installed that passed data under an attackers control to sscanf() it could result in a buffer overflow. This was low severity as this is an unlikely scenario, and the default SELinux targeted policy for Apache would restrict what a successful exploit is able to do.
Table 8. Exploits for flaws in servers and services
Tip
The way to reduce your risk from exploits is to make sure your systems have all applicable security updates installed. The Red Hat Network can help keep track of this.

3.2. Worms

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 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 during the two year period of this study:

  • Linux/MARE was discovered in November 2005 and was a worm that spread by exploiting a flaw in PHP-Nuke. PHP-Nuke is not shipped as part of Red Hat Enterprise Linux.
  • Linux/Lupper was discovered in December 2005 and was a worm designed to exploit CVE-2005-1921[11], a flaw in the PHP PEAR XML-RPC server package exploitable through a number of third party PHP applications. None of the affected third-party applications were shipped as part of of Red Hat Enterprise Linux. Additionally, a PHP update in July 2005 fixed the underlying vulnerability. Users that had not patched were also protected from this worm by the default SELinux configuration.

Without common vulnerabilities to allow attackers to remotely exploit machines, we saw them instead try to focus on exploiting weak configurations. During the period of this study we tracked attempts by attackers to exploit machines with brute-force password tools. The
tools simply looked for open SSH services they could connect to, then tried to log in with lots of combinations of possible 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 are all useful defenses.

4. Mitigation

Red Hat is continually developing technologies to help reduce the risk of security vulnerabilities, and a number of these were consolidated into Red Hat Enterprise Linux 4. The most significant technologies were SELinux and Exec-Shield. Exec-Shield is a project which includes support for the No eXecute (NX) memory permission, simulating NX via segment limits, Position Independent Executables (PIE), gcc, and glibc hardening. Table 9 lists the major security technology innovations in Enterprise Linux 3 and 4.

Part of hardening added to glibc included checks which prevent the exploitation of a “double-free”, a particular programming flaw which can sometimes be exploitable (it depends a lot on how the vulnerable application is written). In 2003 this flaw type led to some high-profile exploits of services such as wu-ftpd and CVS pserver.

In August 2004, the first double-free security flaw in Enterprise Linux 4 was announced[12] affecting the MIT Kerberos 5 Key Distribution Center application. For Enterprise Linux 4 users we were able to downgrade the severity of this flaw from critical as the glibc hardening totally prevented the exploitation of this double-free flaw.

Feature Enterprise Linux 3 Enterprise Linux 4
Digitally signed updates required by default Yes Yes
NX emulation using segment limits by default Yes, since Sep 2004 Yes
Support for Position Independent Executables (PIE) Yes, since Sep 2004 Yes
ASLR for Stack/mmap by default Yes, since Sep 2004 Yes
ASLR for vDSO (if vDSO enabled) NA Yes
Restricted access to kernel memory by default Yes
NX for supported processors/kernels by default Yes, since Sep 2004 Yes
SELinux with targetted policies enabled by default Yes
glibc heap/memory checks by default Yes
Support for FORTIFY_SOURCE, used on selected packages Yes
Support for ELF Data Hardening Yes
CVE compatible Yes Yes
OVAL compatible Yes, since May 2006 Yes, since May 2006
Table 9. Red Hat Enterprise Linux Security Features

5. Conclusion

The aim of this report was to look at the security risk to users of Red Hat Enterprise Linux 4 during the first two years from 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:

  • A default installation of Enterprise Linux 4 AS was vulnerable to only 3 critical security issues in the whole two years
  • A customized installation of Enterprise Linux 4, selecting every package, would have been vulnerable to 55 critical browser security issues, and 5 in non-browser packages in the two years. 75% of those vulnerabilities had fixes available from the Red Hat Network within one day of them being known to the public
  • We found public exploits for 37 vulnerabilities that could have affected a customized full installation; although the majority relied on user interaction. Attempts to use many of the exploits would be caught by standard Enterprise Linux 4 security innovations
  • The most likely successful exploits allowed a local unprivileged user to gain root privileges on an un-patched Enterprise Linux 4 machine
  • Two worms targeting Linux systems were found during the two years, but both affected third party PHP applications not shipped in Red Hat Enterprise Linux 4. In addition, an update to PHP released over three months before one of the worms was released protected systems that had installed the third party applications

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:

  • We place an emphasis on providing the fastest possible, highest quality, turnaround for critical vulnerabilities. We have a global security response team which can draw on significant development and Quality Engineering resources to get things fixed quickly
  • We release updates for critical and important security issues as soon as possible rather than batching them into monthly or quarterly updates
  • We give transparency in our handling of vulnerabilities, our methods, and our metrics

All of the raw data used to generate the statistics in this report along with some tools to analyse them are available[13] from the Red Hat Security Response Team and updated regularly. We also provide other tools and data that can help security measurement including CVE mappings on all our advisories and OVAL definitions.

6. Further Reading

7. About the author

Mark Cox is Director of the Red Hat Security Response Team. Over the last 12 years, Mark has developed software and worked on the security teams of some of the most popular open source projects including Apache, mod_ssl, and OpenSSL. Mark is a founding member of the Apache Software Foundation and the OpenSSL project, and a board member of the Mitre Common Vulnerabilities and Exposure project. In his spare time he finds geocaches [14] with his family in Scotland.


[1] http://www.redhat.com/magazine/017mar06/features/riskreport/

[2] http://rhn.redhat.com/errata/rhel4as-errata.html

[3] Get notified of new security issues

[4] http://www.redhat.com/security/updates/classification/

[5] For a given date, Vulnerability workload = ((number of critical and important severity vulnerabilities published within the last month) + (number of moderate severity vulnerabilities published within the last month/5) + (number of low severity vulnerabilities published within the last month/20)) / (days in the month)

[6] http://nvd.nist.gov/nvd.cfm?workloadindex

[7] http://rhn.redhat.com/errata/RHSA-2006-0609.html

[8] http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/x8664-multi-install-guide/s1-pkgselection.html

[9] 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.

[10] To rank the riskiest packages we use a weighting of “Critical + Important/5
+ Moderate/25 + Low/100″

[11] CVE-2005-1921

[12] http://web.mit.edu/kerberos/advisories/MITKRB5-SA-2004-002-dblfree.txt

[13] http://people.redhat.com/mjc/

[14] http://www.geocaching.com/

9 responses to “Risk report: Two years of Red Hat Enterprise Linux 4”

  1. midi-man says:

    Nice article I would have like a side by side comparison with windows it might have been a nice think to have to see which OS is better at security.

  2. Mark Cox says:

    Various reports have tried to compare operating systems from different vendors, some by comparing numbers of vulnerabilities, others looking at days of risk, some recent ones even written by the competing vendor themselves. You can pretty much get whatever results you like from such comparisons by simply carefully choosing the initial conditions or ignoring differences in disclosure and policies. I think it’s far more useful to let RHEL4 users get a good picture of the risk they faced, and with our raw data available they can tailor it to their environment and way they use RHEL4. For example we treat an issue as severity important if an local user can cause a machine to crash, but if you are in an environment where that isn’t an issue (maybe you don’t have untrusted local users or maybe crashes are not a big deal) then you can rerun our stats accordingly.

  3. Colin Wilson says:

    This is a very well constructed summary. It is both informative and objective, and sets the standard for what to expect from any OS vendor. Thank you for doing such a professional job on it.

  4. jason andrade says:

    Will there be a risk report for RHEL3 also ? It would be extremely useful to have this sort of report being released annually for each of the main releases (3/4/5).

    -j

  5. Mark Cox says:

    It is actually interesting to look at RHEL3. Because of our policy of backporting security fixes where possible, as the distribution gets older we are affected by a lower proportion of vulnerabilities: RHEL3 in its 3.4 years has only had 3 more critical vulnerabilities than RHEL4 in its 2 years. I’ll look at doing a summary this year, or at least “4 years of RHEL3″ by November, thanks for the feedback.

  6. Eric Feldhusen says:

    Another interesting metric would be to see how a “minimal” install does for security. Most of my RHEL3/4/5 servers are done with a minimal install specifically for security reasons.

  7. Peter K says:

    First I’d like to say thank you for a very well written summary. I’m looking forward to future summaries (EL5 one yesr, EL3, EL4 3 or 4…).

    I also found the security feature table interesting. It would have been great to have a column for EL5.

  8. Steven Pass says:

    The title of the report is “Risk report: Two years of Red Hat Enterprise Linux 4″. It’s only toward the end where it states that the report was for “security risks”.
    There was a lot of talk about updates for security and vunerabilities. What about updates for stability issues? Updates due to coding issues, memory leaks, etc. For an enterprise, these are also “risks” in deciding to use Red Hat.

  9. Prashant says:

    Very use full document for risk mang.