Mark J Cox, mark@awe.com  
   
mark :: blog

<< prev [ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 ] next >>



The inspiration for the Sonik video for Gravitation came from a local friend of ours, a talented and world-renowned photographer, Adrian Brannan. Ade is famous for his analogue photo collages (please give him a 'like' on his Facebook page):

We often wondered how the same effect would look if rendered with video. With video you've got the extra element of time, each segment of the mosaic can be running from a different starting point, with a different speed, and even a different direction. In addition the segments themselves can move over time. Would this end up with an effect that was just too much of a mess? Or would it give an effect that helps visualise the consequence of spacetime?

We started by taking several videos at three different locations over the period of a year with a Kodak Zi8 camera. A motorway bridge over the M74, just outside the Buchanan shopping center in Glasgow, and a bench in Strathclyde park. Lining up the images was done roughly by using lines drawn on acetate stuck over the camera screen.

The software to do the mosaic effect was hand-written. We used a simple scripting language, Perl, and the image library GD. On a relatively modern Linux PC running Fedora 16 we can render near real-time 720p HD even when handling 300 segments of mosaic. A simple language controls which parts of the screen come from which video, and the first half of the music video uses this with simple effects having just a few boxes overlayed:

Later in the video things get more complicated, using randomisation to pick the location and movement of each segment:

We used our scripts to create a number of ~13 second segments, then put them all together using kdenlive. The intro and outro were taken from a different video from a hotel room in London Victoria; the intro using a 'miniature' effect, and outro using the randomised segments applied to a single video.

The Perl script and a 5 frame example is available to download: 2011-sonik-vid-example.tar.bz2 (1.4M)

Watch the full video, or click through to YouTube to see it in HD:



Red Hat Enterprise Linux 6.2 was released this week (Dec 2011), just over six months since the release of 6.1 in May 2011. 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.1, up to and including the 6.2 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.1 up to and including 6.2, we shipped 36 advisories to address 121 vulnerabilities. 2 advisories were rated critical, 10 were important, and the remaining 24 were moderate and low.

Or, for all packages, from release of 6.1 up to and including 6.2, we shipped 88 advisories to address 218 vulnerabilities. 10 advisories were rated critical, 16 were important, and the remaining 62 were moderate and low.

Critical vulnerabilities

The 10 critical advisories addressed 31 critical vulnerabilities across 3 components:

  1. Two updates to the OpenJDK 6 Java Runtime (June 2011, October 2011) where a malicious web site presenting a Java applet could potentially run arbitrary code as the user running a web browser.
  2. Four updates to Firefox (June 2011, August 2011, September 2011, November 2011) where a malicious web site could potentially run arbitrary code as the user running Firefox.
  3. Four updates to Thunderbird (June 2011, August 2011, September 2011 November 2011) where a malicious email message could potentially run arbitrary code as the user running Thunderbird.

Updates to correct all of the 31 critical vulnerabilities were available via Red Hat Network either the same day or the next calendar day after the issues were public.

Other significant vulnerabilities

Although not in the definition of critical severity, also of interest during this period were a few flaws that were high risk or easily exploitable:

  • A flaw in Bind, CVE-2011-4313 fixed by RHSA-2011:1458 where a malicious client could cause Bind to stop responding, a denial of service attack. This flaw was discovered by it being accidentally triggered in the wild.

  • A flaw in the Apache HTTP Server, CVE-2011-3192, fixed by RHSA-2011:1245, where a remote attacker could cause a denial of service attack. This was discovered due to a public exploit.

  • A flaw in RPM, CVE-2011-3378 fixed by RHSA-2011:1349 where a specially-crafted RPM package that, when queried or installed, would cause rpm to crash or, potentially, execute arbitrary code prior to any signature checking. We're not aware of any working exploits for this issue.

  • Updates to blacklist the DigiNotar Certificate Authority.

Previous update releases

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 6 Server, but isn't really useful for comparisons with other major versions, distributions, or operating systems -- for example, a default install of either Red Hat Enterprise Linux 4AS and 6 Server does not include Firefox, but a default install of 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.



When we get notified of a security issue affecting a Red Hat product in advance we give an acknowledgement in the security advisory and in our CVE database.

We've now created a page to give acknowledgements to the companies and individuals that report issues in our online services, such as finding a cross-site scripting flaw in a Red Hat web site, or a vulnerability in OpenShift.



We pushed an update to Flash Player for Red Hat Enterprise Linux Supplementary today, on a Friday, because it fixed Critical vulnerabilities. But we try not to push updates on a Friday unless they are critical and already public.

So let's take a look at the most common times and days we push advisories for Red Hat Enterprise Linux 4, 5, and 6 (including Supplementary) using a heatmap:

heatmap

The more advisories pushed for a given date and hour, the darker that section of the graph is. So the most popular times for pushing advisories are Tuesdays at 10am and 2pm Eastern US time, Fridays are pretty light for pushes, and there was nothing during the weekends. The spread of the graph shows that we push advisories when they are ready, rather than waiting to a fixed day and time, in order to reduce the risk to users.

