Cisco Blogs

The Missing Manual: CVRF 1.1 Part 2 of 2

- May 18, 2012 - 0 Comments

This post is a continuation of The Missing Manual: CVRF 1.1 Part 1 of 2.

Praxis: Converting an existing document to CVRF

Now it’s time for some XML! Let’s take what you’ve learned and manually convert the Cisco RVS4000 and WRVS4400N Web Management Interface Vulnerabilities security advisory into a CVRF document. Please note that this process is meant to be instructive and somewhat of a stream-of-consciousness-narrative of how to manually build your first CVRF document. It is expected that, by and large, this process would itself be automated and CVRF document producers would have in-house code to parse their own documents and emit CVRF.

Now is a good time to visit the CVRF 1.1 homepage and check out the schemata, dictionary, and mind map.

From here on out, the original Cisco security advisory HTML document will be referred to as “SA,” while the CVRF document will be referred to as “CVRF document” or some derivative. Remember that an XML schema defines the structure and content of the elements inside an XML document, as well as the order they can be in. This means that we might have to hunt around the SA to find all of the elements we want or need, but we must conform to the order set out by the schema. Before starting this section, have a quick look at the SA and be comfortable with its format and sections.

Disclaimer: What follows should be considered a tutorial only. Not all of the SA is translated into the CVRF document and is by no means a Cisco PSIRT authored or endorsed document.

Root (Document) Level

1) We’ll start with a standard XML prologue specifying the version, encoding and the namespace for the schema:

<?xml version="1.0" encoding="UTF-8"?>
<cvrfdoc xmlns="" xmlns:cvrf="">

2) We’ll choose a title for our CVRF document. This is a required, human-readable field, and we’ll simply copy over the SA title:

    <DocumentTitle>Cisco Security Advisory: Cisco RVS4000 and WRVS4400N Web Management Interface Vulnerabilities</DocumentTitle>

3) Next we add the required field, Document Type, another human-readable field that we’ll call “Security Advisory”:

    <DocumentType>Security Advisory</DocumentType>

4) Next we add the required field, Document Publisher. All that is required is the type, and we’ll fill that in as Vendor. Note that unlike the previous fields, we can only choose from five different values (vendor, discoverer, coordinator, user, other):

    <DocumentPublisher Type="Vendor"/>

5) The large, monolithic and required Document Tracking container is next. Comments are inline.


5a) The required Identification container holds one ID string and additional optional Alias strings that identify the CVRF document. The required ID element is set to the Cisco-specific identifier for the SA, which is derived from the “Advisory ID” field of “cisco-sa-20110525-rvs4000”.


5b) The required Status element is set from the “Status of this Notice” field in the SA, which is “Final”.


5c) The required Version element is set from the “Revision” field of the SA, which is “1.1”. The Revision History is taken from the SA fields of the same name. All elements are required.

                Modified software table to indicate that First Fixed release for RVS4000v1 is
                <Description>Initial public release.</Description>

5d) The required Initial and Current Release Date elements are adapted from the SA fields “Initial Public Release” and “Last Updated”.


6) The next container is Document Notes. This is where we store all freeform human-readable text blurbs from around the SA and its use is completely optional. The first Note we create is to hold the SA Summary. The only required attributes are Type, which is “Summary” for the first Note and “Legal Disclaimer” for the second, and Ordinal, which is a locally significant counter used to track all of the Document Notes and we set to “001” and “002”. We’ll entitle the first Note as “Summary” and the second as “Legal Disclaimer” and include an Audience set to “All” for both. Both attributes are human-readable fields. Finally, we include the XML:lang attribute to indicate the language of both Notes, in this case, English. The use of the XML:lang attribute is completely optional when you’re writing in English, since that is the default. If you change to a different language, you would then use it to specify which one.

        <Note Title="Summary" Audience="All" Type="Summary" Ordinal="001" xml:lang="en">
        Cisco RVS4000 4-port Gigabit Security Routers and Cisco WRVS4400N Wireless-N Gigabit Security Routers have several web interface vulnerabilities that can be exploited by a remote, unauthenticated user. Cisco has released free software updates that address these vulnerabilities. Workarounds that mitigate these vulnerabilities are available. This advisory is posted at
        <Note Title="Legal Disclaimer" Audience="All" Type="Legal Disclaimer" Ordinal="002" xml:lang="en">

7) Acknowledgements is an optional container, but since the SA credits the original discoverer, we will include one here.

            <Name>Michal Sajdak</Name>
            <Organization>Securitum, Poland</Organization>

