Understanding the Red Hat security impact scale

Red Hat uses a four-point impact scale to classify security issues affecting our products. Have you ever asked yourself what it takes and what the requirements are for each point of the scale? We will talk through the highlights of our process in this article.

Is this a CVE?

First and foremost, what is a CVE? Short for Common Vulnerabilities and Exposures, it is a list of publicly disclosed computer security flaws. Learn more in this Red Hat post.

To receive a severity rating, the issue needs to be a CVE. But what does it take to be a CVE? In order to warrant a CVE ID, a vulnerability has to compromise one or more of the three pillars of the CIA triad: Confidentiality, Integrity and Availability.

If the issue doesn’t directly compromise any of these three pillars, the issue is not a CVE. It might be a weakness, but it is not a CVE.

Is my software affected?

If one or more items in the CIA triad are compromised and it warrants a CVE ID, the next question is: is my software affected?

To establish the affected-ness of a CVE, we need to first outline some glossary terms:

• Impacted or Vulnerable: The vulnerable code is present in the runtime code and there is real impact to the CIA triad. Therefore, the vulnerability is suspected to be potentially exploitable.
• Exploited or Exploitable: The vulnerability is proven to be exploited or exploitable.
• Mitigated: The vulnerable code is included in the runtime code. Hence, the component is affected, but action can be taken to reduce the impact of a security vulnerability without deploying any fixes.
• Runtime code: The executable software that is actually delivered to customers.

Thus, affected means any software that contains vulnerable runtime code that is shipped to the end user.

We do not state the not-affectedness of every product in our CVE pages because the page would end up becoming very lengthy. However, we do state “Not Affected” in the CVE pages when the component is present in the product, but the specific version shipped on the product is not affected by the CVE. The absence of a product in a CVE page means that it is not shipped on that product and thus, not affected.

Our impact scale and NIST

The CVE program doesn’t require a CVSS score for every assigned CVE. In order to overcome this limitation and try to get a sense of the security impact of a CVE, the US Government tasked The National Institute of Standards and Technology (NIST) to run the National Vulnerability Database (NVD), which originally was designed to serve as a reference to the U.S. Government. NIST created an impact scale directly mapped to the calculated CVSS scores:

The NVD feed was quickly adopted by the community and security scanners, using NIST’s score and severity as their reference. NIST rates the vulnerability in the component using a generalized (not product specific) approach without evaluating how a component is used in individual products that ship it.

For each vulnerability that potentially affects Red Hat products, our analysts duly and diligently evaluate them, taking into account how the vulnerability is actually exposed and exploitable in what we provide to our customers. The vulnerability can be mitigated by operating system countermeasures, such as SELinux or compiler flags, or how it is exposed on a product. For example, a critical vulnerability in a Red Hat Enterprise Linux (RHEL) component affecting a TCP/IP endpoint that’s only exposed to localhost in Red Hat OpenShift, makes it a strong candidate for a downgrade.

By providing the Red Hat severity ratings, we are adding value for our customers, providing relevant ratings as a reliable tool to help them decide when and how to deploy security updates in their systems, properly establish the affectedness, and improve the availability and reliability of their systems.

However, relying solely on CVSS scores or vendor severity ratings is not a good risk management practice. Customers should always take into account how and where the system is deployed, the criticality of the affected system and its information, and the environment and any other key factors that will help their teams make a good assessment of the actual risk of a CVE in their environment.

The Red Hat impact scale

Red Hat uses a four-point impact scale to rank the CVE vulnerabilities: Low, Moderate, Important and Critical. In that order.

What does it take to qualify for each rating? Let’s look at some real-world examples.

Critical

The key to Critical impact is system compromise and malicious code execution without any user interaction. The poster child example for this is the Log4Shell vulnerability: CVE-2021-44228.

This famous vulnerability allowed a specially crafted URL at the vulnerable server to gain access to the remote system. The vulnerability lay on the Logging subsystem, which actually parsed the URL and duly understood that as a JNDI call, instead of blindly logging the entry. All it took was a trivial URL call and a vulnerable system. This is rooted on CWE-917 (Improper neutralization) and CWE-20 (Improper input validation).

