How secure are virtual machines really? False sense of security?

Question

I was reading this CompTIA Security+ SYO-201 book, and the author Prowse claims that

Whichever VM you select, the VM cannot cross the software boundaries set in place. For example, a virus might infect a computer when executed and spread to other files in the OS. However, a virus executed in a VM will spread through the VM but not affect the underlying actual OS.

So if I'm running VMWare player and execute some malware on my virtual machine's OS, I don't have to worry about my host system being compromised, at all? What if the virtual machine shares the network with the host machine, and shared folders are enabled? Isn't it still possible for a worm to copy itself to the host machine that way? Isn't the user still vulnerable to AutoRun if the OS is Windows and they insert a USB storage device?

How secure are virtual machines, really? How much do they protect the host machine from malware and attacks?

Answer 1

VM's can definitely cross over. Usually you have them networked, so any malware with a network component (i.e. worms) will propagate to wherever their addressing/routing allows them to. Regular viruses tend to only operate in usermode, so while they couldn't communicate overtly, they could still set up a covert channel. If you are sharing CPU's, a busy process on one VM can effectively communicate state to another VM (that's your prototypical timing covert channel). Storage covert channel would be a bit harder as the virtual disks tend to have a hard limit on them, so unless you have a system that can over-commit disk space, it should not be an issue.

The most interesting approach to securing VM's is called the Separation Kernel. It's a result of John Rushby's 1981 paper which basically states that in order to have VM's isolated in a manner that could be equivalent to physical separation, the computer must export its resources to specific VM's in a way where at no point any resource that can store state is shared between VM's. This has deep consequences, as it requires the underlying computer architecture to be designed in a way in which this can be carried out in a non-bypassable manner.

30yrs after this paper, we finally have few products that claim to do it. x86 isn't the greatest platform for it, as there are many instructions that cannot be virtualized, to fully support the 'no sharing' idea. It is also not very practical for common systems, as to have four VM's, you'd need four harddrives hanging off four disk controllers, four video cards, four USB controllers with four mice, etc..

Answer 2

There have been some white-papers published over the years describing ways that researchers have managed to infest a host OS from a VM. These are usually seen, rightly so, as security vulnerabilities by the VM vendors and treated as such. Since I first saw those papers, Intel has made some significant processor instruction-set improvements in allowing separation of VM and hypervisor.

The few vulnerabilities I see these days are based more in the 'vmtools' portion. This is the software you install to make the guest OS run more efficiently (for VMWare this is what allows on the fly cursor capture, and sharing between guest and host without a network). This is a special software pathway for infection; don't install the tools, don't have the vulnerability.

Some malware has show the ability to detect that they're being executed inside a VM and thus change their behavior, much to the aggravation of malware researchers attempting to use VMs as a way to test malware. I don't know how prevalent it is these days, though.

Answer 3

An example of guest-to-host code execution can be found in the Cloudburst exploit. There is a video demonstrating it and a paper from Immunity detailing their success on VMware Workstation 6.5.0 build­118166 on a Windows Vista SP1, VMware Workstation 6.5.1 build­126130 on a Windows Vista SP1, and (even more scary) VMware ESX Server 4.0.0 build­133495.

This probably provides little comfort, but I've never heard of this being used in the wild and the exploit is from 2009. That book was published in 2010 so the author should clean that statement up.

Answer 4

A virtual machine is exactly that, a logically separate machine, so it must have the same security layers placed on it as you would a bare-metal system. Using a virtual machine will not stop a vul if it uses normal channels to get to the host machine.

The real beauty in virtualization is the ability to roll back VMs to a state where they were not effected, as well as the ability to better manage available resources.

If the proper steps are taken to protect the host machine, virtualization can be extremely secure. Practices like keeping ESX/VM server management on a different logical network and not using VM-host interfacing tools will keep attackers mostly oblivious to the fact that a machine is virtual, let alone how to get to the host.

Also, there are known exploits that effects VM hosts (I've played with them in VMWare and Hyper-V). I'm only currently aware of host DoS exploits when it comes to hyper-v (see this), but I'm sure there are other finds in the horizon. VMWare has some in it's history too (i.e. this, it's VMWare tools based, but it still applies).

Depending on what you're doing, there are some online tools that may be able to take away your need to do the analysis on your own machine. Here are a few sites to take a look at:
- Threatexpert.com
- anubis.iseclab.org
- virustotal.com

Answer 5

What is meant by the Security+ material is that thus far malware hasn't been able to escape the sandbox of the VM via exploiting the fact that it's a VM and somehow hitting the hypervisor. Other mechanisms, such as spreading across a shared network, are the same as if these were different physical boxes.

Answer 6

I agree with Ormis above - it's a "machine" that needs to be accounted for on your network. They aren't any more secure than a standard host machine. There are a few companies that sell softare to check the specific issues that software like VMware brings; not only the standard OS flaws, but also the virtual server or app config issues that attackers could use to attack.

I suggest looking at something like Retina Community from eEye - it's a free security tool for physical and virtual systems - it scans them for missing patches and config issues. The product comes with an add on to scan virtual apps deployed via ThinApp as well, which is pretty unique in the industry.