Xensploit: A recipe for attention
Posted by Kevin Skapinetz on March 14, 2008 at 2:56 PM EDT.
Take the hottest datacenter technology, add a generous pinch of security scrutiny, and a dash of clever name recognition… and ‘Wha-La!’, you have ingredients for our latest topic of vulnerability du jour: Xensploit.
Here’s what you need to know.
A group of researchers from the University of Michigan recently published a paper examining the security of virtual machine (VM) live migration technologies including two common implementations, VMware’s VMotion and Xen’s “migrate” function. Despite offering a comprehensive security analysis of the entire migration process, nearly all attention has focused on the proof-of-concept tool discussed in the paper and later demonstrated by Jon Oberheide (one of the researchers) at Black Hat DC. The tool, named Xensploit, allows an attacker to view or modify VM state/memory by intercepting unencrypted data between physical servers during the live migration process.
Although Xensploit assumes the attacker has access to a protected network, it aptly demonstrates how one can man-in-the-middle live migration traffic to commandeer endpoints in arguably limitless ways. After all, there’s something to be said for the degree of control represented by the bits and bytes of replicated VM data traversing the wire. If unfettered access to system memory is the holy-grail for most attackers, live migration lets the treasure leave the confines of your server’s DIMM slots.
That being said, let’s cut to the chase.
Is unencrypted live migration data a vulnerability? By definition, yes. It is a weakness in the system that can be exploited. I don’t think a single security professional would dispute this, Alice and Bob would be ashamed.
Have software vendors adequately recommended defenses to secure this weakness? Yes. VMware’s security best practices guide clearly states that a dedicated, isolated network should be used for all VMotion traffic. Since encryption mechanisms aren’t built into the migration software (possibly due to complexity and/or performance issues), the guide also advocates the use of hardware-based SSL encryption devices to further secure the out-of-band network. At any rate, the vendor message is quite clear; bad things can happen if someone gets access to live migration traffic. Take measures to properly secure it.
Did the researchers show how this data could be used to “take over the hypervisor”? Not exactly. In addition to examining the security of live migration data over the network, the team also performed a detailed investigation of Xen migration code and discovered two vulnerabilities that could allow a remote attacker to execute privileged code and, in turn, compromise the hypervisor. Although these vulnerabilities certainly reinforce the importance of developing secure VMM services, they only apply to the migration code in Xen <= 3.1.0.
Ultimately, I commend the researchers for their work - research like this is valuable for vendors, customers, and security professionals in many ways. Jon mentioned in the comments of another blog that his “primary goal was to raise awareness for the numerous organizations deploying such technology who may not have followed best practices or were not aware of the associated risks. Hopefully that has happened at least to some extent.”
I think it happened.
