Share
Researchers from the University of Michigan recently created a nifty presentation for BlackHat DC, focusing on live migration for virtual environments. Sadly, despite the quality research, the press only focused on the tool used for attacking the migration process, called Xensploit, and never truly got the object lesson of the talk.
Researchers from the University of Michigan recently created a nifty presentation for BlackHat DC, focusing on live migration for virtual environments. Sadly, despite the quality research, the press only focused on the tool used for attacking the migration process, called Xensploit, and never truly got the object lesson of the talk. (IMG:J.Anderson)
The researchers form the University of Michigan published a paper and gave a talk at BlackHat DC about the security of virtual machine (VM) live migration. The research covered two very common implementations of live migration and looked at VMotion, from VMWare, and Xen’s migration abilities.
Now, the research is quite detailed, you can tell there was a lot of effort that went into it. However, while discussing the security of live migration, they had to look for ways to “break it” or simply prove it was secure already.
The news coverage on the research was scattered at best. Most of the attention focused on a tool created for the research called Xensploit. The tool can be used reportedly to crack the Hypervisor and cause mayhem on the VM box, ultimately spreading to the network. Clearly some in the press failed VM security 101. They also missed the points raised by the research itself.
“Yep, some of the media coverage was somewhat inaccurate. When I spoke to some of the press, I really wanted to emphasize the awareness of the issue but not hype it up or pretend like it's some doomsday scenario by any means,” said Jon Oberheide, the researcher who presented at BlackHat DC.
“In particular, with regards to "taking over the Hypervisor", we showed how an in-progress migration could be manipulated by a MITM attacker in order to exploit vulnerabilities in the migration routines of the Xen dom0 daemon. So to clarify, the MITM manipulation of VM state/memory applies to both Xen and VMware migrations, but the remote Hypervisor exploits only apply to Xen <= 3.1.0,” he adds.
“Encryption of all data-in-transit is certainly one well-understood mitigation for man-in-the-middle attacks. But, the fact that plenty of data flows unencrypted within the enterprise – indeed perhaps the majority of data – suggests that there are other adequate mitigations. Unencrypted VMotion traffic is not a flaw, but allowing VMotion to occur on a compromised network can be. So this is a good time to re-emphasize hardening best practices for VMware Infrastructure and what benefit they serve in this scenario,” reads a post on the VMTN blog responding to the FUD in the news over the issue.
“One of the underlying themes of my presentation is that we've been continually breaking down isolations barriers that provide security in exchange for new functionality,” Oberheide says.
Oberheide points out that he has noticed that the trend has gone from, physical machines where state is protected by hardware mechanisms. (The MMU for example.) There are virtual machines where the machine state is protected by the isolation boundaries of a software layer such as the VMM/Hypervisor, “…which, as we've seen, often fails in its isolation,” to VM migration where the machine state is exposed to the local network, and to the prying eyes of anyone who wants to snoop around.
“This transition isn't necessarily a bad thing...we just have to be aware of the security concerns it presents.”
The entire point of the research was to remind administrators to use proper security precautions. “My 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,” Oberheide said.
Sadly, most of the common practices are simply being ignored. Andrew Kutz, a VM Consultant from Lostcreations, out of Austin, Texas puts it best.
“….private management networks, segregated LANs for datacenter servers, RFC 1918 space -- these area all practices that we should already be implementing. If you are running your servers on the "internet,” and then use one of these links for VMotion traffic, (even if the link is direct and not wide), you're not practicing bad VMotion implementation, you're practicing bad networking. Keep your networks private and secure unless otherwise needed.”
Interested in a more interactive TTH? Join our Facebook Group Want regular updates from The Tech Herald? Follow us on Twitter
Advertising
Comment on this Story