All the data used to create this graph is available as part of our public metrics. Thanks to Sami Kerola for the R code from which I based my graph generation.



For my Birthday my wife bought me a Peggy 2 kit, and I finally got around to adding the 625 10mm green LEDs. Some of the example programs are pretty neat but I wanted to make a side scroller with a nice font ready for halloween.

I decided on the Liberation Sans Narrow font, drew up a string of characters in The Gimp, converted it to have only 4 levels, then used a quick perl script to convert the image into program data for the scroller. I'm pretty happy with how it turned out. The scroller, image, and script are available here.



Every year since Red Hat Enterprise Linux 4 was released we've published a risk report where we look at the state of security of the distribution. We investigate the key vulnerabilities, metrics on vulnerability counts, and how users could have been exploited by them. The Six Years of Red Hat Enterprise Linux 4 report (PDF) covering Feb 2005-2011 was published today.

"Red Hat knew about 51.5% of the security vulnerabilities that we fixed in advance. The average time between Red Hat knowing about an issue and it being made public was 23 days (median 10 days).... A default installation of Red Hat Enterprise Linux 4 AS was vulnerable to 20 critical security issues over the first six years. "

The data we publish is interesting to get a feel for the risk of running Enterprise Linux, but isn't really useful for comparisons with other distributions, or operating systems. One important difference is that it is Red Hat policy to count vulnerabilities and allocate CVE names to all issues that we fix, including ones that are found internally. This is not true for many other vendors including folks like Microsoft and Adobe who do not count or disclose issues they fix which were found internally.



A few weeks ago the 2011 update to the CWE/SANS Top 25 Most Dangerous Software Errors was published. As part of our contribution to this update we analysed the most severe vulnerabilities that affected Red Hat since the last update and mapped each one to the appropriate Common Weakness Enumeration (CWE) type.

The table below lists all vulnerabilities which have a CVSS score of 7 or more ('high'), that we fixed in any product during calendar year 2010.

Most common CWE were:

  • Buffer Copy without Checking Size of Input (CWE-120): 8 vulnerabilities.
  • Race Condition (CWE-362): 5 vulnerabilities.

CVECWE2011 top 25?CVSS base scoreFixed in
CVE-2007-4567 CWE-476no 7.8 Red Hat Enterprise Linux 5 (kernel)
CVE-2009-0778 CWE-770no 7.1 Red Hat Enterprise Linux 5 (kernel)
CVE-2009-1385 CWE-191no 7.1 Red Hat Enterprise Linux 5 (kernel)
CVE-2009-3080 CWE-129no 7.2 Red Hat Enterprise Linux 3, 4, 5, MRG (kernel)
CVE-2009-3245 CWE-252no 7.6 Red Hat Enterprise Linux 3, 4, 5 (openssl)
CVE-2009-3726 CWE-476no 7.2 Red Hat Enterprise Linux 4, 5, MRG (kernel)
CVE-2009-4005 CWE-127no 7.1 Red Hat Enterprise Linux 4 (kernel)
CVE-2009-4027 CWE-362no 7.8 Red Hat Enterprise Linux 5 (kernel)
CVE-2009-4141 CWE-416no 7.2 Red Hat Enterprise Linux 5, MRG (kernel)
CVE-2009-4212 CWE-191no 10.0 Red Hat Enterprise Linux 3, 4, 5 (krb5)
CVE-2009-4272 CWE-764no 7.8 Red Hat Enterprise Linux 5 (kernel)
CVE-2009-4273 CWE-78yes 7.9 Red Hat Enterprise Linux 5 (systemtap)
CVE-2009-4537 CWE-120yes 7.1 Red Hat Enterprise Linux 4, 5, MRG (kernel)
CVE-2009-4895 CWE-362no 7.2 Red Hat Enterprise MRG (kernel)
CVE-2010-0008 CWE-606no 7.8 Red Hat Enterprise Linux 4, 5 (kernel)
CVE-2010-0291 CWE-822no 7.2 Red Hat Enterprise Linux 5 (kernel)
CVE-2010-0738 CWE-424no 7.5 JBoss Enterprise Application Platform 4.2, 4.3
CVE-2010-0741 CWE-20no 7.1 Red Hat Enterprise Linux 5 (kvm)
CVE-2010-1084 CWE-120yes 7.2 Red Hat Enterprise Linux 5 (kernel)
CVE-2010-1086 CWE-20no 7.8 Red Hat Enterprise Linux 4, 5 (kernel)
CVE-2010-1087 CWE-362no 7.2 Red Hat Enterprise Linux 5 (kernel)
CVE-2010-1166 CWE-823no 7.6 Red Hat Enterprise Linux 5 (xorg-x11-server)
CVE-2010-1173 CWE-120 *yes 7.1 Red Hat Enterprise Linux 4, 5 (kernel)
CVE-2010-1188 CWE-416no 7.8 Red Hat Enterprise Linux 3, 4, 5 (kernel)
CVE-2010-1436 CWE-120yes 7.2 Red Hat Enterprise Linux 5 (kernel)
CVE-2010-1437 CWE-362no 7.2 Red Hat Enterprise Linux 4, 5 (kernel)
CVE-2010-2063 CWE-823no 7.5 Red Hat Enterprise Linux 3, 4, 5 (samba)
CVE-2010-2235 CWE-77no 7.1 Red Hat Network Satellite Server 5.3 (cobbler)
CVE-2010-2240 CWE-788no 7.2 Red Hat Enterprise Linux 3, 4, 5, MRG (kernel)
CVE-2010-2248 CWE-682no 7.1 Red Hat Enterprise Linux 4, 5 (kernel)
CVE-2010-2492 CWE-805no 7.2 Red Hat Enterprise Linux 5, 6 (kernel)
CVE-2010-2521 CWE-805no 8.3 Red Hat Enterprise Linux 4, 5, MRG (kernel)
CVE-2010-2798 CWE-476no 7.2 Red Hat Enterprise Linux 5 (kernel)
CVE-2010-2962 CWE-823no 7.2 Red Hat Enterprise Linux 6, MRG (kernel)
CVE-2010-3069 CWE-129no 8.3 Red Hat Enterprise Linux 3, 4, 5, 6 (samba)
CVE-2010-3081 CWE-131yes 7.2 Red Hat Enterprise Linux 3, 4, 5, 6, MRG (kernel)
CVE-2010-3084 CWE-120yes 7.2 Red Hat Enterprise Linux 6 (kernel)
CVE-2010-3301 CWE-129no 7.2 Red Hat Enterprise Linux 6 (kernel)
CVE-2010-3302 CWE-120yes 7.1 Red Hat Enterprise Linux 6 (openswan)
CVE-2010-3308 CWE-120yes 7.1 Red Hat Enterprise Linux 6 (openswan)
CVE-2010-3432 CWE-805 *no 7.8 Red Hat Enterprise Linux 4, 5, 6, MRG (kernel)
CVE-2010-3705 CWE-788no 8.3 Red Hat Enterprise Linux 6, MRG (kernel)
CVE-2010-3708 CWE-77no 7.5 JBoss Enterprise Application Platform 4.3, SOA Platform 4.2
CVE-2010-3752 CWE-78yes 7.1 Red Hat Enterprise Linux 6 (openswan)
CVE-2010-3753 CWE-78yes 7.1 Red Hat Enterprise Linux 6 (openswan)
CVE-2010-3847 CWE-426no 7.2 Red Hat Enterprise Linux 5, 6 (glibc)
CVE-2010-3856 CWE-426no 7.2 Red Hat Enterprise Linux 5, 6 (glibc)
CVE-2010-3864 CWE-362no 7.6 Red Hat Enterprise Linux 6 (openssl)
CVE-2010-3904 CWE-822no 7.2 Red Hat Enterprise Linux 5, 6 (kernel)
CVE-2010-4170 CWE-88no 7.2 Red Hat Enterprise Linux 4, 5, 6 (systemtap)
CVE-2010-4179 CWE-862yes 7.5 Red Hat Enterprise MRG (cumin)
CVE-2010-4344 CWE-120yes 7.5 Red Hat Enterprise Linux 4, 5 (exim)

* - in both these cases the outcome is not a buffer overflow as the possible overflow is detected and instead converted into an abort (DoS)

See also our 2010 analysis



Red Hat Enterprise Linux 5.7 was released last week (July 2011), six months since the release of 5.6 in January 2011. 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.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.

Number of security errata between
     5.6 and 5.7

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.

Critical vulnerabilities

The 4 critical advisories addressed 34 critical vulnerabilities across just 2 different packages:

  1. An update to OpenJDK 6 Java Runtime Environment, (June 2011) where a web site hosting a malicious Java applet could potentially run arbitrary code as the user.
  2. Three updates to Firefox (March 2011, April 2011, June 2011) where a malicious web site could potentially run arbitrary code as the user running Firefox.

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.

Other significant vulnerabilities

Although not in the definition of critical severity, also of interest during this period were a couple of flaws that were easily exploitable:

  • A flaw in dhcp, CVE-2011-0997, fixed by RHSA-2011:0428, where a malicious DHCP server could send a response that could lead to arbitrary code execution on connecting clients.
  • A flaw in glibc, CVE-2011-0536, fixed by RHSA-2011:0412, where a local user could gain root privileges.

In addition, updates to Firefox and NSS were made to blacklist a number of compromised SSL certificates.

Previous update releases

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:

Errata per month for each update release

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.



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:

  1. 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.
  2. 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.
  3. Two updates to Thunderbird (March 2011, April 2011) where a malicious email message could potentially run arbitrary code as the user running Thunderbird.
  4. 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.

<< prev [ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 ] next >>

       


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, apacheweek, cve, cvss, fedora, ha, metrics, microsoft, redhat, security, trips


Subscribe to RSS feed