EXPERT RESPONSE
At best, virtual machines make a guest system have the same security footprint as a real system. That is, virtualization doesn't add any additional protection to software running on a guest machine. If a given piece of software is exploitable in a real operating system, it will also be exploitable in a VM. That's because the goal of virtualization technologies is to make a virtual machine behave just like a real one. Thus, you have to harden and patch your guest machines just as you would a real operating system.
Now, virtualization can be used to try to achieve some isolation -- that is, to take a given piece of software and make it run on a guest machine to separate it out from other functions on the host or on a different guest. Proceed with caution though, as a clever attacker may be able to compromise the isolation that virtual machines provide. It's not trivial, but it is possible. If the attacker is able to get code to run on the host and on the guest, he or she can create virtual tunnels that plow through virtualization. My team has created a small tool called VMcat, which creates its own communications channel to tunnel data between guests and host. Now, VMcat requires that the attacker install and run something on both the guest and the host, so it is not a pure-play escape. A true escape would allow an attacker on a guest to start running software directly on the host, popping out of the isolation of the guest.
While no true escape software has been released publicly as of this writing, there has been some interesting movement in this arena recently. In July 2007, my team demonstrated how an unpatched VMware Workstation system can be undermined with an escape. In an unrelated development, in August 2007, Microsoft released MS07-049, a patch for a vulnerability in its Virtual Server and Virtual PC products that, according to Microsoft, "could allow a guest operating system user to run code on the host or another guest operating system." That's a textbook definition of virtual machine escape. Again, as of this writing, there is no public exploit for either the VMware or Microsoft issue.
What should you do about these concerns? Keep your virtualization products patched. VMware releases patches on a regular basis, as does Microsoft. Make sure you apply them. Also, harden both your guest and host machines to minimize the chance of an attacker compromising either side of the virtual divide. And, finally, carefully architect your virtual machine deployments to minimize the damage that an escape could cause. Separate weak machines -- those without important data -- from the strong ones that hold valuable information, and do so using different underlying hosts. Don't treat your virtual machine like a firewall. Use a real firewall instead.
More information
Will allowing virtual machines in the enterprise increase risk exposure? Ed Skoudis continues his virtualization explanation.
Be prepared for virtualization security unknowns.
|
