Sample Red Hat Security Advisory in CVRF 1.1 format

In early 2011, 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 produces a version of some of our security advisories in machine readable format, as OVAL (Open Vulnerability and Assessment Language) definitions, but these are really designed for automated test tools to determine the need to apply an update. CVRF is more useful for providing customers with a machine readable view of all our security advisories.

CVRF 1.0 was released in May 2011 and although we produced some sample documents it wasn't widely adopted by industry. Another year of work later and CVRF 1.1 was released this week. Don't let the minor revision number fool you, the format is quite different to 1.0, and substantially better.

We have created an internal tool to allow us to automatically create CVRF documents from an existing advisory and have provided a sample set of advisories converted into CVRF 1.1 format for download.

We've been really pleased with the way CVRF 1.1 has turned out, and it will be a useful way for vendors to provide machine-readable advisories to customers as well as to tool vendors, filling a gap between OVAL definitions and text advisories.

The rest of this article takes a look at how our CVRF documents will be constructed, and will be useful if you are writing a tool to parse CVRF documents, or you are looking for a way to machine parse our advisories.

Last year we made a sample from a recent Red Hat Enterprise Linux security advisory and deconstructed how it looked as a CVRF 1.0 document. Let's take the same sample and see how it looks in CVRF 1.1.

Our advisories often fix more than one vulnerability at a time and for more than one major version of a product, but for this example we'll keep it simple: RHSA-2010:0888 was an Enterprise Linux 6 update to fix the vulnerability CVE-2010-3864 affecting OpenSSL.

CVRF is XML based, and in order to be a valid document the elements need to be in the right order as defined in the schema.

<?xml version="1.0" encoding="utf-8"?>
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
  <DocumentTitle xml:lang="en">Red Hat Security Advisory: openssl security update</DocumentTitle>
  <DocumentType>Security Advisory</DocumentType>
  <DocumentPublisher Type="Vendor">
    <ContactDetails>secalert@redhat.com</ContactDetails>
    <IssuingAuthority>Red Hat Security Response Team</IssuingAuthority>
  </DocumentPublisher>

The first section, above, illustrates that we're publishing this CVRF as the authoritative vendor ("Issuing Authority") for affected Red Hat products, and this is a Security Advisory ("Document Type"). Note that all our text fields that are likely to be displayed to a user have a language identifier ("en") as future CVRF advisories could contain multiple languages.

  <DocumentTracking>
    <Identification><ID>RHSA-2010:0888</ID></Identification>
    <Status>Final</Status>
    <Version>1</Version>
    <RevisionHistory>
       <Revision>
         <Number>1</Number>
         <Date>2010-11-16T11:08:00Z</Date>
         <Description>Current version</Description>
       </Revision>
    </RevisionHistory>
    <InitialReleaseDate>2010-11-16T11:08:00Z</InitialReleaseDate>
    <CurrentReleaseDate>2010-11-16T11:08:00Z</CurrentReleaseDate>

This next section contains meta data about the document itself, and is a mandatory requirement of CVRF documents. When Red Hat releases an update to a security advisory we usually update the text to explain the revision and we don't have this internally as a separate field, so for now our CVRF "Revision Description" section won't have useful comments even though the initial and current "Release Date" will be accurate. Occasionally our initial "Version" may start with a number greater than "1", this is not a mistake but can happen due to internal processes.

The two "Release Date" fields contain times as well as dates, these give the exact time when the advisory became public on our web site, and available to customers via Red Hat Network (the "Z" prefix specifies the UTC time zone).

    <Generator>
      <Engine>Red Hat rhsa-to-cvrf 1.0.1478</Engine>
      <Date>2012-05-08T10:26:11Z</Date>
    </Generator>
  </DocumentTracking>

During the design of CVRF 1.0 we championed this separate "Generator" section, which mirrors a similar section in OVAL documents. By knowing what created the CVRF document and when we can track down the cause of any errors in published documents, and allows us to regenerate a document if our generation scripts are altered, without causing a new document revision.

  <DocumentNotes>
    <Note Title="Topic" Type="Summary" Ordinal="1" 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.
</Note>
    <Note Title="Details" Type="General" Ordinal="2" 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.
</Note>
    <Note Title="Terms of Use" Ordinal="3" Type="Legal Disclaimer" xml:lang="en">
Please see https://www.redhat.com/footer/terms-of-use.html
</Note>
  </DocumentNotes>

The document "summary" and "details" sections above are direct copies of the equivalent sections from the text version of our advisory. This does have the consequence that the details of the separate vulnerabilities will get repeated, as later each vulnerability gets its own individual section with a description, CVE name, and acknowledgments.

