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?

  • 32
    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
    Commented Jun 23, 2012 at 6:42
  • 4
    A example of a real life attack from guest os to host os. venom.crowdstrike.com
    – Tim Jonas
    Commented Jun 25, 2015 at 23:13
  • A very generic statement is that the security of the host and network depends on the security of the interfaces between said host / network and the client VM. You should consider installing the absolute minimum of tools, configuring minimum network access and configuring minimum of hardware devices to minimize risk. If you just run a VM in a memory sandbox then you will likely be secure; the only interfaces to attack would be the CPU and memory subsystem of the visor. You would also have a pretty useless VM. E.g. do you need a floppy? Commented Sep 11, 2015 at 11:25

10 Answers 10


VMs 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 CPUs, 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 VMs is called the Separation Kernel. It's a result of John Rushby's 1981 paper which basically states that in order to have VMs isolated in a manner that could be equivalent to physical separation, the computer must export its resources to specific VMs in a way where at no point any resource that can store state is shared between VMs. 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 VMs, you'd need four harddrives hanging off four disk controllers, four video cards, four USB controllers with four mice, etc..

2020 update: all the recent hardware based vulnerabilities (Meltdown,Spectre,Foreshadow,ZombieLoad,CacheOut,SPOILER,etc) family of vulnerabilities are great examples of how VM's are always going to be able to communicate, simply because they share hardware (caches, TLB, branch prediction, TSX, SGX) that were never intended or prepared to be partitioned and isolated.

  • 11
    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? Commented Jan 8, 2014 at 16:35
  • 2
    @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
    Commented Apr 17, 2014 at 7:33
  • 2
    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
    Commented Apr 30, 2014 at 19:34
  • 18
    "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
    Commented Feb 6, 2015 at 2:40
  • 2
    There's no such thing as a totally "No sharing" system. Even if you have a dedicated network cards, hard drive, etc for each VM, you'll still be sharing the motherboard. And if your VMs actually have their own motherboards, well you can't really call your system VM anymore then.
    – Lie Ryan
    Commented Apr 30, 2018 at 23:53

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.

  • 3
    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
    Commented Jul 10, 2014 at 15:11
  • 5
    "This is a special software pathway for infection; don't install the tools, don't have the vulnerability." Even if the tools aren't installed the attacker could just install them. To properly close the attack vector you would need to close the APIs that the tools talk to. Commented Dec 21, 2016 at 18:15
  • @PeterGreen sorry for the late reply. But seems that those tools need to be configured at both guest and host sides to work--like shared folder or seamless copy. If this is the case, even if an attacker can install tools it should not be a big issue, right?..
    – user129187
    Commented May 24, 2021 at 5:44

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.


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

  • 2
    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
    Commented Apr 13, 2011 at 18:41
  • 2
    +1, but the recognized leader in these field, Joanna Rutkowska, can be found at theinvisiblethings.blogspot.com
    – AviD
    Commented Apr 13, 2011 at 18:55
  • 4
    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
    Commented Apr 14, 2011 at 13:40
  • 2
    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
    Commented Apr 21, 2011 at 18:01

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.


I think that author assertion is not completely true. Actually, there are two types of hypervisor in virtualization area. Hypervisor is a piece of computer software, firmware or hardware that creates and runs virtual machines. Those types are:

  • Type-1 hypervisors
  • Type-2 hypervisors

Type-1 hypervisor runs directly on the host's hardware to control the hardware and to manage guest operating systems. For this reason, they are sometimes called bare metal hypervisors whereas Type-2 hypervisor runs on a conventional operating system just as other computer programs do. VMWare or VirtualBox are example of Type-2 hypervisor because they are run as programs in host OSs.

For Type-2 hypervisors, there is RoboLinux project which has an unique feature called Stealth VM. Stealth VM software installer that allows you to build a Windows 7 clone running in a secure Linux partition. The system is protected from malware, anything you download will be contained within the virtual machine and it is intended for people who must have a specific Windows program with the convenience of being able to restore the operating system as new in just two clicks.

There is Qubes OS which is developed on Linux and Xen as an example for Type-1 hypervisors. Qubes OS takes an approach called security by isolation, which in this context means keeping the things you do on your computer securely isolated in different VMs so that one VM getting compromised won’t affect the others. Unlike Type-2 hypervisors, it has a secure inter-VM file transfer system to handle sharing folders' risk. In theory, that organization is more secure than Type-2 virtualization according to developers.

In short, the author should indicate which hypervisor or virtual system.


  • 1
    You mean Qubes is an example for Type-1 hypervisors, surely?
    – TNT
    Commented Mar 23, 2016 at 4:58
  • 1
    Yes(I should had clerical error; now I edited the post thx), also, you can find that information on their website. "By contrast, Qubes uses a “Type 1” or “bare metal” hypervisor called Xen. Instead of running inside an OS, Type 1 hypervisors run directly on the “bare metal” of the hardware. This means that an attacker must be capable of subverting the hypervisor itself in order to compromise the entire system, which is vastly more difficult." from qubes-os.org/tour/#what-is-qubes-os Commented Mar 24, 2016 at 19:24

