In the grand scheme of things -think the matrix- the question might not be "to be or not to be", but instead evolve to "to be real or not to be real"

Let's look at the evolutions:

• Malware researchers (as in reverse engineering) tend to use products like VMware to allow them to run malware in a more controlled environment where they also can undo having run it easier (on a to be discarded copy of the image)
• Malware authors more often than not detect VMware and have their malware not give away what it would do on a real machine
• Joanna Rutkowska "Blue Pill" research most likely deserves a mention in here just as well.
• Last month Microsoft fixed in MS07-049 a thread they classified as important that allowed a break out of the virtual OS to the host OS. We had some disagreement on that rating with Microsoft as we saw it as a significant bigger deal than "just" privilege escalation.
• This week VMware released updates that fix a number of vulnerabilities. They've announced the details on a mailing list, but on their own website all seems to be much more rainbows and butterflies unless you dig through some of the release notes (search for "security"): E.g. (there is one for every product):
  • http://www.vmware.com/support/ws6/doc/releasenotes_ws6.html
  • http://www.vmware.com/support/server/doc/releasenotes_server.html
  Now what does this mean in terms of impact ?
  It fixes quite a few vulnerabilities:
  

  CVE-2007-2446 CVE-2007-2447 CVE-2007-0494 CVE-2007-2442 CVE-2007-2443 CVE-2007-2798 CVE-2007-0061 CVE-2007-0062 CVE-2007-0063 CVE-2007-4059 CVE-2007-4155 CVE-2007-4496 CVE-2007-4497 CVE-2007-1856 CVE-2006-1174 CVE-2006-4600 CVE-2004-0813 CVE-2007-1716 CVE-2006-3619 CVE-2006-4146

  Some of these are fixes propagating from DHCP, cron, samba etc, nothing special as such except that they've been around for a while now -with fully documenting source code patches-.
  The more spectacular vulnerabilities are:
  • CVE-2007-4496 A privileged user in a guest OS can execute arbitrary code on the host OS
  • CVE-2007-4497 A user on the guest OS can cause a DoS not just on the host OS (and on the guest OS)
• There is also a paper by Google that studied some aspects for multiple vendors in the virtualization world: http://taviso.decsystem.org/virtsec.pdf While two product names are obscured they'll be easy enough to guess for those knowing the platforms they are used on. Ever since Apple moved to Intel CPUs Parallels has been popular on that platform (I use it myself), and we already mentioned Virtual PC from Microsoft above.

Now with all that, how do we react ?

It all depends what you use it for. E.g. I use parallels on my Mac to be able to run windows applications on my mac when (and if) I need it. When teaching about security I run a virtual machine that has known vulnerabilities to demo how easy it is for real attackers to attack a system and how little skill it requires to execute a program that gives you a command prompt on a target.  If that is what you run a virtualization suite for, you're not more or less at risk than you were before.

If I'm a malware researcher, I'd be extra careful not to trust the malware to break out of the virtual machine, they already detect it, what could be more delaying in the analysis of their contraption than to zap the host OS ?

If I were to feel my host OS was immune to attack (fanboys to /dev/null please) due to the more targeted OS being in a virtual machine I might be in for a rude awakening down the line as those attacks might start to build in things to break out of their segregated environment. Having that false sense of security is a really bad thing.

If I buy less separated machines but instead buy more redundant hardware that's more powerful and run machines together on a shared hardware platform, I'd watch carefully what I'm putting together. It would be a bad idea to put e.g. the firewall, an IDS probe outside of the perimeter and the web server and database server all on one shared platform as if one if broken, all can be broken without going through the layers separated hardware would have provided. Even if all the hosts are from a same security layer there's increased risk as the machines can talk among themselves without passing through the network layer but that's probably easier to mitigate. So it does depend on your architecture and what you mix together.

If I'm a organization that has air-gapped networks that carry differently classified data on, it would be a very risky move to migrate those two hosts on those who need access to both networks onto a virtual machine setup. Better invest in that KVM switch if you need the real estate on those desks.

--
Swa Frantzen -- NET2S