The chart below illustrates the total number of security updates issued for Red Hat Enterprise Linux 5 Server if you had installed 5.6, up to and including the 5.7 release, broken down by severity. It's split into two columns, one for the packages you'd get if you did a default install, and the other if you installed every single package (which is unlikely as it would involve quite a bit of manual effort to select every one). For a given installation, the number of package updates and vulnerabilities that affected you will depend on exactly what packages you have installed or removed.
So, for a default install, from release of 5.6 up to and including 5.7, we shipped 27 advisories to address 109 vulnerabilities. 3 advisories were rated critical, 12 were important, and the remaining 12 were moderate and low.
Or, for all packages, from release of 5.6 to and including 5.7, we shipped 58 advisories to address 172 vulnerabilities. 4 advisories were rated critical, 20 were important, and the remaining 34 were moderate and low.
The 4 critical advisories addressed 34 critical vulnerabilities across just 2 different packages:
Updates to correct all of the 34 critical vulnerabilities were available via Red Hat Network either the same day or the next calendar day after the issues were public.
Overall, for Red Hat Enterprise Linux 5 since release until 5.7, 97% of critical vulnerabilities have had an update available to address them available from the Red Hat Network either the same day or the next calendar day after the issue was public.
Although not in the definition of critical severity, also of interest during this period were a couple of flaws that were easily exploitable:
In addition, updates to Firefox and NSS were made to blacklist a number of compromised SSL certificates.
To compare these statistics with previous update releases we need to take into account that the time between each update release is different. So looking at a default installation and calculating the number of advisories per month gives the following chart:
This data is interesting to get a feel for the risk of running Enterprise Linux 5 Server, but isn't really useful for comparisons with other major versions, distributions, or operating systems -- for example, a default install of Red Hat Enterprise Linux 4AS did not include Firefox, but 5 Server does. You can use our public security measurement data and tools, and run your own custom metrics for any given Red Hat product, package set, timescales, and severity range of interest.
See also: 5.5 to 5.6, 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.
The chart below illustrates the total number of security updates issued for Red Hat Enterprise Linux 6 Server if you had installed 6.0, up to and including the 6.1 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 6.0 up to and including 6.1, we shipped 54 advisories to address 195 vulnerabilities. 2 advisories were rated critical, 29 were important, and the remaining 23 were moderate and low.
Or, for all packages, from release of 6.0 up to and including 6.1, we shipped 102 advisories to address 345 vulnerabilities. 8 advisories were rated critical, 39 were important, and the remaining 55 were moderate and low.
These figures include 10 advisories we released on the day we shipped 6.0. This was because we froze package updates some months before releasing the product. Two of those updates were rated critical, an update to Firefox, and to Samba.
The 8 critical advisories addressed 37 critical vulnerabilities across 4 components:
Updates to correct all of the 37 critical vulnerabilities were available via Red Hat Network either the same day or the next calendar day after the issues were public.
This data is interesting to get a feel for the risk of running Enterprise Linux 6 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 and 6 Server 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.
After many iterations at getting right schema, CVRF 1.0 was released this week.
Red Hat is not yet providing an official archive with CVRF representations of our advisories, but we have created tools internally to support it and allow us to automatically create CVRF documents based on our advisory database. We've provided a sample set of advisories in CVRF format for download.
Let's take one of these samples, a recent Red Hat Enterprise Linux security advisory and examine how it looks when automatically converted to a CVRF document. Our advisories often fix more than one vulnerability at a time and for more than one version of a product, but for this example we'll keep it simple. RHSA-2010:0888 is an Enterprise Linux 6 update to fix the vulnerability CVE-2010-3864 affecting OpenSSL.
The CVRF for this advisory starts like this:
The first section, above, is pretty straightforward: we're publishing this CVRF as the authoritative vendor for Red Hat Enterprise Linux, and it's a Security Advisory. All our text fields have a language identifier ("en") as future CVRF advisories could contain localized parts.<?xml version="1.0" encoding="utf-8"?> <cvrfdoc xmlns="https://www.icasi.org/CVRF/schema/cvrf/1.0" xmlns:cvrf="https://www.icasi.org/CVRF/schema/cvrf/1.0" xmlns:cvrf-vuln="https://www.icasi.org/CVRF/schema/vuln/1.0"> <DocumentTitle xml:lang="en">Red Hat Security Advisory: openssl security update</DocumentTitle> <DocumentDistribution xml:lang="en">Copyright © 2011 Red Hat, Inc. All rights reserved.</DocumentDistribution> <LegalDisclaimer xml:lang="en">Please see https://www.redhat.com/legal/legal_statement.html</LegalDisclaimer> <DocumentType>Security Advisory</DocumentType> <DocumentPublisher>Vendor</DocumentPublisher>
The next section is about document revision history and is a mandatory requirement of CVRF documents. This is tricky for Red Hat to automatically generate from our existing advisories: we use an internal "Push Count" as our revision number, and occasional problems during pushing an advisory live mean that our first real public version is not "1". In addition, when we do release an update to an advisory, we update the description text with details of the changes made, so we don't have this text stored in a separate field. So for now our CVRF "RevisionDescription" sections will not have useful descriptions, but the initial and current release dates will be accurate.<DocumentTracking> <DocumentID>RHSA-2010:0888</DocumentID> <DocumentStatus>Final</DocumentStatus> <DocumentVersion>1</DocumentVersion> <DocumentRevisionHistory> <DocumentRevision> <RevisionNumber>1.0</RevisionNumber> <RevisionDate>2010-11-16T16:08:00+00:00</RevisionDate> <RevisionDescription>Current version</RevisionDescription> </DocumentRevision> </DocumentRevisionHistory> <DocumentInitialReleaseDate>2010-11-16T16:08:00+00:00</DocumentInitialReleaseDate> <DocumentCurrentReleaseDate>2010-11-16T16:08:00+00:00</DocumentCurrentReleaseDate>
During the design of CVRF we championed this separate "DocumentGenerator" section, which mirrors a similar section in OVAL. This can help us track down any errors in published documents and allows us to regenerate a document if our automated script is altered or fixed without causing a new document revision.<DocumentGenerator> <Generator>make-cvrf-from-et.pl</Generator> <GenerationDate>2010-12-15T10:15:06+00:00</GenerationDate> <CVRFVersion>1.00</CVRFVersion> </DocumentGenerator> </DocumentTracking>
The document summary and details sections above are directly copied from the equivalent sections in our text advisory. This does mean however that the details of the vulnerabilities will get repeated, as later each vulnerability gets its own section with description, CVE name, and acknowledgments.<DocumentSummary> <Summary Title="Topic" Audience="General" xml:lang="en"> Updated openssl packages that fix one security issue are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having important security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available from the CVE link in the References section. </Summary> </DocumentSummary> <DocumentDetails> <Details Title="Details" Audience="General" xml:lang="en"> OpenSSL is a toolkit that implements the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols, as well as a full-strength, general purpose cryptography library. A race condition flaw has been found in the OpenSSL TLS server extension parsing code, which could affect some multithreaded OpenSSL applications. Under certain specific conditions, it may be possible for a remote attacker to trigger this race condition and cause such an application to crash, or possibly execute arbitrary code with the permissions of the application. (CVE-2010-3864) Note that this issue does not affect the Apache HTTP Server. Refer to Red Hat Bugzilla bug 649304 for more technical details on how to determine if your application is affected. Red Hat would like to thank Rob Hulswit for reporting this issue. All OpenSSL users should upgrade to these updated packages, which contain a backported patch to resolve this issue. For the update to take effect, all services linked to the OpenSSL library must be restarted, or the system rebooted. </Details> </DocumentDetails>
References can appear both at the top level of a CVRF document as well as for each vulnerability. The most important top level reference is the self-reference which links to the full representation of the advisory. In early CVRF drafts this had a separate attribute so that it was possible to extract the self reference URL; we think that would have been useful to still be there.<References> <RelatedDocument> <DocumentURL>https://rhn.redhat.com/errata/RHSA-2010-0888.html</DocumentURL> <DocumentDescription>https://rhn.redhat.com/errata/RHSA-2010-0888.html</DocumentDescription> </RelatedDocument> <RelatedDocument> <DocumentURL>https://www.redhat.com/security/updates/classification/#important</DocumentURL> <DocumentDescription>https://www.redhat.com/security/updates/classification/#important</DocumentDescription> </RelatedDocument> </References>
The final top level directives give our severity rating and issuing authority. The severity is a free-text field and it's up to each vendor to use their own scheme for this. In the earlier references section we already gave a URL that described the severity levels being used; for a future CVRF version we should have that URL referenced as part of the AggregateSeverity tag.<AggregateSeverity>Important</AggregateSeverity> <IssuingAuthority VendorID="Red Hat, Inc">secalert@redhat.com</IssuingAuthority>
We produce one vulnerability section for each CVE fixed, and the vulnerability details are abstracted from our full text description.<cvrf-vuln:Vulnerability> <cvrf-vuln:VulnerabilityID><cvrf-vuln:Value SystemName="CVE">CVE-2010-3864</cvrf-vuln:Value></cvrf-vuln:VulnerabilityID> <cvrf-vuln:VulnerabilityDetails xml:lang="en">A race condition flaw has been found in the OpenSSL TLS server extension parsing code, which could affect some multithreaded OpenSSL applications. Under certain specific conditions, it may be possible for a remote attacker to trigger this race condition and cause such an application to crash, or possibly execute arbitrary code with the permissions of the application. </cvrf-vuln:VulnerabilityDetails>
VendorRemediationStatus will always be "Completed" for all our advisories as they are always released at the same time as a fix. Also included is a per-vulnerability impact rating and CVSS base score. These are currently not included in our HTML advisories, but are available from our CVE database and Bugzilla entries; so it's handy to be able to have them all in the same document for the first time.<cvrf-vuln:VendorRemediationStatus>Completed</cvrf-vuln:VendorRemediationStatus> <cvrf-vuln:CVE>CVE-2010-3864</cvrf-vuln:CVE> <cvrf-vuln:Threat><cvrf-vuln:Impact>Important</cvrf-vuln:Impact></cvrf-vuln:Threat> <cvrf-vuln:ProductFamily>Red Hat Enterprise Linux</cvrf-vuln:ProductFamily> <cvrf-vuln:Acknowledgment>Red Hat would like to thank Rob Hulswit for reporting this issue.</cvrf-vuln:Acknowledgment> <cvrf-vuln:CVSS> <cvrf-vuln:CVSSBaseScore>7.6</cvrf-vuln:CVSSBaseScore> <cvrf-vuln:CVSSScoringVector>AV:N/AC:H/Au:N/C:C/I:C/A:C</cvrf-vuln:CVSSScoringVector> </cvrf-vuln:CVSS>
The remediation section mirrors our advisories by giving a list of packages and the versions that first contained the fix for the issue. We have multiple variants of Red Hat Enterprise Linux 6, and some vulnerabilities will affect packages only shipped in some subset of variants, so the duplication is required.<cvrf-vuln:Remediation> <cvrf-vuln:VendorFix xml:lang="en"> Before applying this update, make sure all previously-released errata relevant to your system have been applied. This update is available via the Red Hat Network. Details on how to use the Red Hat Network to apply this update are available at https://kbase.redhat.com/faq/docs/DOC-11259 </cvrf-vuln:VendorFix> </cvrf-vuln:Remediation> <cvrf-vuln:AffectedPlatform Name="Red Hat Enterprise Linux"> <cvrf-vuln:AffectedRelease Name="Red Hat Enterprise Linux Desktop Optional (v. 6)"> <cvrf-vuln:Version Type="Fixed">openssl-1.0.0-4.el6_0.1</cvrf-vuln:Version> <cvrf-vuln:Version Type="Fixed">openssl-debuginfo-1.0.0-4.el6_0.1</cvrf-vuln:Version> <cvrf-vuln:Version Type="Fixed">openssl-devel-1.0.0-4.el6_0.1</cvrf-vuln:Version> <cvrf-vuln:Version Type="Fixed">openssl-perl-1.0.0-4.el6_0.1</cvrf-vuln:Version> <cvrf-vuln:Version Type="Fixed">openssl-static-1.0.0-4.el6_0.1</cvrf-vuln:Version> </cvrf-vuln:AffectedRelease> <cvrf-vuln:AffectedRelease Name="Red Hat Enterprise Linux HPC Node Optional (v. 6)"> <cvrf-vuln:Version Type="Fixed">openssl-1.0.0-4.el6_0.1</cvrf-vuln:Version> <cvrf-vuln:Version Type="Fixed">openssl-debuginfo-1.0.0-4.el6_0.1</cvrf-vuln:Version> <cvrf-vuln:Version Type="Fixed">openssl-devel-1.0.0-4.el6_0.1</cvrf-vuln:Version> <cvrf-vuln:Version Type="Fixed">openssl-perl-1.0.0-4.el6_0.1</cvrf-vuln:Version> <cvrf-vuln:Version Type="Fixed">openssl-static-1.0.0-4.el6_0.1</cvrf-vuln:Version> </cvrf-vuln:AffectedRelease> <cvrf-vuln:AffectedRelease Name="Red Hat Enterprise Linux Workstation Optional (v. 6)"> <cvrf-vuln:Version Type="Fixed">openssl-1.0.0-4.el6_0.1</cvrf-vuln:Version> <cvrf-vuln:Version Type="Fixed">openssl-debuginfo-1.0.0-4.el6_0.1</cvrf-vuln:Version> <cvrf-vuln:Version Type="Fixed">openssl-perl-1.0.0-4.el6_0.1</cvrf-vuln:Version> <cvrf-vuln:Version Type="Fixed">openssl-static-1.0.0-4.el6_0.1</cvrf-vuln:Version> </cvrf-vuln:AffectedRelease> <cvrf-vuln:AffectedRelease Name="Red Hat Enterprise Linux Workstation (v. 6)"> <cvrf-vuln:Version Type="Fixed">openssl-1.0.0-4.el6_0.1</cvrf-vuln:Version> <cvrf-vuln:Version Type="Fixed">openssl-debuginfo-1.0.0-4.el6_0.1</cvrf-vuln:Version> <cvrf-vuln:Version Type="Fixed">openssl-devel-1.0.0-4.el6_0.1</cvrf-vuln:Version> </cvrf-vuln:AffectedRelease> <cvrf-vuln:AffectedRelease Name="Red Hat Enterprise Linux HPC Node (v. 6)"> <cvrf-vuln:Version Type="Fixed">openssl-1.0.0-4.el6_0.1</cvrf-vuln:Version> <cvrf-vuln:Version Type="Fixed">openssl-debuginfo-1.0.0-4.el6_0.1</cvrf-vuln:Version> </cvrf-vuln:AffectedRelease> <cvrf-vuln:AffectedRelease Name="Red Hat Enterprise Linux Server Optional (v. 6)"> <cvrf-vuln:Version Type="Fixed">openssl-1.0.0-4.el6_0.1</cvrf-vuln:Version> <cvrf-vuln:Version Type="Fixed">openssl-debuginfo-1.0.0-4.el6_0.1</cvrf-vuln:Version> <cvrf-vuln:Version Type="Fixed">openssl-perl-1.0.0-4.el6_0.1</cvrf-vuln:Version> <cvrf-vuln:Version Type="Fixed">openssl-static-1.0.0-4.el6_0.1</cvrf-vuln:Version> </cvrf-vuln:AffectedRelease> <cvrf-vuln:AffectedRelease Name="Red Hat Enterprise Linux Desktop (v. 6)"> <cvrf-vuln:Version Type="Fixed">openssl-1.0.0-4.el6_0.1</cvrf-vuln:Version> <cvrf-vuln:Version Type="Fixed">openssl-debuginfo-1.0.0-4.el6_0.1</cvrf-vuln:Version> </cvrf-vuln:AffectedRelease> <cvrf-vuln:AffectedRelease Name="Red Hat Enterprise Linux Server (v. 6)"> <cvrf-vuln:Version Type="Fixed">openssl-1.0.0-4.el6_0.1</cvrf-vuln:Version> <cvrf-vuln:Version Type="Fixed">openssl-debuginfo-1.0.0-4.el6_0.1</cvrf-vuln:Version> <cvrf-vuln:Version Type="Fixed">openssl-devel-1.0.0-4.el6_0.1</cvrf-vuln:Version> </cvrf-vuln:AffectedRelease> </cvrf-vuln:AffectedPlatform>
Finally, the per-vulnerability reference section links to our CVE database for each CVE, and the Red Hat bug database for more technical details of the vulnerability and how it was addressed.<cvrf-vuln:References> <cvrf-vuln:RelatedDocument> <cvrf-vuln:DocumentURL>https://www.redhat.com/security/data/cve/CVE-2010-3864.html</cvrf-vuln:DocumentURL> <cvrf-vuln:DocumentDescription>CVE-2010-3864</cvrf-vuln:DocumentDescription> </cvrf-vuln:RelatedDocument> <cvrf-vuln:RelatedDocument> <cvrf-vuln:DocumentURL>https://bugzilla.redhat.com/show_bug.cgi?id=649304</cvrf-vuln:DocumentURL> <cvrf-vuln:DocumentDescription>bz#649304: CVE-2010-3864 OpenSSL TLS extension parsing race condition</cvrf-vuln:DocumentDescription> </cvrf-vuln:RelatedDocument> </cvrf-vuln:References> </cvrf-vuln:Vulnerability> </cvrfdoc>
Our example advisory only had one vulnerability, but the whole vulnerability section is repeated where multiple are addressed.
Overall we've been really pleased with the way CVRF has turned out for it's first release, and we think it will be a useful way for vendors such as us to provide machine-readable advisories to customers as well as to tool vendors, filling a gap between our OVAL XML and our text and HTML advisories. We'll be trialling CVRF advisories later this year, drop an email to secalert@redhat.com if you have comments on our CVRF samples.
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.
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 |
Starting with Red Hat Enterprise Linux 6 we have switched to using SHA-256 signatures on all RPM packages and to a 4096-bit RSA signing key.
We've done this because it is current best practice to migrate away from MD5 and SHA-1 hashes due to various flaws found in them. Those flaws don't yet directly pose a threat to package signing however, and therefore our existing shipped products which used these older hashes will continue to use their existing keys until they reach their end of life.
A similar switch to stronger signing was already made in Fedora 11. This switch involved some changes to the RPM application.
So what this means is that we used new signing keys for both the beta and final release packages for Red Hat Enterprise Linux 6. Those keys were created and are protected by a hardware security module, as we've done with previous keys.
Details and fingerprint of the new key, #fd431d51.
Also in the Red Hat Enterprise Linux 6 distribution we've started
to simplify the layout of the key files in
the /etc/pki/rpm-gpg/
directory:
The auxiliary key mentioned above is for emergency use. We created it some time ago on a new standalone machine, took a hardcopy printout of the private key and passphrase, stored them separately and securely, and destroyed the software copies. We've planned for many eventualities, but in the unlikely event we lose the ability to sign with the hardware key we could retrieve the printout, type in the key, and continue to sign updates.
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.
It all started when I bought her a Chumby for Christmas. A Chumby is a little bedside device that can act as an alarm clock as well as running flash-lite applets. What made it especially appealing is that you can write your own applets if you want, and the whole thing is Linux-based and designed to be hackable: they correctly abide by the GPL and have their sources available, you can build and install your own software, you can even enable ssh and have a remote shell if you want to. And with NTP the clock is always at the right time, since I really don't like having out-of-sync clocks around the house.
So it was time to connect another device to my wireless network: a device designed to be left on and permanently connected to the network, and having a connected microphone, in the bedroom. A quick look around the OS and I found that it had a web server accessible by default, and a pair of CGI scripts, written in shell script, running as root, that didn't correctly escape their input. (Hint: writing secure CGI scripts in shell is non-trivial).
With a bit of careful manipulation (to get around some character handling in the code) I had a remote root shell on a default Chumby and could stream audio from the microphone remotely. Oops. Not too big a deal though as it's unlikely you're going to have it directly connected to the internet, although with some social engineering, if you know someone with a Chumby, you could do a cunning cross-site scripting attack and get a reverse shell that way.
I contacted the Chumby folks and they dealt with this like an ideal vendor; acknowledging the issue, keeping in contact, and doing a security update. Good for them. I like this device and vendor so much I'm going to buy another Chumby, and a few colleagues from work are too.
But how many other devices do we connect to our networks without thinking about them, and how many folks outside of the security paranoid have properly secured and segmented wireless networks? I've got a IP wireless network CCTV camera and a VOIP phone system both which seem to be running Linux (and both which seem to have vulnerabilities) to worry about next although harder since both are closed systems which haven't released their source.
So for CVE database: CVE-2010-0418 is "Chumby One before 1.0.4 and Chumby Classic before 1.7.2 allows remote attackers to execute arbitrary commands via shell metacharacters in a carefully crafted request to the web interface". Reported 29 Dec 2009, vendor responded 29 Dec 2009, tested fix 3 Feb 2010, public and updates 4 Mar 2010.
The stories center around how open source software such as Firefox was able to produce updates to correct this issue just a few days after the Blackhat conference, while Microsoft still hasn't fixed it and are "investigating a possible vulnerability in Windows presented during Black Hat".
But the actual timeline is missing from these stories.
The NULL character certificate flaw (CVE-2009-2408) was actually disclosed by two researchers working independantly who both happened to present the work at the same conference, Blackhat, in July this year. Dan Kaminsky mentioned it as part of a series of PKI flaws he disclosed. Marlinspike had found the same flaw, but was able to demonstrate it in practice by managing to get a trusted Certificate Authority to sign such a malicious certificate.
The flaw was no Blackhat surprise; Dan Kaminsky actually found this issue many months ago and responsibly reported the issues to vendors including Red Hat, Microsoft, and Mozilla. We found out about this issue on 25th February 2009 and worked with Dan and some of the upstream projects on these issues in advance, so we had plenty of time to prepare updates and this is why we were able to have them ready to release just after the disclosure.