8) Also optional is the Document References container. For posterity, we will include a single Related Document that refers to the original HTML SA. The Type of reference is self because we’re referring to a different representation of the same document. The URL points to the HTML SA (a CRLF is inserted to preserve readability in the whitepaper, but should not used in an actual CVRF document) and the human-readable Description is nominal.

        <Reference Type="Self">
            <Description xml:lang="en">URL to the html advisory.</Description>

9) The Document Distribution comes next. We find it in the SA under “Distribution”. This is another human-readable field and I prefer to remove all non-character data (bullets and such):

    This advisory is posted on Cisco's worldwide website at In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. - cust-security - - - - - - - - Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates.

Product Tree

Next we will build our Product Tree to contain all of the products we will reference in the Vulnerability section of the CVRF document. After reading the SA, we find in the “Affected Products” section that there are five products affected by the vulnerability, and in the “Software Versions and Fixes” section there are three “first fixed” products (two of the affected versions have been end-of-life’d and are no longer supported):

Affected Products:

  1. Cisco RVS4000 Gigabit Security Router version 1
  2. Cisco RVS4000 Gigabit Security Router version 2
  3. Cisco WRVS4400N Wireless-N Gigabit Security Router version 1.0
  4. Cisco WRVS4400N Wireless-N Gigabit Security Router version 1.1
  5. Cisco WRVS4400N Wireless-N Gigabit Security Router version 2.0

Fixed Products:

  1. Cisco RVS4000 Gigabit Security Router version
  2. Cisco RVS4000 Gigabit Security Router version
  3. Cisco WRVS4400N Wireless-N Gigabit Security Router

In the following example, we will use the “Branched” method of Product Tree creation to insert the above products. It affords the most machine-readable method of product enumeration (the “Concatenated” method does a similar job, but this SA contains no product dependencies).

1) The first element is the Product Tree container that specifies the schema.

    <ProductTree xmlns="">

2) We then construct each product using the Branched method. Since all of the products are vended by Cisco, our top level Branch container is Type “Vendor” and Name “Cisco”. Both attributes are required.

        <Branch Type="Vendor" Name="Cisco">

3) This level of nesting actually splits. We first handle the “RVS4000” products and we finish up with the “WRVS4400N” products. This is the Product Family and we assign Type and Name accordingly.

            <Branch Type="Product Family" Name="RVS4000">

4) Next is the canonical name of the product. We assign this Type as Product Name with a Name value of “Gigabit Security Router”.

                <Branch Type="Product Name" Name="Gigabit Security Router">

5) The last branch contains the product version. We assign this Type as Product Version with a Name value of “1”. We then terminate this branch with a Full Product Name and our first Product ID. The FullProductName contains the canonical or “friendly” name of the referenced product. In this (and probably most) cases, it is the additive result of the individual branches, or “Cisco RVS4000 Gigabit Security Router version 1”. The ProductID is chosen to be illustrative and demonstrative at “CVRF1.1-PID-0001”. In practice, it can be anything unique to Product Tree.

                    <Branch Type="Product Version" Name="1">
                        <FullProductName ProductID="CVRF1.1-PID-0001">Cisco RVS4000 Gigabit Security Router version 1</FullProductName>

6) The remainder of the Product Tree elements are constructed in the same manner.

                    <Branch Type="Product Version" Name="2">
                        <FullProductName ProductID="CVRF1.1-PID-0002">Cisco RVS4000 Gigabit Security Router version 2</FullProductName>
                    <Branch Type="Product Version" Name="">
                        <FullProductName ProductID="CVRF1.1-PID-0006">Cisco RVS4000 Gigabit Security Router version</FullProductName>
                    <Branch Type="Product Version" Name="">
                        <FullProductName ProductID="CVRF1.1-PID-0007">Cisco RVS4000 Gigabit Security Router version</FullProductName>
            <Branch Type="Product Family" Name="WRVS4400N">
                <Branch Type="Product Name" Name="Wireless-N Gigabit Security Router">
                    <Branch Type="Product Version" Name="1.0”>
                        <FullProductName ProductID="CVRF1.1-PID-0003">Cisco WRVS4400N Wireless-N Gigabit Security Router version 1.0</FullProductName>
                    <Branch Type="Product Version" Name="1.1">
                        <FullProductName ProductID="CVRF1.1-PID-0004">Cisco WRVS4400N Wireless-N Gigabit Security Router version 1.1 </FullProductName>
                    <Branch Type="Product Version" Name="2.0">
                        <FullProductName ProductID="CVRF1.1-PID-0005">Cisco WRVS4400N Wireless-N Gigabit Security Router version 2.0</FullProductName>
                    <Branch Type="Product Version" Name="">
                        <FullProductName ProductID="CVRF1.1-PID-0008">Cisco WRVS4400N Wireless-N Gigabit Security Router version</FullProductName>


