The folks using virtualization to contain server instances for security purposes are assuming that VM isolation is just as robust as separation of physical servers. That’s a "goats on the moon" assumption… which is odd because not even the vendors are making that claim (read the TOE of the ESX server common criteria evaluation).

Are exploits against virtual machines likely? Of course. All software has bugs, especially complex software like virtualization products. Do I know of exploits specifically for ESX server? Not at the moment, but then I’m not connected to any of the underground black markets where such exploits are most likely to show up first.

Vmware says that the kernel hosting the VM guest is purely VMware. The implication is that any Linux vulnerabilities in the Service Console would not be reachable by the guest OSs.

Thanks for the comment. You’re right that a virtual machine can be “safe” for a particular purpose. Anything can be acceptable as long as you understand the issues and accept the risk. Using virtual machines all within the same security domain (to emulate all the servers housed within one DMZ, for example), isn’t much riskier than physical hardware since the assumption of a DMZ is always that the machines within it can attack each other. Spanning security domains is higher risk, since much less is known about vulnerabilities in these entirely software-based emulations than is known about physical hardware like a firewall appliance.

The point of the article is that people are assuming virtual machines are *identical* security-wise to physical machines, and that the emulated VLANs provided by products like vmware are *identical* to physical LANs or hardware VLANs. They’re not.. and shouldn’t blindly be used as drop-in substitutions for physical hardware.

Regarding VLANs, in the article I was talking about the emulated VLANs implemented within VMWare. These are software simulations of physical LANs, just like the NICs in each guest OS is a software emulation of a physical network card. I don’t think VMWare VLANs use 802.1q internally… but that’s something to look into. The point is that there are ways to escape VLANs when implemented in hardware… assuming that simulated LANS implemented entirely in software are just as strong is a mistake IMHO.

By the way, take at look at the “aims and benefits” section in the original IEEE 802.1Q spec at http://standards.ieee.org/getieee802/download/802.1Q-1998.pdf. Physical VLANs were originally designed to limit ethernet collision domains and to allow physically separate hosts to be placed logically on the same LAN. As far as I can see, security wasn’t a specific design goal. Doesn’t mean VLANs can never be used to provide traffic separation for security purposes… it depends on what you’re protecting and the level risk you’re willing to accept.

Having said that, you cannot “hop VLAN’s” on a network that doesn’t use the Native VLAN, or use Cisco’s propriatary ISL instead of IEEE 802.1q to communicate between switches. Because “Native VLAN” exists on a 802.1q link only.

In my opinion, a virtual machine can be as “save” as you need it to be. You just need to understand the technique very well.