Virtualization Security Is Taking Longer Than Expected

A few years ago I wrote a paper for SANS titled “Security Implications of the Virtualized Data Center.” I had been working in system and network security for almost 10 years and, like many IT professionals, had been relying on virtualization as a system tool for many years. While using virtualization as a sandbox for security research I was drawn to virtualization security, now called virtsec, once I realized how great the security threat was in x86 virtual computing environments.

The original intent for that paper was to serve as the first in a series that dug into all facets of virtsec. Starting with the basic threat analysis of moving systems from hardware to software, that paper dealt with security risks like attacking the host platform, attacking individual guests, and using a shared filesystem. These attacks were all examples of exploiting the nature of running virtual machines in a shared environment with shared resources on the virtual platform; they specifically did not delve into security of the hypervisor.

We’re still working on bringing virtual platform security up to the strict level of physical security, a level that’s been well understood and in place for many, many years. Virtual platform security isn’t that different than securing standard data center systems, it’s just an extra layer in security planning and monitoring. Where virtual systems differ, however, is in visibility: there are certain virtualized components that can’t be monitored or secured in the same manner as their physical counterparts. Virtual networking is the classic example of such hidden components. Unlike physical switches, there’s no easy way to place a tap on a virtual software switch port, for example, and trust that the mirrored data you’re monitoring is legitimate. This concept holds true for any virtualized hardware including RAM (News - Alert), bus, and CPUs.

The type of hypervisor also makes a difference for virtual platform security. Hypervisors are typically lumped into two generically-named categories. Type 1 hypervisors (also known as bare-metal hypervisors) run directly on the hardware providing native access to hardware resources for virtual machines. Type 1 hypervisors can be thought of as special-purpose operating systems because they control all access to the hardware resources. Examples of type 1 hypervisors include VMware ESX and ESXi, Microsoft (News - Alert) Hyper-V, and Citrix XenServer. Basically, all major data center-class hypervisors today are type 1 hypervisors. The extent to how stripped down or embedded these hypervisors are varies drastically between implementation. VMware ESX, for example, uses a full – albeit highly modified – Linux kernel and running space to support the hypervisor environment. Due to its larger environment, ESX requires additional levels of security focused on the operating system itself. Any “stock” OS components deployed by a type 1 hypervisor increase the attack surface of that hypervisor. If SSH is enabled on an ESX host, then that host (and its running virtual machines) are susceptible to SSH-based attacks just like a physical host running SSH.

Type 2 hypervisors, in contrast, run as applications within another operating system. Examples of type 2 hypervisors include VMware Workstation and Server and Microsoft Virtual Server. Since type 2 hypervisors are applications rather than operating systems they don’t manage direct access to hardware. Some security experts feel that no direct access to hardware provides an added level of security, while others believe that these systems are less secure since they’re susceptible to both traditional application attacks, such as buffer overflows, as well as having to rely on the security of the underlying operating system while managing virtual machine resources.

Regardless of the type of hypervisor, securing the running environment and virtual peripherals are still the most critical parts of virtual security. An excellent example of the work being done by the virtual security community is a document recently released by CIS, the Center for Internet Security, titled “Security Configuration Benchmark for VMware ESX 3.5.” This guide highlights the steps necessary to lock-down the ESX 3.5 hypervisor environment. These guidelines are no different than those required for physical systems – secure access and logging, tight user permissions, access to hardware resources by running applications and guest virtual machines, etc – yet they’re framed in a way that’s applicable to virtual platforms.

Once we get past that first critical step of securing the virtual platform running environment, then we can start looking into more sophisticated attacks: guest escaping, manipulating virtual machine state during a live migration, attacking virtual CPU cores, etc.

For as far as we’ve come with virtualization in the data center, the lack of advanced attacks focused at the hypervisor level is a bit surprising. I still look back on my original outline for that series of papers on virtsec and wait…wait for the time when writing about guest escaping attacks and malicious virtual CPU payloads is something that someone wants, or rather needs, to read about. IT

Alan Murphy is technical marketing manager of management and virtualization solutions with F5 Networks (News - Alert) (www.f5.com).

» Internet Telephony Magazine Table of Contents