The final section contains the actual vulnerabilities documented in the SA. If we read the “Details” section of the SA, we find that there are three vulnerabilities:


  1. CVE-2011-1645: Retrieval of the configuration file
  2. CVE-2011-1646: Root operating system arbitrary command injection by an authenticated attacker
  3. CVE-2011-1647: Retrieval of admin SSL certificate private key

We will document each in its own Vulnerability container.

1) First element is the Vulnerability container that has a required attribute, Ordinal.

    <Vulnerability Ordinal="1" xmlns="">

2) Next we have the human-readable Title. We simply copy the canonical name from the SA.

        <Title>Retrieval of the configuration file</Title>

3) Next we find the Notes container. Structurally, it is the same as the Document Notes container above. In this case, it contains details about the vulnerability and is typed and titled as such. We see the first usage of CDATA here, as there is an ampersand in the original text (which, from an XML point of view, it tells the parser an escape sequence is forthcoming).

            <Note Type="Details" Ordinal="003" Title="Details" Audience="All">
            <![CDATA[ The Cisco RVS4000 and WRVS4400N Gigabit Security Routers deliver high-speed network access and IPsec VPN capabilities for small businesses. They also provides firewall and intrusion prevention capabilities. The Cisco RVS4000 and WRVS4400N Gigabit Security Routers contains a web management interface vulnerability: Retrieval of the configuration file If an administrator of the device has previously created a backup  of the configuration, using Administration --> Backup & Restore --> Backup, it is possible for a remote unauthenticated user to access the backup configuration file.  This file contains all configuration parameters of the device, including the HTTP authentication password and VPN pre-shared-keys (PSKs).]]>

4) The release date of the vulnerability is set as the initial release date of the advisory.


5) The Involvements container houses information about the document producer’s engagement status of vulnerability. In this case, the Party is Cisco (the vendor of the product) and their involvement Status is considered Completed (the vulnerability is fully identified and scoped and the remediation process is finished).

            <Involvement Party="Vendor" Status="Completed">
                <Description>Cisco has completed involvement in this vulnerability.</Description>

6) We find a CVE ID for the vulnerability in the SA’s “Details” section.


7) Now we move on to the Product Statuses. This is where we enumerate the list of products that are directly concerned with vulnerability. The guidance here is to list the affected products followed by the fixed or recommended products.

        <Products Statuses>

7a) If we look at the “Affected Products/Vulnerable Products” section we will note which products and versions are vulnerable. If we then refer back to the Product Tree, we can enumerate their Product IDs.

            <Status Type="Known Affected">

7b) If we look at the “Software Versions and Fixes” section we will note which products and versions are fixed. If we then refer back to the Product Tree, we can enumerate their Product IDs.

            <Status Type="First Fixed">
        </Product Statuses>

8) Next we happen upon the Threats container. If we peruse the “Impact” section of the SA we find a description. That’s fodder for our Impact typed Threat container. The omission of any Product or Group IDs means this threat applies to all of the vulnerable products.

            <Threat Type="Impact">
                Successful exploitation of the vulnerability may result in execution of arbitrary commands on the device by an authenticated user or retrieval of configuration files and private keys by an unauthenticated user. The configuration files contain sensitive information in text, such as the HTTP passwords and PSKs. The retrieval of the certificates may aid in further attacks.

9) The next container we come across is the CVSS Score Sets. This stuff can be found in the “Vulnerability Scoring Details” section. A Score Set will always have a Base Score, but the Temporal and Environmental scores, as well as the Vector, are optional. In this case, we have a temporal score and a Vector and we fill them in accordingly.


10) The final section for Vulnerability is the Remediation container.


10a) The first step here is to determine the type of Remediation. We learn from the “Software Versions and Fixes” section that there is an official vendor fix, and we assign that as the Type.

            <Remediation Type="Vendor Fix">

10b) The mandatory Description element is created from the same section.

                The official fix from Cisco is to upgrade to the latest software release, the first fixed version is In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Small Business Support Center or your contracted maintenance provider for assistance.