There is a big difference to CVRF 1.0 here as these text sections are now all included in "Note" elements with attributes specifying the type of note. A mandatory, unique, "Ordinal" number is also used so a specific note can be referred to (although we don't do that in our CVRF documents).

  <DocumentDistribution xml:lang="en">Copyright © 2010 Red Hat, Inc. All rights reserved.</DocumentDistribution>
  <AggregateSeverity Namespace="https://access.redhat.com/security/updates/classification/">Important</AggregateSeverity>

Next are the distribution terms and overall severity rating for the issues in this document. CVRF does not impose any particular severity definitions on vendors, instead the new "Namespace" attribute is used to reference a document that describes the scheme being used.

  <DocumentReferences>
    <Reference Type="Self">
       <URL>https://rhn.redhat.com/errata/RHSA-2010-0888.html</URL>
       <Description>https://rhn.redhat.com/errata/RHSA-2010-0888.html</Description>
    </Reference>
    <Reference>
       <URL>http://www.redhat.com/security/updates/classification/#important</URL>
       <Description>http://www.redhat.com/security/updates/classification/#important</Description>
    </Reference>
  </DocumentReferences>

External references can appear both here, at the top level of a CVRF document, as well as specific for each vulnerability later. The most important top level reference is the self reference which links to the full HTML representation of the advisory, and now with CVRF 1.1 it's now possible to tell which reference this is from the "Type" attribute.

  <ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
    <Branch Type="Product Family" Name="Red Hat Enterprise Linux">
...
      <Branch Type="Product Name" Name="Red Hat Enterprise Linux Desktop (v. 6)">
        <FullProductName ProductID="6Client">Red Hat Enterprise Linux Desktop (v. 6)</FullProductName>
      </Branch>
      <Branch Type="Product Name" Name="Red Hat Enterprise Linux Server (v. 6)">
        <FullProductName ProductID="6Server">Red Hat Enterprise Linux Server (v. 6)</FullProductName>
      </Branch>
    </Branch>
    <Branch Type="Product Version" Name="openssl-1.0.0-4.el6_0.1">
      <FullProductName ProductID="openssl-1.0.0-4.el6_0.1">
openssl-1.0.0-4.el6_0.1.src.rpm
      </FullProductName>
    </Branch>
...
    <Relationship ProductReference="openssl-1.0.0-4.el6_0.1" 
            RelationType="Default Component Of" RelatesToProductReference="6Client">
      <FullProductName ProductID="6Client:openssl-1.0.0-4.el6_0.1">
openssl-1.0.0-4.el6_0.1 as a component of Red Hat Enterprise Linux Desktop (v. 6)
      </FullProductName>
    </Relationship>
    <Relationship ProductReference="openssl-1.0.0-4.el6_0.1" 
            RelationType="Default Component Of" RelatesToProductReference="6Server">
      <FullProductName ProductID="6Server:openssl-1.0.0-4.el6_0.1">
openssl-1.0.0-4.el6_0.1 as a component of Red Hat Enterprise Linux Server (v. 6)
      </FullProductName>
    </Relationship>
  </ProductTree>

The "Product Tree" section is new to CVRF 1.1 and is the last top level section we use. It is used to describe the products that are affected by the issues outlined in the advisory. Because our sample advisory affects a lot of products we've cut it down above to just show two. It's quite a complicated section so will take a little extra explanation:

Red Hat advisories in CVRF format will mostly follow the same Product Tree layout. We start by defining the Product Family, in this case it is "Red Hat Enterprise Linux", and then inside that Family have each affected product. These product names are quite long and so get assigned a unique ProductID. Therefore where we've used the ProductID "6Server" we refer to the product named "Red Hat Enterprise Linux Server (v. 6)", part of the "Red Hat Enterprise Linux" family.

Next we list the affected components of the product. In this case it's the OpenSSL package, which in Red Hat Enterprise Linux is provided and installed as RPMs. We assign a unique ProductID to each affected component, so in this example when we use the ProductID "openssl-1.0.0-4.el6_0.1" we refer to the components which came from the source RPM "openssl-1.0.0-4.el6_0.1.src.rpm".

Finally, we set up the "Relationship" between the affected components and the affected products. So when we use the ProductID of "6Server:openssl-1.0.0-4.el6_0.1" we refer to the packages from source RPM openssl-1.0.0-4.el6_0.1 (openssl-1.0.0-4.el6_0.1.src.rpm) as a component of Red Hat Enterprise Linux Server (v. 6)" which is part of the "Red Hat Enterprise Linux" family of products. We will use these ProductIDs later when we list the vulnerabilities and show what was fixed.

Note that although the "Relation Type" of the components is given as "Default Component Of" it doesn't imply that the component will be installed on any given system, only that it's an available part of the product. The actual components installed on any given system vary depending on the type of installation done and subsequent changes made.

  <Vulnerability Ordinal="1" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
    <Notes>
       <Note Title="Vulnerability Description" Type="General" Ordinal="1" 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.
       </Note>
    </Notes>

Our documents have one "Vulnerability" section for each CVE fixed, and the vulnerability details are abstracted from the full advisory text. We don't give a title to the vulnerabilities, or an ID, as there will always be one to one mapping of vulnerability section to CVE. Here again we have a "Vulnerability" "Ordinal" used to number each vulnerability so we can refer between them, and another one for tracking multiple "Notes" (although we don't use either in our document).

    <DiscoveryDate>2010-11-03T00:00:00Z</DiscoveryDate>
    <ReleaseDate>2010-11-16T00:00:00Z</ReleaseDate>
    <Involvements><Involvement Party="Vendor" Status="Completed"></Involvement></Involvements>
    <CVE>CVE-2010-3864</CVE>

