Red Hat Customer Portal

Skip to main content

Warning message

Log in to add comments.

How Red Hat uses CVSSv2 Scoring to assist in rating flaws

Vincent Danen published on 2013-02-13T13:00:46+00:00, last updated 2016-07-07T20:19:44+00:00

Red Hat rates all security flaws using a four-point scale: critical, important, moderate, and low. A number of factors contribute to this rating: How easily can a flaw be exploited? What kind of damage can be done if exploited? Are there typically other factors involved that lower the impact of the flaw (such as firewalls, Security-Enhanced Linux, compiler directives, and so forth)? CVSSv2 (Common Vulnerability Scoring System version 2.0) can also help to determine the rating.

Out of all of these factors that, combined, give us guidance on how to rate a flaw, the one that requires the most explanation is the CVSSv2 score and the metrics that contribute to it.

A CVSSv2 score is a number from 0.0 to 10.0 that is derived from a set of metrics (one example of which is illustrated as AV:N/AC:M/Au:N/C:N/I:P/A:N, which provides the base score of 4.3). This score might generally equate to a moderate impact flaw; however, Red Hat's flaw rating is based on the criteria defining the four-point scale. CVSSv2 provides additional information, but it does not have a direct impact on the flaw rating. The metrics and their description are available on the Issue Severity Classification page.

While there are other CVSSv2 metrics, and different types of scores, Red Hat only uses the Base metrics and does not use the Environmental or Temporal metrics. The reason for not using the Environmental or Temporal metrics is that these metrics (and the resulting scores) may change over time: a flaw that right now has only a proof of concept may in a week or a month have a functional exploit, which would adjust the Temporal metrics and score. These transient scores have no real affect on the flaw itself, however. Likewise, the Environmental metrics are very much specific to individual users and organizations and their needs. A flaw in DHCP may be highly critical to an ISP, but of fairly low impact to a home user that runs a DHCP server on their home network. Because these metrics can change over time and are relevant to certain use cases and environments, they are not used to rate a flaw. A flaw itself is the same, regardless of whether there is a functional exploit or not.

The Base metrics are made up the following:

  • Access Vector (AV): How the vulnerability is accessed. For example, whether local access to a system is required, or if the vulnerability can be exploited remotely over a network.
  • Access Complexity (AC): Extra conditions required to trigger the vulnerability. For example, an uncommon configuration may be required.
  • Authentication (Au): What authentication, if any, an attacker requires.
  • Confidentiality (C): The risk of an information leak if the vulnerability is exploited.
  • Integrity (I): The risk of an attacker modifying data on a system if the vulnerability is exploited.
  • Availability (A): The risk of an attacker causing a denial of service if the vulnerability is exploited.

For a complete description of each metric and their possible values, refer to the CVSS Guide.

If you were to look at Red Hat's CVSSv2 scores versus scores produced by others (authors of a particular piece of software, or databases like NVD), you might notice some discrepancies. For instance, one denial of service flaw in BIND (CVE-2012-5688) warranted a score of 7.8 from NIST, AV:N/AC:L/Au:N/C:N/I:N/A:C. However, Red Hat scored this flaw as 4.3, AV:N/AC:M/Au:N/C:N/I:N/A:P.

Why the difference? From a purely numeric standpoint, 7.8 suggests an important impact, whereas 4.3 would typically suggest a moderate impact.

Looking at the metrics, there are a few differences. The first is that the higher score has an Access Complexity (AC) metric of Low (L), whereas the Red Hat score has an AC of Medium (M). The second difference is that the Availability (A) metric is Complete (C) versus Partial (P).

When Red Hat sets the metrics for a flaw, we look at the issue in terms of the entire operating system. After all, Red Hat provides operating systems, middleware, layered products, and so forth -- not individual packages. We do not provide, in this instance, a product called BIND. That is what Internet Systems Consortium, Inc. (ISC) does. We provide Red Hat Enterprise Linux, which happens to include BIND (along with other similar components). Therefore, when computing the CIA (Confidentiality/Integrity/Availability) metrics, we look at the whole picture, not just BIND (or whatever the affected component is). So for upstream, the metrics refer to BIND itself -- A:C is justified. It is a complete loss of service to BIND (the named daemon). On Red Hat Enterprise Linux and Fedora, however, availability is not lost to our product (the operating system), just one part of it (this one service). This means the impact is lower (Partial versus Complete). This agrees with the official CVSS guide which states that impacts should be evaluated against the "entire system".

Denial of service flaws in the Linux kernel warrant A:C, because the entire system is unresponsive; typically, only kernel flaws warrant A:C.

For Access Complexity, the story is a little different. Upstream may look at this as "how difficult is it for the attacker to pull off an attack" as the only question to ask. However, that is not the entire picture. Red Hat asks many questions: How difficult is it for the attacker? Is this a default configuration? What privilege is required to change the default configuration to a vulnerable scenario? In our BIND example, this flaw requires that DNS64 support is enabled in named. This is a non-default configuration, and it would require root privileges to enable it. Likewise, the majority of deployments would not be allowing queries from untrusted clients (the notable exception being ISPs or other public DNS servers). Because of this, AC has a metric of Medium (M), which meets the specified criteria of "The affected configuration is non-default, and is not commonly configured (e.g., a vulnerability present when a server performs user account authentication via a specific scheme, but not present for another authentication scheme)" as noted in the CVSSv2 guide.

It is also interesting to note that, despite the CVSSv2 score of 4.3, Red Hat did rate this BIND flaw as an important impact issue. The CVSSv2 score, from a purely numeric standpoint, does not warrant that impact rating. This is one example of why CVSSv2 is not the sole factor that determines an impact rating. Red Hat fully recognizes that BIND is a pretty critical piece of software in typical infrastructure, and that the likelihood of being able to exploit the issue really has no bearing on the fact that, if the conditions were right, this would be easy to exploit and could cause significant issues. In this case, other factors contributed to the impact rating of important, not just the CVSSv2 score.

CVSSv2 is a guideline that helps to describe the characteristics and impacts of flaws. It does not provide a 1:1 mapping to impact or our four-point scale; as has been described, a 4.3 score does not necessarily mean a moderate impact flaw. It certainly helps to provide guidance, but it is not as fine-grained as it would need to be to reach the point of 1:1 mapping. For instance, there are cases where a 4.3 score would equate to a low impact issue. Red Hat assesses flaws on many criteria, some of which are not represented in CVSSv2 metrics.

Further information on Red Hat impact ratings and how CVSSv2 is used can be found on our Issue Severity Classification page. CVSSv2 base metrics are available for all vulnerabilities from 2009 onwards, as well as selected earlier vulnerabilities. These scores are found on the per CVE pages (linked to from the References section of each Red Hat Security Advisory) and also from our Security Measurements page.

About The Author

rhn-engineering-vdanen's picture

Vincent Danen

Vincent Danen lives in Canada and is a manager within Product Security at Red Hat. He joined Red Hat in February 2009 and has been working within the open source security world since 2002.