Virtualization And The Apple Effect

Remember when attackers ignored Apple products? Back when the platform was limited to industry-specific niches? Mac viruses are still rare, but the explosive popularity of iThings and Apple's growing market presence (now around 14% of total U.S. personal computing share) mean they're a growing concern. Hypervisors are also popping up everywhere, and not just in data centers. Even Microsoft's Xbox console sports an elementary hypervisor (not Hyper-V) to separate the system software from underlying hardware. And more popularity inevitably equals more attacks.

Some IT pros saw this coming. Back when vSphere was still called ESX server, I remember sitting with a group of network professionals and discussing how the hypervisor changed the security landscape by interjecting a new layer into the stack, thereby creating a new attack surface. The more senior members of our little group pointed out that because hypervisors were written by humans and consisted of code, they were inherently vulnerable. Most of my team scoffed--after all, in 2002, only a small percentage of IT shops had virtualized infrastructures. With hardware and implementation costs acting as a barrier to adoption and major vendors like Microsoft refusing to support widely used products like Exchange and SQL Server running on virtualized platforms, confidence in virtualized infrastructures and their ability to show a compelling ROI was not exactly high. But I remember thinking it was only a matter of time before attacks on the hypervisor went mainstream.

That time is now, and evidence of hypervisor vulnerabilities in 64-bit paravirtualized Xen hosts (CVE-2012-0217) has brought home exactly how right those old-timers were. When it comes to market share, the hypervisor is king. Our InformationWeek 2012 State of the Data Center Survey, fielded in April, shows just 14% of respondents (all involved with management or decision-making at data centers that are 1,000 square feet or larger) don't have a virtualization management or private cloud software stack in place; the top pick by far, with 53%, is VMware vCenter. At No. 2, with just 10%, is Microsoft System Center VMM.

With widespread adoption in every vertical and in industries of every size, the incentive to write exploit code for common hypervisor platforms is very compelling indeed.

The Xen vulnerability brings the matter of hypervisor security to our front door. An attacker who compromises an unpatched guest machine can now root the host itself on unpatched Xen implementations. The fact that CVE-2012-0217 exists means we can no longer ignore security at the hypervisor and rest easy at night secure in the knowledge that exploits simply don't exist.

Still, while the landscape just became a whole lot scarier, it's not all gloom and doom. VMware in particular has been proactively preparing for this moment since February 2008, when it launched the VMsafe initiative. The idea behind VMsafe was to get a small number of highly trusted security providers deep into VMware's hypervisor and collaboratively develop APIs and intercept code to mitigate and prevent hypervisor exploits. While VMsafe has been discontinued, its successor product line, vShield, is alive and well and has been the subject of considerable enhancement in vSphere 5.

VMware has also espoused the fact that a small, compact, and robustly tested hypervisor like vSphere is intrinsically difficult to write exploit code for, a statement with which most security professionals will agree. While Hyper-V continues to gain in market share, largely because of aggressive pricing, VMware's full-featured ESXi sports a 70-MB installed footprint versus around 3.5 GB for a corresponding Server 2008 R2 Core Hyper-V installation. This means that VMware is fully functional at one-fiftieth the amount of code, a significant attack surface advantage for the seated virtualization giant.

Even so, VMware has taken a few lumps. In 2008, a vulnerability dubbed CVE-2008-4916, which took advantage of faulty display code to enable execution of code on the host machine, was demonstrated; however, the vulnerability was only ever proved on VMware workstation, and VMware patched the bug before releasing vSphere 4.0. This year, a new vulnerability in VMware display drivers, CVE-2012-1510, enables local privilege elevation on a guest machine running the unpatched driver but does not threaten the host itself. Also this year, CVE-2012-1517 can crash the host VMX process and is listed as having the potential to execute privileged code on the host, even though a proof of concept has not been demonstrated.

Despite the lack of a corresponding case of guest-to-host escape like CVE-2012-0217, the virtualization giant has come close to a serious vulnerability more than once.

So what does it all mean? Simply put, despite VMware's best efforts to mitigate vulnerabilities and its visionary leadership in the area of hypervisor security, vulnerabilities are still becoming a fact of life in virtualized infrastructures.

And with the hypervisor being a critical component of everyday business strategy from enterprises both small and large, it's only a matter of time before the more enterprising members of the black-hat community start finding exploits for major hypervisor platforms with increasing frequency.

Network and security professionals would be wise to pull their heads out of the sand and start addressing virtual security before it's too late.