We set the "Discovery Date" as being the date that the vulnerability was first reported to (or discovered by) Red Hat. The "Release Date" is set to the date the vulnerability was first known to the public. So it's possible for the discovery date to be before the release date where we knew about a vulnerability in advance. These fields will rarely have a real time included and instead use "00:00:00 UTC" as a default.

As this CVRF is for a security advisory where an issue is being fixed, the "Involvements" section states that as a "Vendor" we have "Completed" dealing with this issue as we have released fixes.

The CVE name for the vulnerability is given. In some cases (not this one) our documents will contain the CWE name or names appropriate to the vulnerability.

    <ProductStatuses><Status Type="Fixed">
...
      <ProductID>6Client:openssl-1.0.0-4.el6_0.1</ProductID>
...
      <ProductID>6Server:openssl-1.0.0-4.el6_0.1</ProductID>
    </Status></ProductStatuses>

The "Product Statuses" section is new for CVRF 1.1 and replaces the "Affected Platform" and "Affected Release" sections. The section above illustrates that the vulnerability is "Fixed" by the given ProductIDs. Therefore this vulnerability is fixed by the openssl-1.0.0-4.el6_0.1 package for Red Hat Enterprise Linux Server (v. 6) and Client (v. 6).

    <Threats><Threat Type="Impact"><Description>Important</Description></Threat></Threats>
    <CVSSScoreSets><ScoreSet>
      <BaseScore>7.6</BaseScore>
      <Vector>AV:N/AC:H/Au:N/C:C/I:C/A:C</Vector>
    </ScoreSet></CVSSScoreSets>

Earlier we gave an overall severity rating for the entire document; now we give one specific to each vulnerability. The "Threats" section contains the "Impact" severity, and "CVSS Score Sets" gives a CVSS base score. CVSS scores are currently not included in our HTML or text advisories, but are available from our CVE database and Bugzilla entries, and now the CVRF documents.

    <Remediations>
      <Remediation Type="Vendor Fix">
        <Description 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
        </Description>
        <URL>https://rhn.redhat.com/errata/RHSA-2010-0888.html</URL>
      </Remediation>
    </Remediations>

The "Remediations" section contains a copy of our text advisory "Solution" section.

    <References>
      <Reference>
        <URL>https://www.redhat.com/security/data/cve/CVE-2010-3864.html</URL>
        <Description>CVE-2010-3864</Description>
      </Reference>
      <Reference>
        <URL>https://bugzilla.redhat.com/show_bug.cgi?id=649304</URL>
        <Description>bz#649304: CVE-2010-3864 OpenSSL TLS extension parsing race condition</Description>
      </Reference>
    </References>

The per-vulnerability "References" section gives links to our CVE database for the CVE as well as the Red Hat bug database for more technical details of the vulnerability and how it was addressed.

    <Acknowledgments><Acknowledgment><Description>
Red Hat would like to thank Rob Hulswit for reporting this issue.
    </Description></Acknowledgment></Acknowledgments>
  </Vulnerability>
</cvrfdoc>

After giving any per-vulnerability "Acknowledgements" we reach the end of this vulnerability. Our example advisory only had one "Vulnerability" section, but the whole section would be repeated where more are addressed.

When we first wrote about converting our advisories to CVRF 1.0 we had a number of suggestions and changes we wanted to make to enhance CVRF, and I'm pleased that as part of the working group we were able to see those become part of CVRF 1.1. The main missing feature is support for document signing. Send an email to secalert@redhat.com if you have comments on our CVRF samples or on any of the decisions we made on the conversion of the sample document.

Connect: