Home > Blogs > VMware Security & Compliance Blog > Monthly Archives: October 2009

Monthly Archives: October 2009

The Common Vulnerability Scoring System and VMware network isolation

The Common Vulnerability Scoring System (CVSS) is an standard for assessing the severity of computer system security vulnerabilities. CVSS is composed of three metric groups: Base, Temporal, and Environmental, each consisting of a set of metrics. For those not familiar with CVSS, here is a blog post Common Vulnerability Scoring System (CVSS) Explained.

  1. Base: represents the intrinsic and fundamental characteristics of a vulnerability that are constant over time and user environments.
  2. Temporal: represents the characteristics of a vulnerability that change over time but not among user environments.
  3. Environmental: represents the characteristics of a vulnerability that are relevant and unique to a particular user's environment.

A software vendor can typically fill out the base metrics score because things are supposed to be constant. But it turns out that VMware products break the definition of a CVSS base score.
A base metric is comprised of the following:

  • Access Vector (AV)
  • Access Complexity (AC)
  • Authentication (Au)
  • Confidentiality Impact (C)
  • Integrity Impact (I)
  • Availability Impact (A)

Now consider only the Access Vector (AV) metric. Here is the definition:

Metric Value Description
Local (L) A vulnerability exploitable with only local access requires the attacker to have either physical access to the vulnerable system or a local (shell) account. Examples of locally exploitable vulnerabilities are peripheral attacks such as Firewire/USB DMA attacks, and local privilege escalations (e.g., sudo).
Adjacent Network (A) A vulnerability exploitable with adjacent network access requires the attacker to have access to either the broadcast or collision domain of the vulnerable software. Examples of local networks include local IP subnet, Bluetooth, IEEE 802.11, and local Ethernet segment.
Network (N) A vulnerability exploitable with network access means the vulnerable software is bound to the network stack and the attacker does not require local network access or local access. Such a vulnerability is often termed "remotely exploitable". An example of a network attack is an RPC buffer overflow.

In this blog post I intend to show with VMware products the CVSS Access Vector (AV) can be different depending on how virtual networking is setup, and is thus affected by the user environment. Perhaps CVSS should consider moving the Access Vector metric from the Base metric set to Environmental metric set. I will show why it is so important to isolate your management network, because when using VMware's best practices the CVSS base score of many vulnerabilities will be reduced.

Consider the following scenarios.

In the following scenarios we'll take a look at an ESX system with several virtual machines. The virtual machines are connected to the Internet.

Scenario 1

Badbadbad

This is where both the ESX Service Console (or the ESXi management network) and the virtual machine network are both on the same vSwitch which connects them to the Internet. Note this is NOT recommended!
Most Operating Systems don't have virtual switches or layer 2 network isolation, and so they would fall under Scenario 1 where all networking is exposed to the Internet. This Leaves the CVSS Access Vector value to be Network.

Scenario 2

Good

Here the management network is on a different vSwitch and on a totally different network then the virtual machines which are connected to the Internet. There is NO direct route from the Internet to the management interface, nor to the ESX Service Console. This is VMware's recommendation for platform security best practices and it provides an additional layer of protection. In this scenario using the CVSS definitions, the management network is on a local IP subnet or Adjacent Network, and the virtual machine port group is on the Internet or CVSS defined "Network."

Vulnerabilities

Now consider a vulnerability in the ESX Service Console. Let's take CVE-2008-4309, "a denial-of-service flaw was found in the way net-SNMP processes SNMP GETBULK requests. A remote attacker who issued a specially-crafted request could cause the snmpd server to crash."

The National Vulnerability Database rates this CVE as:

CVSS v2 Base Score:
5.0 (MEDIUM) (AV:N/AC:L/Au:N/C:N/I:N/A:P)

But this also assumes the Access Vector is Network (AV:N). If you are following VMware's best practices, then your management network is isolated. There is no way an attacker from the Internet/Network can get to the management network stack, even if there is a flaw in the management network stack, thus the only Access Vector is through the Adjacent Network (AV:A). This adjustment in the Access Vector to (AV:A) from (AV:N) changes the CVSS score to:

CVSS v2 Base Score:3.3 (LOW) (AV:A/AC:L/Au:N/C:N/I:N/A:P)

This is just one example where a base metric Access Vector doesn't meet the CVSS criteria of "the characteristics of a vulnerability that are constant with time and across user environments" because of virtualization. While looking at CVSS we noticed a few other interesting conditions that need to be considered because of virtualization. But we'll leave that to another post.

All ESX Service Console vulnerabilities and ESXi management service vulnerabilities can also be modified when using VMware security best practices as shown above. The Access Vector is no longer just Network (AV:N), but it becomes Adjacent Network (AV:A) when using multiple virtual switches

So when evaluating security risk using CVSS consider how you have deployed your machines, consider how the networking is setup and if you are following VMware's best practices you may be able to lower your CVSS score to better reflect your risk. If you NOT following VMware's best practices, perhaps it is time to re-evaluate your security setup and consider isolating your management network.