| |
mark :: blog :: metrics
Red Hat Enterprise Linux 6.1 was released this week (May 2011), just
over six months since the release of 6.0 in October 2010. So let's
use this opportunity to take a quick look back over the
vulnerabilities and security updates made in that time, specifically
for Red Hat Enterprise Linux 6 Server.
Errata count
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.
Critical vulnerabilities
The 8 critical advisories addressed 37 critical vulnerabilities across 4 components:
- An update to Samba (October 2010)
where a malicious client could potentially run arbitrary code as the Samba
server. Samba is a default install package but the server is not enabled by default.
- Four updates to Firefox (October 2010, December 2010, March 2011, April 2011)
where a malicious web site could potentially run arbitrary code as the user
running Firefox.
- Two updates to Thunderbird (March 2011, April 2011)
where a malicious email message could potentially run arbitrary code as the user
running Thunderbird.
- An update to Pango (March 2011)
where an application using Pango to parse untrusted font data (such as
Firefox) could potentially run
arbitrary code as the privileges of the user. Pango is a default install package.
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.
Earlier this year, Red Hat joined the Common Vulnerability Reporting Framework
(CVRF) working group run by ICASI. The goal of CVRF is to provide a way to
share information about security updates in a machine-readable format. Red Hat
already produce a version of our security advisories in machine readable format,
as OVAL definitions, but these are really designed for automated test tools to
determine the need to apply an update. CVRF looked like it would be more useful
for providing customers with a machine readable view of our advisories.
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:
<?xml version="1.0" encoding="utf-8"?>
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.0"
xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.0"
xmlns:cvrf-vuln="http://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 http://www.redhat.com/legal/legal_statement.html</LegalDisclaimer>
<DocumentType>Security Advisory</DocumentType>
<DocumentPublisher>Vendor</DocumentPublisher>
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.
<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>
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.
<DocumentGenerator>
<Generator>make-cvrf-from-et.pl</Generator>
<GenerationDate>2010-12-15T10:15:06+00:00</GenerationDate>
<CVRFVersion>1.00</CVRFVersion>
</DocumentGenerator>
</DocumentTracking>
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.
<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>
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.
<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>http://www.redhat.com/security/updates/classification/#important</DocumentURL>
<DocumentDescription>http://www.redhat.com/security/updates/classification/#important</DocumentDescription>
</RelatedDocument>
</References>
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.
<AggregateSeverity>Important</AggregateSeverity>
<IssuingAuthority VendorID="Red Hat, Inc">secalert@redhat.com</IssuingAuthority>
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.
<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>
We produce one vulnerability section for each CVE fixed, and the vulnerability
details are abstracted from our full text description.
<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>
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: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
http://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>
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: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>
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.
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.
Red Hat Enterprise Linux 5.6 was released last week (January 2011), nearly ten
months since the release of 5.5 in March 2010. So let's use this opportunity to
take a quick look back over the vulnerabilities and security updates made in
that time, specifically for Red Hat Enterprise Linux 5 Server.
Errata count
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.
Critical vulnerabilities
The 12 critical advisories addressed 49 critical vulnerabilities across just 3 different packages:
- An update to the Exim Internet Mailer,
(December 2010),
where an unauthenticated remote attacker could run arbitrary code as root on a
server.
Exim is not a default package or enabled by default. There is a
public exploit for this issue which worked on Red Hat Enterprise Linux 5.
- Two updates over three advisories to Samba,
(June 2010 for
Samba 3.0 and Samba 3.3,
September 2010 for
Samba 3.0 and
Samba 3.3),
where a malicious client could send a specially-crafted SMB packet to the Samba
server, potentially resulting in arbitrary code execution with the privileges of the Samba
server. I'm not aware of any working public exploits for these issues.
- Eight updates to Firefox (March 2010, June 2010, 20 July 2010, 23 July 2010, September 2010, 19 October 2010, 27 October 2010, December 2010)
where a malicious web site could potentially run arbitrary code as the user
running Firefox.
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.
Other significant vulnerabilities
Although not in the definition of critical severity, also of interest during
this period were several kernel flaws that where an local user could gain
root privileges. The following had publicly available exploits:
- A fix
for CVE-2010-2240
was provided
by RHSA-2010-0661
(August 2010). The public exploit did not work against Red Hat Enterprise
Linux 5, but it may be possible to create one that does.
- A fix
for CVE-2010-3081
was provided
by RHSA-2010-0704
(September 2010). The public exploit worked against Red Hat Enterprise
Linux 5
- A fix
for CVE-2010-3904
was provided
by RHSA-2010-0792
(October 2010). The public exploit did not work against Red Hat Enterprise
Linux 5 but it is possible to create one that does.
Previous 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 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.
Two years ago I published a table
of Vulnerability and
threat mitigation features in Red Hat Enterprise Linux and Fedora. Now that
we've released Red Hat Enterprise Linux 6, it's time to update the table. Thanks
to Eugene Teo for collating this information.
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.
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:
- RPM-GPG-KEY-redhat-beta : Both the old and new beta keys
- RPM-GPG-KEY-redhat-release : Both the new signing key and the auxiliary key
- RPM-GPG-KEY-redhat-legacy-release : The signing key used for EL5
- RPM-GPG-KEY-redhat-legacy-former : The signing key used for products before EL5
- RPM-GPG-KEY-redhat-legacy-rhx : The signing key used for RHX
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.
It came as no surprise when
Microsoft admitted to quiet security patching. We knew many years
ago that they did this: not counting extra vulnerabilities that
were found internally or by researchers contracted to work for them.
For closed source, single vendor software, this isn't too big of a
deal - it's not like the user has a choice if they need to update some
application to address one critical vulnerability or 20.
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. "
Red Hat Enterprise Linux 5.5 was released at the end of March 2010,
just under 7 months since the release of 5.4 in September 2009. So
let's use this opportunity to take a quick look back over the
vulnerabilities and security updates we've made in that time,
specifically for Red Hat Enterprise Linux 5 Server.
Errata count
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.
Critical vulnerabilities
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.
- Four updates to Firefox (September 2009, October 2009, December 2009, February 2010)
where a malicious web site could potentially run arbitrary code as the user
running Firefox.
- An update to kdelibs
(November 2009),
where a malicious web site could potentially run arbitrary code as the
user running the Konqueror browser. kdelibs is not a default
installation package.
- An update to krb5, the Kerberos network authentication system
(January 2010),
where a remote KDC client could cause a crash or run arbitrary code as
root. This issue only affected users that have configured and enabled
krb5.
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.
Other significant vulnerabilities
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.
Previous 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.3 to 5.4,
5.2 to 5.3,
5.1 to 5.2, and
5.0 to 5.1
risk reports.
The 2010 CWE/SANS Top 25 Most Dangerous
Programming Errors was published today listing the most widespread issues
that lead to software vulnerabilities.
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.
There have been quite a few stories over the last couple of weeks
about the NULL character certificate flaw, such as this
one from The Register.
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.
Red Hat Enterprise Linux 5.4 was released today, just over 7 months since the
release of 5.3 in January 2009. So let's use this opportunity to take a quick
look back over the vulnerabilities and security updates we've made in that time,
specifically for Red Hat Enterprise Linux 5 Server.
Errata count
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.
Critical vulnerabilities
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.
- Seven updates to Firefox (February, March 4th, March 27th, April 21st, April 27th, June, July )
where a malicious web site could potentially run arbitrary code as the user
running Firefox.
- An update to kdelibs
(June),
where a malicious web site could potentially run arbitrary code as the
user running the Konqueror browser. kdelibs is not a default installation package.
- An update to the NSS library
(July), where
a service could present a malicious SSL certificate causing
a heap overflow which could potentially run arbitrary code as the user running
a browser such as Firefox.
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.
Other significant vulnerabilities
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:
- CVE-2009-2698
was public on August 24th and a working privilege escalation exploit was
published about a week later. This issue was addressed for Red Hat Enterprise
Linux 5 by
a kernel update on
August 24th.
- CVE-2009-2692
was public on August 13th and a working privilege escalation exploit was
published the same day.
This issue was addressed for Red Hat Enterprise Linux 5 by
a kernel update on
August 24th.
- CVE-2009-1897
was public on July 16th along with a working privilege escalation exploit. This issue
affected only beta versions of the Red Hat Enterprise Linux 5.4 kernel and
it was addressed prior to the release of Red Hat Enterprise Linux 5.4.
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.
Mitigations
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:
- CVE-2009-0692,
a stack buffer overflow flaw in dhclient.
FORTIFY_SOURCE protection detects the overflow and causes dhclient to exit with
no security consequence. No security update for users of Red Hat Enterprise
Linux 5 was needed.
-
CVE-2009-1252
a buffer overflow flaw in NTP caught by FORTIFY_SOURCE.
We issued an
update as a remote attacker could still cause a denial of service.
- CVE-2009-0846,
a uninitialized pointer free in krb5. glibc provides a hardened malloc/free
implementation which mitigates the exploitability of this flaw, however we
issued an update as a remote attacker could still cause a denial
of service.
Previous 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.
|
|
|
Hi! I'm Mark Cox. This blog gives my
thoughts and opinions on my security
work, open source, fedora, home automation,
and other topics.
pics from my twitter:
popular tags:
[all],
apache,
apachecon,
apacheweek,
cve,
cvss,
fedora,
financial,
geocaching,
ha,
metrics,
microsoft,
nashville,
north carolina,
red hat summit,
redhat,
security,
trips
|
|