They aren't perfectly secure, as demonstrated with this exploit:

VENOM, CVE-2015-3456, is a security vulnerability that impacts some common computer virtualization platforms, notably Xen, KVM, VirtualBox, and the native QEMU client.

This vulnerability may allow an attacker to escape from the confines of an affected virtual machine (VM) guest and potentially obtain code-execution access to the host. More details regarding the vulnerability can be found here.

  • 1
    Note that CVE-2015-3456 is mitigated by using QEMU's chroot option, assuming it is not running as root. All that vulnerability does is compromise the userspace QEMU frontend, not the kernelspace Xen/KVM backend. Also, I don't think it affects VirtualBox, like at all. It is specifically a vulnerability in QEMU's fdc driver. VirtualBox does not share that code. The only reason it is said to affect KVM and Xen is because those two are rarely used on their own, and instead act as backends for QEMU. Something like kvmtool rather than QEMU, despite still using KVM, would not be affected.
    – forest
    Commented Dec 22, 2017 at 2:25

Of interest and relevance , the "Pwn2Own" security contest for 2016 has as one of its competitions, escaping from a VMWare Workstation virtual machine. (Others include escaping browser sandboxes or taking over physical machines). That should give an idea that 1) its at least plausible and 2) if its easy then we have a way to hear it - just check the outcome :)

More generally VM security could in theory be escaped in many ways. For example -

  • Guest to host commands and APIs (eg VMware tools)

  • Exploitable weaknesses in the host OS itself which are not mitigated by running in a VM process (if some guest OS calls are erroneously judged "safe" and passed direct by a guest driver to the host OS or device driver for speed, but an exploit exists)

  • Bugs in vendor drivers or vendor code (for example, a host driver allows network bridging for the guest OS; perhaps a bug in it might allow calls or code to be made on the host at kernel level).

  • Vulnerabilities resulting from other software on the host (contrived example - if local antivirus intercepts all network traffic from the host to scan, and guest traffic is scanned as part of that (as opposed to being ignored due to virtual NIC device), then a vulnerability of the a/v engine to a malicious crafted traffic or packet could be capable of allowing traffic originating from the VM to escape to the host)

  • Bad config by user (host files mapped or insufficiently secure/separated so the guest can reach them)

The scope exists, and given prevalence its surely being examined actively for exploits. Surely vulnerabilities if not exploits will regularly be found and need patching.

  1. Physical isolation will always be more robust than using logical isolation. In physically-isolated systems (servers, etc.), a security issue in one physically-isolated system will not become an issue in another through shared hypervisor or HW. Of course, the network is another vector that needs to be addressed.

  2. For all intents and purposes, VMs/Hypervisors (see notes later) could provide adequate isolation between the VM. That is also an underlying premise in using Cloud Service Providers (CSPs) where multi-tenant systems share the same HW, using not only virtualized servers, but also virtual networks and storage. There are certain hypervisor-based systems have been approved for providing isolation between systems of different classification levels on the same platform (https://en.wikipedia.org/wiki/NetTop).

  3. The distinction between Type 1 (bare metal) and Type 2 hypervisors is an important one. Type 2 hypervisors will not be any more secure than the underlying Host OS. They also don't typically have the same control over the HW as Type 1 hypervisors do.

  4. Hypervisor security capabilities and assurance in their correct operation: Different hypervisors make different claims in terms of VM isolation and control over VM to physical HW resources. For instance, ESXi claims "VM domain isolation" and it has been independently evaluated for this and other security requirements through the Common Criteria (CC) process. If you use a hypervisor that has not been independently validated, you're taking the vendor's word that its does what they claim it does and does it correctly.

  5. All complex SW can be misconfigured, exposing vulnerabilities. It is important to configure hypervisor using CIS Benchmarks, Vendor Guidance or DISA STIGs to remove known configuration vulnerabilities.

  6. All SW may have security bugs (implementation vulnerabilities), so it is also important to have a vulnerability management program to quickly identify and patch such.

In summary:

  1. Use Type 1 hypervisors that are CC-certified.
  2. Securely configure per security configuration guidance.
  3. Have a security vulnerability management program in place.
  4. Have a comprehensive security architecture in place (Network and Host IDS), AV, security monitoring, boundary controls, etc.
  5. For any centralized virtualization infr. management, such as WMware vCenter, ensure that the manager platform, the manager and the manager to the managed hypervisor instance interfaces are secured. For instance: the vCenter is deployed on a secure, hardened server, with strong admin. authentication and access control. The platform is protected at the host (AV/HIDS), network level (FWs, NIDS/NIPS) and security monitoring is in place (e.g., SIEM). Interfaces use proper data-in-transit (DIT) encryption, mutual authentication and proper Key Management (KM).
  6. Do recognize that virtual isolation does introduce an additional risk relative to physical isolation. But should be manageable if the above areas are addressed.

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .