Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I was reading this CompTIA Security+ SYO-201 book, and the author David 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?

share|improve this question

migrated from serverfault.com Apr 13 '11 at 0:02

This question came from our site for system and network administrators.

Possible duplicate of security.stackexchange.com/questions/2816/… ? –  AviD Apr 13 '11 at 7:08
If I were the editor, I would interject a "hopefully" and "theoretically" in a few choice locations in that quote. As is, it's definitely a false statement. –  tylerl Jun 23 '12 at 6:42

7 Answers 7

up vote 45 down vote accepted

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..

share|improve this answer
What would be the benefit of this sort of covert communication for the virus author? It sounds like it couldn't be used until both machines were infected, but why would you need it after that point? –  Jack O'Connor Jan 8 '14 at 16:35
@JackO'Connor: In order to communicate between them. Consider for instance if one of the VMs has a network card attached to the Internet but not the internal Data Center, and the other has a network card attached to the internal Data Center but not to the Internet. Using this covert channel, the attacker now has a route to attack the DC from the Internet and exfil data. Additionally, one VM could possibly side-channel attack another VM using this method, for instance one compromised VM (on Azure/EC2 maybe) attacking another VM to get the other VM's SSL private keys, for instance. –  Matt Apr 17 '14 at 7:33
If a VM doesn't actually execute machine code directly, but instead interprets it, should there be any fundamental difficulty in making the machine 100% secure if the only ways it can interact with the outside world are initiated from outside itself (e.g. an outside utility which copies data to the virtual machine's "hard drive"?) –  supercat Apr 30 '14 at 19:34
"to have four VM's, you'd need four harddrives hanging off four disk controllers, four [etc...]" That sounds like it's missing the point of virtual machines. –  Hugh Allen Feb 6 at 2:40

Exploits that are specifically designed to run in vms and target bugs in the underlying host kernel are inevitable. Look for them first in the popular cloud platforms.

share|improve this answer

It would be possible exploit a virtual machine and execute code outside of the virtual machine. For example if the intruder managed to exploit a usb mouse driver implemented by vmware it would be possible. An very basic example of this would be make a program that sets the mouse position to 12345678. If the vmware mouse fuction only has a buffer space of 5 integers then this would cause a buffer overflow. If the buffer space where long enough which I would imagine it would be you could run a pretty deadly shellcode and take full control of the host operating system. Funny if someone looks into this and actually develops and exploit using this method $$$.

share|improve this answer

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

share|improve this answer
P.S. check out malwaredomainlist.com if you want to test out your sandbox environment... but be cautioned, only use this if you want to be infected with some new, fun, malware :-) –  Ormis Apr 13 '11 at 18:41
+1, but the recognized leader in these field, Joanna Rutkowska, can be found at theinvisiblethings.blogspot.com –  AviD Apr 13 '11 at 18:55
A VM on x86 is NOT an exact logically separate machine. Read en.wikipedia.org/wiki/… and usenix.org/events/sec2000/robin.html and you'll find out there are 17 instructions that cannot be virtualized. –  Marcin Apr 14 '11 at 13:40
Logically separate does not mean technically separate. Even if all instructions cannot be virtualized, the application of the machine is still a different logical entity. Those who deploy them need to keep this mindset, don't assume security because of abstraction. Also, remember to do the basics... for VMWare, try to use a different host OS than Guest OS that you're testing, look over the isolation options, and make sure the networks are properly constructed. So, @Marcin i understand what you're trying to say, but i believe my comments are still valid (simply that virtualization != security). –  Ormis Apr 21 '11 at 18:01

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.

share|improve this answer

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.

share|improve this answer
I've heard that they usually run the malware in the debugger, set a breakpoint for the branch that causes VM-specific behavior, and change the result of that condition after it's evaluated. But it's less prevalent nowadays because many interesting targets are virtualized. –  Kevin Chen Jul 10 '14 at 15:11

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.

share|improve this answer
Unfortunately, your answer is factually incorrect. I'm not certain it was known in 2011, but it definitely is now. vupen.com/blog/… via insinuator.net/2013/05/analysis-of-hypervisor-breakouts –  ajm475du Dec 15 '14 at 13:03

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.