Risk report: Three years of Red Hat Enterprise Linux 4
by Mark Cox
This report is an update to the risk report published in Red Hat Magazine in April 2007.
Red Hat® Enterprise Linux® 4 was released on February 15th, 2005.
This report takes a look at the state of security for the first three
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.
- 1. Introduction
- 2. Vulnerabilities
- 3. Threats
- 4. Mitigation
- 5. Conclusion
- 6. Further Reading
- 7. About the Author
1. Introduction
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 2008 unless otherwise stated.
2. Vulnerabilities
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 145 security advisories to address 302 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.
2.1. Severity Levels
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. 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.
| 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. |
2.2. 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.
| Severity | Enterprise Linux 4 AS default install |
Enterprise Linux 4 WS default install |
Enterprise Linux 4 AS all possible packages |
|---|---|---|---|
| Critical | 7 | 83 | 87 |
| Important | 224 | 270 | 303 |
| Moderate | 175 | 266 | 388 |
| Low | 127 | 148 | 241 |
| Total | 533 | 767 | 1019 |
A default install of Enterprise Linux 4 AS was only vulnerable to 7 critical flaws in the whole three 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 83 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 three years, 87.
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 three years, five 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). 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 December 2008 would use Update 6 and be affected by only a subset of the issues.
- Tip
- You can cut down the number of security issues you need to deal
with by carefully choosing the right Enterprise Linux variant and
package set
when deploying a new system, and ensuring you install the latest available Update release.
2.3. 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’ve ignored 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 our 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 thus could 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.
| Type | Number of flaws | “Days of Risk” | Fix within one day |
|---|---|---|---|
| Mozilla products (Firefox, Mozilla, SeaMonkey, Thunderbird) | 64 | 2.2 | 81% |
| Media Player Plugin (HelixPlayer) | 7 | 1.4 | 85% |
| Other browsers (Lynx, Links, KDE, QT) | 5 | 1.2 | 80% |
| Non-Browser (see Table 4) | 11 | 0.9 | 82% |
| Total | 87 | 2.0 | 81% |
| Package affected | Default Installed? | References | Description | “Days of Risk” |
|---|---|---|---|---|
| samba | Yes | CVE-2007-6015 RHSA-2007:1114 |
Stack-based buffer overflow if the “domain logons” option is enabled. | 0 |
| samba | Yes | CVE-2007-5398 RHSA-2007:1016 |
Stack-based buffer overflow if operating as a WINS server. | 0 |
| samba | Yes | CVE-2007-2446 RHSA-2007:0354 |
Heap-based buffer overflows in Samba. | 0 |
| krb5 | Yes | CVE-2007-0956 RHSA-2007:0095 |
The krb5 telnet daemon, if enabled, allowed remote attackers to bypass authentication | 0 |
| sendmail | Yes | CVE-2006-0058 RHSA-2006:0264 |
A remote attacker could exploit a race condition in the handling of asynchronous signals. | 0 |
| kopete | Yes | CVE-2005-1852 RHSA-2005:639 |
A remote attacker could send a specially crafted Gadu-Gadu message and trigger an integer overflow | 1 |
| tog-pegasus | No | CVE-2008-0003 RHSA-2008:0002 |
A stack-based buffer overflow in the OpenPegasus CIM management server. | 0 |
| gnomemeeting | No | CVE-2007-1007 RHSA-2007:0086 |
Format string vulnerability in GnomeMeeting | 7 |
| mod_auth_pgsql | No | CVE-2005-3656 RHSA-2006:0164 |
Several format string flaws if mod_auth_pgsql is used for user authentication. | 0 |
| gaim | No | CVE-2005-2103 RHSA-2005:627 |
A remote attacker could send a specially crafted away message to a Gaim user logged into AIM or ICQ and trigger a buffer overflow. | 2 |
| gaim | No | CVE-2005-1261 RHSA-2005:429 |
A remote attacker could send a message with a carefully crafted URL and trigger a buffer overflow. | 0 |
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 81% of critical flaws were available from Red Hat Network
at latest one calendar day after public disclosure of the flaw. 63% of
the critical flaws were fixed on the very same day. 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.4. 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 “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 1019 total vulnerabilities, across every package in Enterprise Linux in the 3 years, we determined if the flaw was something we knew about in advance (if the date it went public was after the date we were told about the issue), and how we found out [3] about the flaw. The results are summarised in Figure 2 and Figure 3.
Red Hat knew about 49% of the security vulnerabilities that we fixed 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 8 days or less. Figure 4 shows the distribution of notice periods in more detail.
2.5. 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 responsible for the most vulnerabilities, weighting them [2] to take into account their severity. The results are shown in Table 5, which lists the top 10, ranked across all three years as well as a comparison to the rank found in the last risk report.
| Rank (vs last year) | Package | Critical | Important | Moderate | Low |
|---|---|---|---|---|---|
| 1 (-) | mozilla/seamonkey | 64 | 22 | 62 | 15 |
| 2 (-) | firefox | 61 | 31 | 64 | 16 |
| 3 (-) | thunderbird | 41 | 22 | 59 | 10 |
| 4 (-) | kernel | 0 | 101 | 54 | 26 |
| 5 (-) | HelixPlayer | 7 | 0 | 1 | 0 |
| 6 (was 7) | cups | 0 | 20 | 3 | 1 |
| 7 (new entry) | php | 0 | 14 | 20 | 21 |
| 8 (new entry) | samba | 3 | 2 | 3 | 0 |
| 9 (-) | kdegraphics | 0 | 17 | 1 | 0 |
| 10 (was 6) | gaim | 2 | 6 | 3 | 2 |
These top 10 packages together totaled 78% of all the weighted vulnerabilities. The kernel, cups, php, and samba packages are part of the default installation of Enterprise Linux 4 AS.
- Tip
- You can reduce the number of vulnerabilities that will affect your systems by removing packages that you don’t need or don’t use, particularly those that have the worst security history.
2.6. Advisory Workload
In our previous reports we 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. Feedback suggested that the actual effort in maintaining an Enterprise Linux system was 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 vulnerability.
The Advisory Workload index gives a measure of the number of important advisories 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 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 [1] / days in the
month. A score of 1.0 would mean one important advisory a day.
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 peak in November-December 2007 were due to Update 6 coinciding with several Firefox and SeaMonkey updates.
- Tip
- Cut down on the number of alerts you receive. Register your systems
with the Red Hat Network to get customised 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 as well
3. Threats
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 exploits and worms written to take advantage of the 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 publicly available exploits for the vulnerabilities that affected the first three 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 49 vulnerabilities for the first three years of vulnerabilities. Around half of the exploits are for buffer overflow vulnerabilities where in most cases the Exec-Shield technology should help prevent remote exploitation due to randomisation and enforcement of a non-executable stack.
3.1.1. Kernel exploits
The subset of vulnerabilities that affected 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 eight vulnerabilities that had the potential to allow an unprivileged user to gain privileges on an un-patched Enterprise Linux 4 system. Of the eight, 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), and one affected only x8_64 architectures (CVE-2007-4573).
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
Nearly 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 email client as root. Some of these exploits are also blocked if JavaScript is disabled.
| 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-2007-0981 | An exploit that can bypass the same-origin policy, allowing cookie or cross-domain attacks. |
| 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-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. |
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.
| 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 would have to be analysing network packets using Wireshark from a network into 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-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). |
| CVE-2006-2356 | An exploit for a flaw in the Gimp image editor. If an attacker can force a victim to run the Gimp on a malicious image they could execute arbitrary code as the victim. |
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 six exploits from the month of bugs, and two from previous years, 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.
| Vulnerabilities | Description | |
|---|---|---|
| CVE-2007-1286 | Exploit for a flaw in the unserialize function which could lead to arbitrary code execution as the apache user. Although unserialize is used by some PHP scripts with untrusted data, the input string required to exploit this issue must exceed ~512K in length, so default Apache line length limits will prevent this from being remotely exploited via input data carried in the HTTP request headers or URI. | |
| CVE-2007-1287 | Exploit for a cross-site-scripting issue in the phpinfo function. Generally, the phpinfo function should never be used in publicly-accessible PHP scripts. | |
| CVE-2007-1701 | Exploit for a flaw in the session extension which allows super-globals to be over-ridden by an attacker, exploitable if session data is taken from an untrusted source. | |
| CVE-2007-1718 | Exploit for a flaw in the mail function which could allow a remote attacker to inject arbitrary headers into PHP generated mail if the mail Subject comprises of user-supplied data. | |
| CVE-2007-1885 | Exploit for an integer overflow the str_replace function, which can be triggered remotely if a script passes large untrusted strings to particular arguments of this function. |
|
| CVE-2007-0906 | Exploit for a heap overflow in the imap_mail_compose function, which can be triggered if a script uses the function to create a new MIME message based on an input body from an untrusted source | |
| CVE-2006-4020 | Exploits for a flaw in the sscanf function. If a PHP script passed data under an attackers control to sscanf it could result in a buffer overflow. | |
| CVE-2005-1921, CVE-2005-2498 | Exploits for flaws in the 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. |
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.
| Vulnerabilities | Description |
|---|---|
| CVE-2007-2926 | BIND was found to have weak random number generation. An exploit was released to use this flaw to poison the DNS cache. |
| CVE-2007-0957 | An exploit for a buffer overflow in the Kerberos administration daemon. A remote authenticated user could execute arbitrary code as root on the Kerberos server. Attempts to remotely exploit this flaw should be caught by Exec-Shield. |
| CVE-2007-6015 | An exploit for a buffer overflow in Samba. In order to exploit this
flaw, the “domain logons” option would need to be enabled. Attempts to remotely exploit this flaw should also be caught by Exec-Shield. |
| CVE-2005-0022 | A remote exploit for a buffer overflow in the non-default Exim mail server which could lead to arbitrary code execution as the ‘exim’ unprivileged user. In order to exploit this vulnerability, Exim 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-0710, CVE-2005-0709 | 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. |
- 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 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 during the three 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, 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 Red Hat Enterprise Linux. Additionally, a PHP update in July 2005 fixed the underlying flaw in PHP. Even users that had not patched were also protected from this worm by the default SELinux configuration.
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.
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 10 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 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 prevented the exploitation of this double-free flaw. Since then several other similar flaws were mitigated.
| 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 targeted 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 |
5. Conclusion
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 three 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:
- A default installation of Enterprise Linux 4 AS was vulnerable to seven critical security issues over the first three years
- A customised installation of Enterprise Linux 4, selecting every
package, would have been vulnerable to 76 critical browser security
issues, and 11 in non-browser packages in the three years. 81% of those
vulnerabilities had fixes to correct them available from the Red Hat
Network within one
calendar day of them being known to the public - Red Hat knew about 49% of security issues affecting the first three years of Enterprise Linux 4 in advance. The average time between Red Hat knowing about an issue and it being made public was 21 days (median 8 days)
- We found public exploits for 49 vulnerabilities that could have affected a customised 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 three 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 Security Response Team distributed globally which can draw on significant Engineering and Quality resources to get the things that matter the most 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 provide transparency in the 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 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.
6. Further Reading
- What’s new in security for Red Hat Enterprise Linux 4
- Vulnerability Types for Enterprise Linux 4
- Security Features in Red Hat Enterprise Linux and Fedora Core
- SELinux: A New Approach to Secure Systems
- Red Hat Enterprise Linux 4 Security Guide
- Statistics and data from the Security Response Team
7. About the author
Mark J Cox is Director of the Red Hat Security Response Team and is based in Scotland. Over the last 13 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 with his family.
[1] 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 do their workload metrics.
[2] To rank the riskiest packages we use a weighting of “Critical + Important/5 + Moderate/25 + Low/100″
[3] 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 projects or they mailed us to tell us about an issue. ‘Red Hat discovered’ are issues Red Hat staff discovered. ‘Red Hat notified’ are where some customer, researcher, or other third party told us about an issue through email, bugzilla, or other means. ‘Security Lists’ includes public lists like Bugtraq and Full-Disclosure, and ‘CVE feed’ is the feed from Mitre when they allocate CVE names to public issues.