By Eugene Teo and Petr Matousek, Red Hat Product Security

Abstract

Red Hat uses a combination of a four-point severity scale and CVSS v3 base scores (these will be explained briefly later) to rate security flaws. This article concentrates on virtualization security flaws and how we rate them.

Why do we rate security flaws?

All software has flaws. Some flaws have security implications that malicious users can use to gain control over or obtain privileged information from affected systems. It is therefore important to know that, and how severe, these security flaws are.

Whenever a security update is made available, what do you do? It is unrealistic to expect everyone to update their system whenever a security update is released. Some users can only perform the update after office hours, and some can only do it during the weekend. Users digesting the advisories may not have the knowledge or know-how to perform a technical analysis of the flaws. At Red Hat, we differentiate security flaws from normal bugs and rate them according to their severity. These ratings provide prioritized risk assessments to help users understand at a glance how serious a flaw is, allowing them to make informed decisions as to what to do with the security updates in their environment.

How do we do it, and what is CVSS v3?

We use a four-point severity scale of Low, Moderate, Important and Critical, in combination with Common Vulnerability Scoring System (CVSS) version 3 base scores to rate the severity of the security flaws. Most of the time the CVSS v3 base scores are closely correlated to the four-point severity scale.

The four-point scale tells us how severe the flaw is. It takes into consideration all the possible and potential risks the flaw poses based on the technical analysis we perform on the flaw.

CVSS v3 base scores give a detailed severity rating by scoring the constant aspects of a security flaw. The constant aspects include the Access Vector (AV), Access Complexity (AC), Privileges Required (PR), User Interaction (UI), Scope (S), Confidentiality impact (C), Integrity impact (I), and Availability impact (A).

We will not go more in-depth into these as our Issue Severity Classification page has explained them clearly. If you are not familiar with CVSS especially, do read it up first before reading the rest of the article.

Why are virtualization security flaws different?

The CVSS v3 standard is still host-centric. It has not completely taken into account virtualization, and assumes security flaws only affect the host, without taking virtualization into account. CVSS v3 base scoring does not differentiate between whether the flaw affects the host or the guest operating system. It also does not differentiate between the impacts, and whether it affects the host or the guest or both. This can be tricky when interpreting the CVSS v3 base scores.

Because CVSS v3 does not work so well for virtualization security flaws, we have adopted the following guidelines to rate such flaws:

• If the user in the guest operating system is privileged, we will use PR:H.
• If the user in the host operating system is privileged, we will also use PR:H.
• If the user in the guest operating system is not privileged, we will use Au:N.
• If the security flaw is exploitable from the guest operating system, and it affects the guest only, we will use AV:L.
• If the security flaw is exploitable from the guest operating system, and it affects the host, we will use AV:A.
• If the security flaw can crash the guest or the host, we will use the highest impact and adjust the Confidentiality impact (C), Integrity impact (I), and Availability (A) impacts accordingly.
• For virtualization technologies like Xen where there is a hypervisor, a trusted domain0, and an untrusted domainU, we will assume that the hypervisor and domain0 are the host operating system, and that the domainU is the guest operating system. That is to say that, if the domain0 is compromised, it is equivalent to gaining access to the hypervisor.

Examples

The following five examples are of past virtualization security flaws with different severity impacts, and different CVSS v3 base scores and vectors. We explain how to interpret them based on our guidelines.

1. CVE-2011-1751
   cvss2=7.4/AV:A/AC:M/Au:S/C:C/I:C/A:C
   CVSS:3.0=6.6/AV:A/AC:L/PR:H/UI:R/S:U/C:H/I:H/A:H

   It was found that the PIIX4 Power Management emulation layer in qemu-kvm did not properly check for hot plug eligibility during device removals. A privileged guest user could use this flaw to crash the guest or, possibly, execute arbitrary code on the host. (CVE-2011-1751, Important)

   The host can be impacted from inside the guest, so we use AV:A.

   The C, I, and A impacts do not indicate if the impact is on the guest, or the host, or both, but since it is possible to execute arbitrary code on the host, we used the worst possible impact.

   A privileged guest user is indicated by PR:H, but it is unclear if the host user has these privileges.

2. CVE-2012-0045
   cvss2=4/AV:L/AC:H/Au:N/C:N/I:N/A:C
   CVSS:3.0=4.7/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:H

   A flaw was found in the way the Linux kernel's KVM hypervisor implementation emulated the syscall instruction for 32-bit guests. An unprivileged guest user could trigger this flaw to crash the guest. (CVE-2012-0045, Moderate)

   The host is not impacted as the flaw does not cross the guest boundary, we used AV:L.

   A:H indicates a High impact to Availability, but does not explain whether the guest or the host is becoming unusable.

3. CVE-2011-2519
   cvss2=5.2/AV:A/AC:M/Au:S/C:N/I:N/A:C
   CVSS:3.0=4.3/AV:A/AC:L/PR:H/UI:R/S:U/C:N/I:N/A:H

   A flaw was found in the way the Linux kernel's Xen hypervisor implementation emulated the SAHF instruction. When using a fully-virtualized guest on a host that does not use hardware assisted paging (HAP), such as those running CPUs that do not have support for (or those that have it disabled) Intel Extended Page Tables (EPT) or AMD Virtualization (AMD-V) Rapid Virtualization Indexing (RVI), a privileged guest user could trigger this flaw to cause the hypervisor to crash. (CVE-2011-2519, Moderate)

   Unlike the example above, A:H in this case indicates a hypervisor crash.

4. CVE-2011-2901
   cvss2=5.5/AV:A/AC:L/Au:S/C:N/I:N/A:C
   CVSS:3.0=4.3/AV:A/AC:L/PR:H/UI:R/S:U/C:N/I:N/A:H

   An off-by-one flaw was found in the __addr_ok() macro in the Linux kernel's Xen hypervisor implementation when running on 64-bit systems. A privileged guest user could trigger this flaw to cause the hypervisor to crash. (CVE-2011-2901, Moderate)

   A:H in this example also indicates a hypervisor crash.

5. CVE-2010-0435
   cvss2=5.5/AV:A/AC:L/Au:S/C:N/I:N/A:C
   CVSS:3.0=4.3/AV:A/AC:L/PR:H/UI:R/S:U/C:N/I:N/A:H

   A NULL pointer dereference flaw was found when the host system had a processor with the Intel VT-x extension enabled. A privileged guest user could use this flaw to trick the host into emulating a certain instruction, which could crash the host (denial of service). (CVE-2010-0435, Moderate)

   In this case, by looking at just the base vector, it is not possible to determine whether A:H refers to the host or the guest. PR:H indicates that it has to be a local, privileged user, but it does not say whether the attacker is residing in the guest or the host. AV:A gives a hint that it is a guest/host issue in the virtualization environment.

The future direction?

In this short article, we have answered how and why we rate security flaws, and given numerous examples of how we rate real-life virtualization security flaws. We have shared our guidelines that we use to rate such flaws and apply them consistently. We hope that by sharing some insight to the current scoring system, our users will be able to interpret the scores and make informed decisions. We also hope that the guidelines can inspire improvements in the next version of CVSS in the near future.

Connect: