Hypervisors are the pillars of the Cloud, not the Achilles Heel

Bromium's Simon Crosby strongly advises us not to succumb to Cloudophobia.
Written by Jason Perlow, Senior Contributing Writer

Simon Crosby is CTO of Bromium

The following story was written by guest contributor Simon Crosby.

In a recent piece, Steven J. Vaughan-Nichols writes that hypervisors may be the Achilles Heel of the cloud. The piece draws on a discussion with Linux kernel developer Matthew Garrett, who raises the spectre of targeted attacks on cloud hypervisors: "Once someone gets to the hypervisor then it's game over, everyone can be compromised."

Garrett is technically correct: Vulnerabilities in all major hypervisors and their support code have been documented (eg: Xen, VirtualBox, VMware ESX and Workstation, Hyper-V). Research published by my colleagues Rafal Wotczuk and Rahul Kashyap at Black Hat highlights the potential for devastating "guest to hypervisor" attacks.

But my emphasis on the word potential is deliberate: I'm not convinced that hypervisor attacks ought to be viewed as a significant concern for cloud security, for many reasons: 

  • Better code: Hypervisors are small code-bases developed by some of the world's best engineers, and are subject to more rigorous scrutiny than other software precisely due to their critical role in system security. They surely have vulnerabilities, but I'd be prepared to bet that they have far fewer than comparably sized applications. Public cloud vendors that build on Open Source Software – like AWS and Google – do not disclose what version of what code base they use, and they are passionately dedicated to the security of their infrastructure.
  • Extreme difficulty: To succeed in practice this class of attack requires multiple successful compromises, each of which is extremely difficult to achieve. For a malicious VM to compromise a fellow tenant VM on the same server via the hypervisor probably requires (a) a privilege escalation in the attacking VM (b) a precisely targeted hypervisor attack that allows the attacker to achieve guest-to-host privilege escalation that (c) does not crash the hypervisor before (d) gathering in-memory data or snooping on network activity of other guests and (e) somehow exporting this information (over the network) to the attacker. Possible? Yes. Probable? No.  
  • Attackers are rational:  Attacking another guest via the hypervisor is like paying to try to break into the back of a building through a set of tiny windows just to see if there's something interesting inside. More rewarding by far to pick a valuable target, and enter by the front door – using publicized application or OS vulnerabilities

In my view Vaughn-Nichols is losing sight of the big picture: What is the overall risk faced by a customer adopting the cloud, versus running the application on their own infrastructure? The title of his piece is belied by the fact that to date there have been no reports of real-word attacks, and merely adds fuel to the fire of cloudophobia

The future of secure infrastructure looks brighter too. Both hardware and software technologies are becoming available that will greatly diminish the threat due to attacks via low-level systems infrastructure.   

For example the PrivateCore extensions to KVM encrypt VM memory and storage at run-time. The platform validates server integrity and counters persistent attacks such as rootkits or bootkits, and secures both the hypervisor and cloud user against malicious server hardware.  

Expect to see such features in hardware soon.  For example "trusted enclaves" made possible by Intel SGX technology that will ensure that the data in an enclave (VM) is protected even in the event that the hypervisor itself is compromised.

Finally, there is a rich vein of academic research on techniques to protect hypervisors and guests. I only wish that the press would do more to promote tools and techniques to educate careless application developers to build more secure cloud applications.

Simon Crosby is CTO of Bromium and was previously CTO of Citrix, Inc. 

Editorial standards