10c) Entitlement is optional to the Remediation container, but likely a legal mandate by the Cisco powers that be. It is copied from the “Obtaining Fixed Software” section.

                Cisco has released free software updates that address this vulnerability. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at , or as otherwise set forth at Downloads at . Do not contact or for software upgrades. Customers should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at If the information is not clear, please contact the Cisco Small Business Support Center or your contracted maintenance provider for assistance. Small Business Support Center contacts are as follows. +1 866 606 1866 (toll free from within North America) +1 408 418 1866 (toll call from anywhere in the world) Customers should have their product serial number available. Refer to for additional support contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages.

10d) URL to the fixed software is optional but included here as it is specified by the SA in the “Software Versions and Fixes” section. Note the use of the ampersand escape sequence to specify the “&” in the query string portion of the URL.


10e) Finally we come to the last element in the Remediation section, the optional Product ID. Inclusion of this(these) element(s) constrains the Remediation container to apply to only the product(s) listed. Exclusion of the element implies that the Remediation is general or applies to all vulnerable products.


10f) Now we can move on to the next two Remediation containers, which are constructed similar to the first, the only notable differences being the Description, the Product ID and the URL of the last one. All of this information is in the same section, “Obtaining Fixed Software”. The entitlement is omitted to keep the code short, sweet and DRY.

            <Remediation Type="Vendor Fix">
                <Description>The official fix from Cisco is to upgrade to the latest software release, the first fixed version is</Description>
            <Remediation Type="Vendor Fix">
                <Description>The official fix from Cisco is to upgrade to the latest software release, the first fixed version is</Description>

10g) Note we have multiple Product ID’s here.


10h) This Remediation container is slightly different because it holds the workaround discussed in the SA in the section entitled “Workarounds” and it applies to all of the vulnerable products.

            <Remediation Type="Workaround">
                Disable remote management: Caution: Do not disable remote management if you manage the device via the WAN connection. Doing so will result in loss of management connectivity to the device. Remote Management is disabled by default. If it is enabled, administrators can disable it using the Firewall > Basic Settings screen. Change the setting for the field "Remote Management" to "Disabled". Disabling remote management limits the exposure of the vulnerabilities to those on the local LAN. Limit remote management access to specific IP addresses: If remote management is required, harden the device so that it can be accessed only by certain IP addresses, rather than the default setting of "any". By entering the configuration screen at Firewall --> Basic Settings, an administrator can change the Remote IP address field to ensure only devices with the specified IP addresses can access the device. Remove all backup configuration files from the device: Rebooting the device after performing a configuration backup, will remove the configuration file from the system so that it can not be retrieved by an unauthenticated user.

11) The remaining two vulnerabilities are quite similar to the first in terms of construction and content. To close out our CVRF document, for brevity’s sake, they are left to you as an exercise.

    <Vulnerability Ordinal=”2” xmlns="">
        <Title>Root operating system arbitrary command injection by an authenticated attacker</Title>
    <Vulnerability Ordinal=”3” xmlns="">
        <Title>Retrieval of admin SSL certificate private key</Title>

Looking Ahead: What’s Next for CVRF?

As CVRF evolves, it will change and grow as per the feedback from its users. The follow items are on the docket for inclusion in subsequent release(s) of CVRF. The list is not exhaustive and subject to change.

  • XML Security: Support for the signing and encrypting of XML documents as per the W3C recommendations on XML Signature Syntax and Processing.
  • Producer-Specific Tags: Support for producer-specific elements that would enable a document producer to include their own XML tags to add functionality to CVRF. The working group is carefully discussing this feature. We want to avoid a situation where it would enable the creation of new CVRF dialects and eventual end-user confusion.
  • Proof of Concept Container: Support for inclusion of proof-of-concept / vulnerability reproduction steps. We have started to work on high-level plans to enable document producers to include step-by-step instructions to reproduce a vulnerability and include exploit code.

Special Thanks

I’d like to take a quick minute to call out to the CVRF Core Team who went above and beyond to ensure CVRF was built the way it needed to be:

  • Joe Clarke, Cisco Systems
  • Troy Fridley, Cisco Systems
  • Joe Hemmerlein, Microsoft Corporation

Without your help we wouldn’t be here today. Thanks guys.

Leave a comment

We'd love to hear from you! To earn points and badges for participating in the conversation, join Cisco Social Rewards. Your comment(s) will appear instantly on the live site. Spam, promotional and derogatory comments will be removed.

All comments in this blog are held for moderation. Your comment will not display until it has been approved

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.