Dissecting the Red Hat requirements for a Critical impact:

     “This rating is given to flaws that could be easily exploited (Yes) by a remote unauthenticated attacker (Yes) and lead to system compromise (arbitrary code execution) (Yes) without requiring user interaction (Yes). Flaws that require authentication (No), local or physical access to a system (No) or an unlikely configuration (No) are not classified as Critical impact.”

Bingo. Critical it is. If any of the above requirements weren’t true, it would be an Important or even Moderate impact CVE, but still retain a high CVSS score that could match the top of NIST’s scale. We’re talking more about the Integrity pillar. Availability issues, such as denial of service (DoS), don't qualify for a Critical impact, as it won’t lead to a remote code execution.

Important

Here, the requirements change significantly. There’s a lot of “or”s instead of the “and”s of the Critical. Now, it can affect any of the CIA pillars and encompasses DoS, among others. Let’s look at the key requirements:

“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 or authenticated users to gain additional privileges
• allow unauthenticated remote users to view resources that should otherwise be protected by authentication or other controls
• allow authenticated remote users to execute arbitrary code
• allow remote users to cause a denial of service”

Focus on the words “easily compromise” at the beginning of the text. We’re talking about a low effort level to break Confidentiality, Integrity or Availability. Confidentiality and Availability breakages can be carried out by unauthenticated remote users. Integrity breakage requires authenticated users.

The example here is the recent "Looney Tunables": CVE-2023-4911. This vulnerability affected glibc, an essential component in Linux operating systems that provides services to numerous and assorted library callbacks.

This vulnerability exploited a buffer overflow (CWE-122) and enabled a malicious attacker with a local system access and privilege to run executables to set a malicious GLIBC_TUNABLES environment variable prior to executing a setuid program, such as mount, exploit the buffer overflow, and elevate its privilege to the level of the setuid program. In that case, root.

Matching this CVE against the Important requirements statement:

“This rating is given to flaws that can easily compromise the confidentiality, integrity, or availability (yes, trivial as a shell) [...] vulnerabilities that allow local or authenticated users to gain additional privileges”

Yes, end of parsing. It is trivial, requires a local/authenticated user, and will yield an elevated privilege, breaking the system's integrity, potentially availability and confidentiality too. Solid match for an Important rating.

Moderate

For Moderate impact, the requirements revolve around “flaws that may be more difficult to exploit”. They “could have had a Critical or Important impact but are less easily exploited based on a technical evaluation of the flaw, and/or affect unlikely configurations”.

Let’s evaluate CVE-2023-3128, an interesting Grafana issue with a hefty CVSS 9.8 score. In this vulnerability, the attacker can just follow the step-by-step recipe on the internet (qualifies for Critical, easy to exploit), you don’t have to have any footprint on the system (trumps Important, qualifies for Critical), and get a full compromise of the Azure environment of the victim (also on Critical requirements). The CWE type for this vulnerability is CWE-290, an Authentication Bypass by spoofing. Except for the fact that the Azure AD access needed to carry the attack is not supported in our products and is also disabled, making it an “unlikely configuration”. Therefore, this issue was downgraded to Moderate.

Low

These are the ones that require unlikely circumstances, theoretical and unproven security attacks, or minimal consequences.

Now, let’s look at CVE-2023-48232. This CVE affected vim, the famous text editor. This vulnerability is triggered when smooth scrolling is enabled, a window border is present, and also requires specific vim configuration settings, on grounds of CWE-755, an Improper Handling of Exceptional Conditions. The result of the exploit is a crash on vim.

While we have unlikely configurations, all that happened was a crash on vim, which belongs to the “minimal consequences” category.

Wrap up

After walking through these four examples, we hope that it clarifies how Red Hat Vulnerability Management assessment works and adds value to the risk management for our customers, instead of blindly assigning impact to scores.

Learn more about Red Hat Product Security