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.
The 12 critical advisories addressed 49 critical vulnerabilities across just 3 different packages:
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.
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.
See also: 5.4 to 5.5, 5.3 to 5.4, 5.2 to 5.3, 5.1 to 5.2, and 5.0 to 5.1 risk reports.
Hold on a second. It might be important. I'd better go and read it. Oh it's just a note confirming some meeting for next week. Deleted. Now, what was I working on?
A few years ago, when I was analysing where my time was going, (and why I was working 60+ hour weeks), I figured out that the context switching caused by being unable to concentrate on a task for more than a few minutes was a major productivity drain.
It's hard to resist a new email. My new cellphone takes great delight in having 'push' email and would really like to beep on each new message I receive. The web is full of gmail notifier applications designed specifically to interrupt you to some important new mail. Even my favourite command-line email client, Alpine, likes to ping you about new mail arriving in your inbox even if you're busy in some other mailbox or composing a mail.
Alpine ought to have some sort of "don't notify me" option, but in the meantime I apply the brute-force patch below to disable it.
This 5-minute patch has saved me several hours of task switching every week, and although this means it can sometimes be an hour or two between me checking my inbox, no one has really noticed.
--- alpine-2.00/pith/newmail.c.orig 2010-07-19 16:47:01.127480500 +0100 +++ alpine-2.00/pith/newmail.c 2010-07-19 16:47:35.657602347 +0100 @@ -680,7 +680,7 @@ } format_new_mail_msg(folder, number, e, intro, from, subject, subjtext, sizeof(subject)); - +#if 0 if(!for_new_mail_win) q_status_message5(SM_ASYNC | SM_DING, 0, 60, "%s%s%s%.80s%.80s", intro, @@ -706,6 +706,7 @@ #endif } #endif +#endif if(pith_opt_icon_text){ if(F_ON(F_ENABLE_XTERM_NEWMAIL, ps_global)
Between releases there are lots of changes made to improve security and we've not listed everything; just a high-level overview of the things we think are most interesting that help mitigate security risk. We could go into much more detail, breaking out the number of daemons covered by the SELinux default policy, the number of binaries compiled PIE, and so on.
Note that this table is for the most common architectures, x86 and x86_64 only; other supported architectures may vary.
Features | Red Hat Enterprise Linux | |||
3 | 4 | 5 | 6 | |
2003 Oct | 2005 Feb | 2007 Mar | 2010 Nov | |
Firewall by default | Y | Y | Y | Y |
Signed updates required by default | Y | Y | Y | Y |
NX emulation using segment limits by default | Y(since 9/2004) | Y | Y | Y |
Support for Position Independent Executables (PIE) | Y(since 9/2004) | Y | Y | Y |
Address Randomization (ASLR) for Stack/mmap by default | Y (since 9/2004) | Y | Y | Y |
ASLR for vDSO (if vDSO enabled) | no vDSO | Y | Y | Y |
Support for NULL pointer dereference protection | Y(since 11/2009) | Y(since 9/2009) | Y(since 5/2008) | Y |
NX for supported processors/kernels by default | Y(since 9/2004) | Y | Y | Y |
Support for block module loading via cap-bound sysctl tunable or /proc/sys/kernel/cap-bound |
Y | Y | Y | no cap-bound |
Restricted access to kernel memory by default | Y | Y | Y | |
Support for SELinux | Y | Y | Y | |
SELinux enabled with targeted policy by default | Y | Y | Y | |
glibc heap/memory checks by default | Y | Y | Y | |
Support for FORTIFY_SOURCE, used on selected packages | Y | Y | Y | |
Support for ELF Data Hardening | Y | Y | Y | |
All packages compiled using FORTIFY_SOURCE | Y | Y | ||
All packages compiled with stack smashing protection | Y | Y | ||
SELinux Executable Memory Protection | Y | Y | ||
glibc pointer encryption by default | Y | Y | ||
Enabled NULL pointer dereference protection by default | Y(since 5/2008) | Y | ||
Enabled write-protection for kernel read-only data structures by default |
Y | Y | ||
FORTIFY_SOURCE extensions including C++ coverage | Y | |||
Support for block module loading via modules_disabled sysctl tunable or /proc/sys/kernel/modules_disabled |
Y | |||
Support for SELinux to restrict the loading of kernel modules by unprivileged processes in confined domains |
Y | |||
Enabled kernel -fstack-protector buffer overflow detection by default | Y | |||
Support for sVirt labelling to provide security over guest instances | Y | |||
Support for SELinux to confine users' access on a system | Y | |||
Support for SELinux to test untrusted content via a sandbox | Y | |||
Support for SELinux X Access Control Extension (XACE) | Y |
When you look back, before they admitted to this practice, Microsoft actively used vulnerability counts in reports as a tool to discredit the security of open source distributions. Famously even Steve Ballmer participated in counting vulnerabilities using candy.
In other news, the Red Hat Enterprise Linux 4 risk report we release each year has been published (PDF). This whitepaper looks at the state of security for the first five years of Red Hat Enterprise Linux 4 from its release on February 15th, 2005. It includes metrics, key vulnerabilities, and the most common ways users were affected by security issues.
"Red Hat knew about 52% of the security vulnerabilities that we fixed in advance of them being publicly disclosed. The average time between Red Hat knowing about an issue and it being made public was 22 days (median 10 days).... A default installation of Red Hat Enterprise Linux 4 AS was vulnerable to 14 critical security issues over the entire five years. "
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.
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.
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.
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.
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.
See also: 5.3 to 5.4, 5.2 to 5.3, 5.1 to 5.2, and 5.0 to 5.1 risk reports.
During the creation and review of the list we spent some time to see how closely last years list matched the types of flaws we deal with at Red Hat. We first looked at all the issues that Red Hat fixed across our entire product portfolio in the 2009 calendar year and filtered out those that had the highest severity. All our 2009 vulnerabilities have CVSS scores, so we filtered on those that have a CVSS base score of 7.0 or above[1].
There were 22 vulnerabilities that matched, and we mapped each one to the most appropriate CWE. This gives us 11 flaw types which led to the most severe flaws affecting Red Hat in 2009:
CWE | CWE Description | CWE/SANS top 25? | Number of Vulnerabilities |
---|---|---|---|
CWE-476 | NULL Pointer Dereference | No (on cusp) | 6 |
CWE-120 | Buffer Copy without Checking Size of Input | Yes | 3 |
CWE-129 | Improper Validation of Array Index | Yes | 3 |
CWE-131 | Incorrect Calculation of Buffer Size | Yes | 3 |
CWE-78 | OS Command Injection | Yes | 1 |
CWE-285 | Improper Access Control (Authorization) | Yes | 1 |
CWE-362 | Race Condition | Yes | 1 |
CWE-330 | Use of Insufficiently Random Values | No (on cusp) | 1 |
CWE-590 | Free of Memory not on the Heap | No | 1 |
CWE-672 | Use of a Resource after Expiration or Release | No (on cusp) | 1 |
CWE-772 | Missing Release of Resource after Effective Lifetime | No (on cusp) | 1 |
10 of the 11 CWE are mentioned in the 2010 CWE/SANS document, although 4 of them are on "the cusp" and didn't make it into the top 25.
This quick review shows us that 2009 was the year of the kernel NULL pointer dereference flaw, as they could allow local untrusted users to gain privileges, and several public exploits to do just that were released. For Red Hat, interactions with SELinux prevented them being able to be easily mitigated, until the end of the year when we provided updates. Now, in 2010, the upstream Linux kernel and many vendors ship with protections to prevent kernel NULL pointers leading to privilege escalation. So although 2009 was the year where CWE-476 mattered to Linux administrators, it didn't make the SANS/CWE top 25 as this flaw type should not lead to severe issues (as long as the protections remain sufficient).
Here is a breakdown with the complete data set to show the CVSS scores and packages affected:
CVE | CWE | top 25? | CVSS base | Fixed in |
---|---|---|---|---|
CVE-2008-5182 | CWE-362 | Yes | 7.2 | Red Hat Enterprise Linux 5 (kernel) |
CVE-2009-0065 | CWE-129 | Yes | 8.3 | Red Hat Enterprise Linux 4,5,MRG (kernel) |
CVE-2009-0692 | CWE-120 | Yes | 8.3 | Red Hat Enterprise Linux 3,4 (dhcp) |
CVE-2009-0778 | CWE-772 | No (on cusp) | 7.1 | Red Hat Enterprise Linux 5 (kernel) |
CVE-2009-0846 | CWE-590 | No | 9.3 | Red Hat Enterprise Linux 2.1, 3 (krb5) [2] |
CVE-2009-1185 | CWE-131 | Yes | 7.2 | Red Hat Enterprise Linux 5 (udev) |
CVE-2009-1385 | CWE-129 | Yes | 7.1 | Red Hat Enterprise Linux 3,4,5,MRG (kernel) |
CVE-2009-1439 | CWE-131 | Yes | 7.1 | Red Hat Enterprise Linux 4,5,MRG (kernel) |
CVE-2009-1579 | CWE-78 | Yes | 7.5 | Red Hat Enterprise Linux 3,4,5 (squirrelmail) |
CVE-2009-1633 | CWE-131 | Yes | 7.1 | Red Hat Enterprise Linux 4,5,MRG (kernel) |
CVE-2009-2406 | CWE-120 | Yes | 7.2 | Red Hat Enterprise Linux 5 (kernel) |
CVE-2009-2407 | CWE-120 | Yes | 7.2 | Red Hat Enterprise Linux 5 (kernel) |
CVE-2009-2692 | CWE-476 | No (on cusp) | 7.2 | Red Hat Enterprise Linux 3,4,5,MRG (kernel) |
CVE-2009-2694 | CWE-129 | Yes | 7.5 | Red Hat Enterprise Linux 3,4,5 (pidgin) |
CVE-2009-2698 | CWE-476 | No (on cusp) | 7.2 | Red Hat Enterprise Linux 3,4,5 (kernel) |
CVE-2009-2848 | CWE-672 | No (on cusp) | 7.2 | Red Hat Enterprise Linux 3,4,5,MRG (kernel) |
CVE-2009-2908 | CWE-476 | No (on cusp) | 7.2 | Red Hat Enterprise Linux 5 (kernel) |
CVE-2009-3238 | CWE-330 | No (on cusp) | 7.8 | Red Hat Enterprise Linux 4,5,MRG (kernel) |
CVE-2009-3290 | CWE-285 | Yes | 7.2 | Red Hat Enterprise Linux 5 (kvm) |
CVE-2009-3547 | CWE-476 | No (on cusp) | 7.2 | Red Hat Enterprise Linux 3,4,5,MRG (kernel) |
CVE-2009-3620 | CWE-476 | No (on cusp) | 7.2 | Red Hat Enterprise Linux 4,5,MRG (kernel) |
CVE-2009-3726 | CWE-476 | No (on cusp) | 7.2 | Red Hat Enterprise Linux 5,MRG (kernel) |
[1] NIST NVD rate vulnerabilities as "High" severity if they have a CVSS base score of 7.0-10.0. This ends up excluding flaws in web browsers such as Firefox which can have a maximum CVSS base score of 6.8.
[2] Red Hat Enterprise Linux 4 and 5 were also affected by this vulnerability, but with a lower CVSS base score of 4.3, due to the extra runtime pointer checking.
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.
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.
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.
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:
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.
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:
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.
See also: 5.2 to 5.3, 5.1 to 5.2, and 5.0 to 5.1 risk reports.
The chart below shows the total number of security updates issued for Red Hat Enterprise Linux 5 Server as if you installed 5.2, up to and including the 5.3 release, broken down by severity. I've split it into two columns, one for the packages you'd get if you did a default install, and the other if you installed every single package (which is unlikely as it would involve a bit of manual effort to select every one). So, for a given installation, the number of packages and vulnerabilities will probably be somewhere between the two.
So for a default install, from release of 5.2 up to and including 5.3, we shipped 45 advisories to address 127 vulnerabilities. 7 advisories were rated critical, 21 were important, and the remaining 17 were moderate and low.
For all packages, from release of 5.2 to and including 5.3, we shipped 61 advisories
to address 181 vulnerabilities. 7 advisories were rated critical, 28 were
important, and the remaining 26 were moderate and low.
The 7 critical advisories were for just 3 different packages:
Although not of critical severity, also of interest during this period were the spoofing attacks on DNS servers. We provided an update to BIND (July) adding source port randomization to help mitigate these attacks.
Updates to correct all of these critical vulnerabilities (as well as migitate the BIND issue) were available via Red Hat Network either the same day, or 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.
To compare this with the last updates 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:
Red Hat Enterprise Linux 5 shipped with a number of security technologies designed to make it harder to exploit vulnerabilities and in some cases block exploits for certain flaw types completely. For 5.2 to 5.3 there were two flaws blocked that would otherwise have required updates:
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.
See also:5.1 to 5.2 risk report
The graph below shows the total number of security updates issued for Red Hat Enterprise Linux 5 Server starting at 5.1 up to and including the 5.2 release, broken down by severity. I've split it into two columns, one for the packages you'd get if you did a default install, and the other if you installed every single package (which is unlikely as it would involve a bit of manual effort to select every one). So, for a given installation, the number of packages and vulnerabilities will probably be somewhere between the two.
So for a default install, from release of 5.1 up to and including 5.2, we shipped 46 updates to address 119 vulnerabilities. 8 advisories were rated critical, 24 were important, and the remaining 14 were moderate and low.
For all packages, from release of 5.1 to and including 5.2, we shipped 62 updates to address 179 vulnerabilities. 9 advisories were rated critical, 29 were important, and the remaining 24 were moderate and low.
The nine critical updates were in five different packages:
Updates to correct all of these critical issues were available via Red Hat Network either the same day, or one calendar day after the issues were public.
To get a better idea of risk we need to look not only at the vulnerabilities but also the exploits written for those vulnerabilities. A proof of concept exploit exists publicly for one of the Samba flaws, CVE-2007-6015, but we are not aware of public exploits for any other of those critical vulnerabilities. Also of high risk was an important "zero-day" exploit affecting the Linux kernel where a local unprivileged user could gain root privileges. Red Hat Enterprise Linux 5.1 was affected and a fix was available two calendar days after public disclosure.
Red Hat Enterprise Linux 5 shipped with a number of security technologies designed to make it harder to exploit vulnerabilities and in some cases block exploits for certain flaw types completely. For the period of this study there were two flaws blocked that would otherwise have required updates:
This data is interesting to get a feel for the risk of running Enterprise Linux 5 Server, but isn't really useful for comparisons with other versions or distributions -- for example, a default install of Red Hat Enterprise 4AS did not include Firefox. You can get the results I presented above for yourself by using our public security measurement data and tools, and run your own custom metrics for any given Red Hat product, package set, timescales, and severities.
See also 5.0 to 5.1 risk report
My full risk report was published yesterday in Red Hat Magazine and reveals the state of security since the release of Red Hat Enterprise Linux 4 including metrics, key vulnerabilities, and the most common ways users were affected by security issues.
"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."