Virtualization and security
- 29 November, 2006 10:51
It's a pity that discussions on the subject of security vulnerabilities associated with virtual servers tend to focus on Windows: If a virtual machine is running as a guest on a Windows host, an exploit on the guest VM can climb up to the Windows host, and then all hell can break loose. There's more to securing virtual servers than not running VMs as guests of a Windows host. If cyberfelons gain local or remote access to a VMware Virtual Center console, your world is their oyster. This seems like a fairly obscure potential risk -- Virtual Center is pretty easy to lock down -- but are there other risks unique to virtual servers?
I've posited that a virtual machine's virtual disk volumes, being condensed into a single file, could become an aid to a black hat working an inside job. If he or she can't get out of the building with physical hard drives, then a simple copy of a virtual drive image duplicated to a desktop external USB drive, which can now hold 750GB of data, would let the larcener stuff your server in a backpack and scan its contents at his or her leisure. A less experienced administrator may take more care to make sure files inside the virtual image are secure than to ensuring that the image itself is secure.
Microsoft plans to alter Windows to add what it calls enlightenment so that it can optimize its operation based on the knowledge that an instance of Windows is running in a virtual machine. That strikes me as a horrible idea, especially because Windows software partners will demand APIs that allow them to write enlightened system-level add-ons for things like anti-virus and intrusion detection. As it is, virtualization vendors have some work to do to protect virtual machine instances from being discovered as virtual. I can do it by querying the virtualized hardware to find out what CPU and chipset it's using. Virtual systems tend to mimic outdated hardware, like Intel's 440BX chipset. A MAC (media access controller) address identifies the manufacturer of an Ethernet card, and each virtual machine vendor uses the same one or two types of simulated Ethernet devices.
The concern typically expressed is that if a virtual machine is discovered to be virtual, the host OS (in a host/guest virtual configuration) is an easy target. I'm more concerned about lateral attacks, because multiple VMs on a single system tend to start life as a common virtual drive image. The rapid deployment is a major advantage of virtualization, but it also saves cyberfelons the trouble of treating each system as a unique puzzle. Multiple virtual machines sharing one physical system are likely to use a sequential range of IP addresses, and they often have identical local administrator passwords. Crack one, and you've cracked all servers with similar characteristics.
Finally, there is the issue of detection. It is practically impossible to reboot a physical server with a cracked kernel, or to access Windows' recovery console (where the administrator password can be reset) without attracting attention because the server goes off-line. However, it is theoretically easier to do a "root exploit" on a virtual machine because a VM can be duplicated and failed over to a clone of itself without disappearing from the network.
Like other most-feared exploits, these are theoretical risks rather than proven real ones. Still, some of the characteristics that make virtualization so convenient could conceivably make virtualized assets easier prey than physical ones.