Skip to navigation

Issue Severity Classification

The Red Hat Security Response Team rates the impact of security issues found in Red Hat products using a four-point scale (Low, Moderate, Important, and Critical), as well as Common Vulnerability Scoring System (CVSS) base scores. These provide a prioritized risk assessment to help you understand and schedule upgrades to your systems, enabling informed decisions on the risk each issue places on your unique environment.

The four-point scale tells you how serious Red Hat considers an issue to be, helping you judge the severity and determine what the most important updates are. The scale takes into account the potential risk based on a technical analysis of the exact flaw and its type, but not the current threat level; a given rating will not change if an exploit or worm is later released for a flaw, or if one is available before the release of a fix.

Level Description
Critical impact This rating is given to flaws that could be easily exploited by a remote unauthenticated attacker and lead to system compromise (arbitrary code execution) without requiring user interaction. These are the types of vulnerabilities that can be exploited by worms. Flaws that require an authenticated remote user, a local user, or an unlikely configuration are not classed as Critical impact.
Important impact This rating is given to flaws that can easily compromise the confidentiality, integrity, or availability of resources. These are the types of vulnerabilities that allow local users to gain privileges, allow unauthenticated remote users to view resources that should otherwise be protected by authentication, allow authenticated remote users to execute arbitrary code, or allow local or remote users to cause a denial of service.
Moderate impact This rating is given to flaws that may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances. These are the types of vulnerabilities that could have had a Critical impact or Important impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.
Low impact This rating is given to all other issues that have a security impact. These are the types of vulnerabilities that are believed to require unlikely circumstances to be able to be exploited, or where a successful exploit would give minimal consequences.

A Red Hat security advisory can contain fixes for more than one vulnerability and for packages for more than one product (such as both Red Hat Enterprise Linux 5 and 6). Each issue in an advisory has an impact rating for each product. The overall severity of an advisory is the highest severity out of all the individual issues, across all the products the advisory targets. For simplicity, advisories only show the overall severity (except for kernel advisories, which list the severity of each issue). The advisories contain links to the relevant entries in Red Hat's bug-tracking system, where you can examine individual impacts and additional commentary.

When a technology—enabled and most likely used by default—completely blocks the exploitation of a particular vulnerability across all architectures, we will adjust the severity level. When a technology reduces the risk of a vulnerability, we may adjust the severity level and give an explanation of the decision in the bug-tracking entry.

Common Vulnerability Scoring System (CVSS)

Common Vulnerability Scoring System (CVSS) base scores give a detailed severity rating by scoring the constant aspects of a vulnerability: Access Vector, Access Complexity, Authentication, Confidentiality, Integrity, and Availability.

CVSS version 2 base metrics are available for all vulnerabilities from 2009 onwards, as well as selected earlier vulnerabilities. These scores are found on the CVE pages (linked to from the References section of each Red Hat Security Advisory) and also from our Security Measurements page.

CVSS v2 Base Metrics

The CVSS v2 base metrics group covers the constant aspects of a vulnerability:

  • 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.

A formula translates these measurements into a single, numerical base score, ranging from 0.0 (no risk) to 10.0 (highest risk). Refer to A Complete Guide to the Common Vulnerability Scoring System Version 2.0 for detailed descriptions of the base metrics.

How Red Hat Uses CVSS v2 Base Metrics

We aim to comply with the CVSS v2 standard when allocating base scores. There are circumstances where it may not be obvious why a particular score was chosen. The following are some common vulnerability types with our interpretation and typical scoring:

Libraries

It is not always possible to know how third-party applications use libraries, making it difficult to give accurate CVSS v2 base metrics for flaws in system libraries. When rating these flaws, we take into account the way the library is used by applications that we ship, but also look at other popular software that may use the library in a way that would cause an issue to be of higher severity, and adjust the score appropriately.

Web Browsers (and associated plug-ins)

There is a class of flaws in web browsers and their plug-ins that can allow a malicious web page to execute arbitrary code when the victim accesses the page. We rate these flaws as having Critical severity, even though they need some user interaction. Scoring these issues using CVSS v2 gives a base score of 6.8 (for example CVE-2009-1313). Because the desktop is running as a non-privileged user, the CVSS v2 Confidentiality, Integrity, and Availability impacts are all rated as Partial, and not Complete.

Other Common Scores

Flaws where a local, unprivileged user can cause a kernel to crash (denial of service) typically score 4.9 (for example, CVE-2009-1758).

Flaws that allow a local, unprivileged user to escalate their privileges to root typically score 7.2 (for example, CVE-2008-5182).

Cross-site scripting flaws are generally scored as having a partial loss of Integrity, with no loss to Confidentiality or Availability, in line with scoring from other vendors and NVD. A typical score for these flaws is 4.3 (for example, CVE-2009-0153).

Base Score Variations Across Products

It is common for a given CVE-named vulnerability to have several different CVSS v2 base metrics, depending on the product, version, and architecture. Examples of this include:

  • A vulnerability that only affected some architectures. For example, CVE-2007-6694 only affected PowerPC.
  • A vulnerability that is mitigated by source code protection mechanisms on some platforms. For example, CVE-2009-1252 could have led to arbitrary code execution on Red Hat Enterprise Linux 4, but it is only a denial of service on Red Hat Enterprise Linux 5.
  • A vulnerability that affected more than one application. For example, CVE-2009-0352 affected both Firefox (web browser) and Thunderbird (mail reader), but had a lower CVSS score and severity for Thunderbird.

If CVSS v2 base scores are significantly different across products, we give them separately wherever possible. If we do not split the score, we report the metric that gives the highest CVSS v2 base score (the worst-case outcome).

Differences Between NVD and Red Hat Scores

For open source software shipped by multiple vendors, the CVSS v2 base scores may vary for each vendor's version, depending on the version they ship, how they ship it, the platform, and even how the software is compiled. This makes scoring of vulnerabilities difficult for third-party vulnerability databases, such as NVD, who can give only a single CVSS v2 base score to each vulnerability.

These differences can cause the scores to vary widely. For example, NVD rates Firefox flaws as having Complete impact metrics because the Firefox application is also available for Microsoft Windows, where it is common that the user is running Firefox with administrator privileges. For Red Hat Enterprise Linux, we use Partial impact metrics, as Firefox is most likely to be run as an unprivileged user.

Red Hat creates CVSSv2 scores against the entire Red Hat or Red Hat JBoss product, not against an individual component within the product. This is why you may often see differences between Red Hat scores and NVD or upstream scores. For instance, if there is a denial of service flaw against Apache, upstream may score it A:C (complete loss of availability) because their product is httpd. Red Hat would score this as A:P (partial loss of availability) because the underlying operating system (our product) is still available, while only one service is unavailable. Red Hat only uses A:C for flaws that would render the entire system unavailable (typically kernel flaws).

For these reasons, we recommend that, whenever possible, you use a CVSS base score provided by Red Hat in preference to a score from a third party. Please let us know if you believe we have given an incorrect CVSS v2 base score for a particular vulnerability. We are happy to discuss the severity and update it if needed.