Preventing VMware virtual machine errors and security breaches

Edward L. Haletky, Contributor

Just because you've secured your operating systems running on a VMware ESX or VMware ESXi hypervisor doesn't mean you've secured virtual machines (VMs) against all errors and vulnerabilities. VMware administrators also need to consider the more abstract virtualization "layer" where a virtual machine and a hypervisor interact.

In this case, we'll discuss a virtualization layer made up of paravirtualized drivers, normal drivers and the VMware backdoor that

    Requires Free Membership to View

    Login

VMware Tools uses to execute commands. Wherever there is an interaction layer, hackers will develop and research security exploits. In this tip, we'll discuss how to regulate driver interactions and how to prevent security risks that can arise with the VMware backdoor.

Interaction between the hypervisor and the virtual machine
Although paravirtualized drivers, normal drivers and VMware Tools pose different kinds of threats, each entity should be tweaked to lessen the chance of a security breach.

Hardening the guest OS

Here are some useful reference links on hardening guest operating systems:

Apply one or all of these benchmarks or guides to your virtual machines. Remember that the vSwitch does not contain a built-in firewall so once the guest OS is connected to a network it must protect itself.

Paravirtualized drivers. Paravirtualized drivers know they run within a virtual machine and either use out-of-band communication with devices (perhaps through the VMware backdoor, an I/O port that is specific to VMware virtual machines) or take advantage of this to use code specific to the virtualization host in use. Within a VMware guest, for example, the vmxnet driver is paravirtualized. The driver gains performance advantages because of this knowledge. VMware's proposed Virtual Machine Interface (VMI) will make writing paravirtualized drivers for Linux much easier and nearly transparent.

In the meantime, however, poorly written paravirtualized drivers can cause crashes that could be an attempt to escape the VM into the hypervisor. While this is not currently possible, it is best to vet all paravirtualized drivers before putting them in use. In essence use paravirtualized drivers from only known sources (i.e., VMware).

Normal drivers. Normal drivers do not know they run on a hypervisor and often require a hypervisor's translation to the underlying hardware in use. These drivers interact with the guest OS kernel only and the guest OS kernel interacts with the hypervisor through normal means. In some cases, the hypervisor does not know about the command issued by the driver (or to the driver) and will show errors within the per-VM vmware.log to this effect. Functionality suffers, but this may not be noticeable to the VM. In other cases it could cause the VM to crash. For example, the vmkernel, VMware's hypervisor, did not implement every SCSI instruction or command available. Some of the esoteric commands can cause errors to appear within the vmware.log file. In odd cases, the VM would panic.

The VMware backdoor.The VMware backdoor can leak version data ,which can contribute to other attacks. The backdoor gives an alternative path to the hypervisor and is used to provide out-of-band communication between the VM and the hypervisor. The VMware backdoor is mainly used by VMware Tools. If you create some simple settings within a VM, however, it protects the backdoor.

VMware Tools can run as any user, and therefore any user can issue many of the VMware Tools commands that run through the VMware backdoor. The average user does not need access to VMware Tools to execute commands, so VMware Tools access should be restricted to administrators within the guest. Unfortunately, the VMware backdoor is available to anyone and cannot be closed off from within all guest OSes at this time.

Securing the VMware backdoor
The chief way to secure the VMware backdoor is to disable functionality with VMware's advanced configuration settings. Each of the current security standards suggests subsets of all the different isolation options to set and none of them agree on the minimal set required, which is actually all the ones listed. Here is how to change a VM's settings, which you can find under Advanced Options (or added directly into each VM's .vmx file.).

DISA STIG for ESX

  • Disable copy from remote console of a VM to the workstation:
    isolation.tools.copy.enable => false

     

  • Disable paste from workstation into remote console of VM:
    isolation.tools.paste.enable => false

     

  • Disable changing screen resolution and depth:
    isolation.tools.setguioptions.enable => false

CISecurity ESX Benchmark

  • Disable copy from remote console of a VM to the workstation:
    isolation.tools.copy.enable => false

     

  • Disable paste from workstation into remote console of VM:
    isolation.tools.paste.enable => false

     

  • Disable changing screen resolution and depth:
    isolation.tools.setguioptions.enable => false

     

  • Disable the ability for the VMware Tools to make some configuration changes
    isolation.tools.setinfo.disable => true

VMware VI3.5 hardening guidelines

 

  • Disable some aspects of logging during the life of the VM to vmware.log. This greatly reduces logging but does not entirely remove it. This could help with disk I/O issues.
    isolation.tools.log.disable => true

     

  • Rotate the vmware.log every specified bytes, else the vmware.log file can grow very large
    log.rotatesize => 100000

     

  • Keep only the specified number of historical vmware.log files, else an infinite number will be kept, which can take up quite a bit of disk space. On a VMFS it can quickly reach the 32 K file limit.
    log.keepold => 10

     

  • Limit how much data can be sent to the VMware Back door.
    tools.setinfo.sizeLimit => 1048576

     

  • Disable the ability to set some of the information from within the VM about the VM through the VMware backdoor
    isolation.tools.setInfo.disable => true

     

  • Disable the ability for the VM to set the connection state through the VMware backdoor of those aspects of the virtual hardware that can be connected and disconnected (floppy, CD-ROM, network, etc.)
    isolation.tools.connectable.disable => true
    isolation.tools.diskshrink.disable => true

     

  • Disable the ability of the VM to call diskwiper routines through the VMware backdoor.
    isolation.tools.diskwiper.disable => true

Preventative measures
Depending on security requirements, all these options should be set because they secure interactions between guests and VMware remote console hosts as well as between the virtual machine, the hypervisor and the file system. These settings can prevent interesting (and confusing) hypervisor errors created by a lack of space.

Protecting the VMware backdoor is very important, so I've emphasized it here. It is best to limit access to the tools, but not the drivers, as appropriate. Also, the implementation of mandatory access controls such as Window's User Access Control (UAC) and SELinux within the guest OS can limit who and what can access the VMware backdoor.

Security of the VM is mostly within the guest OS, but virtual hardware settings can make a large difference as well. Make a practice of reading the current hardening guidelines, benchmarks and checklists to aid in properly securing your virtual machines.

ABOUT THE AUTHOR: Edward L. Haletky is the author of VMware ESX Server in the Enterprise: Planning and Securing Virtualization Servers. He recently left Hewlett-Packard, where he worked on the virtualization, Linux and High-Performance Computing teams. Haletky owns AstroArch Consulting, Inc. and is a champion and moderator for the VMware Communities Forums.

This was first published in January 2009

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.

    Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.

    Back to top