The Xen Project has reported multiple guest/host escape bugs over the past year, which has led to growing concerns...
about hypervisor security. Is there anything that can be done to protect against these risks until a patch is released? Should open source virtualization software like this be avoided?
Any time a significant vulnerability is found in any software, enterprises should assess the potential impact on their systems. For example, a heap overflow vulnerability in Xen can allow a privileged guest in a guest operating system to gain elevated privileges when an emulated IDE CD-ROM is enabled. If none of your guest operating systems have virtual CD-ROM drivers enabled, then this vulnerability will not affect your organization.
While waiting for a patch, you could opt to run your virtualized servers on dedicated machines. AWS offers an option to use dedicated hardware when launching an instance. You will pay more, but your virtual machines will only share hosts with other VMs that run from your account.
The question about avoiding open source virtualization software seems to imply that the likelihood of a vulnerability existing in software is a function of the model under which it is distributed. I have not seen any evidence to indicate this is the case; vulnerabilities creep into both open source and proprietary systems for many reasons. Sometimes, for example, programmers make mistakes, like not checking bounds on array references when using languages that do not provide boundary checks. This kind of risk can be mitigated by performing code reviews, employing static analysis tools, and using memory safe languages that avoid potentially unsafe pointer operations. In this case, design choices and software engineering practices have more to do with the likelihood of a vulnerability than the question of commercial versus open source software.
Complexity is another factor that should be considered when evaluating open source virtualization software options. OpenSSL, for example, comprises hundreds of thousands of lines of codes across two major components for TLS and cryptography services. The Heartbleed bug was one of the most significant vulnerabilities found in any software recently, but I can't recall anyone arguing that was due to OpenSSL being an open source project. Amazon believes the problem lies more in OpenSSL's evolution to a level of complexity that is not manageable. As a solution to the problem, Amazon released s2n, an open source alternative to the TLS components of OpenSSL that requires only several thousand lines of code. Reducing complexity -- albeit at the cost of eliminating features in the process -- is another way to reduce the risk of vulnerabilities.
You might want to consider the question of commercial versus open source for legitimate business reasons, but if security is your primary concern, there are plenty of other factors of application design and software engineering practices that should be considered first.
Ask the Expert:
Want to ask Dan Sullivan a question about cloud security? Submit your questions now via email. (All questions are anonymous.)
Take a further look into the open source software security debate
Learn how to use NIST 800-125-A to understand hypervisor security threats
Was VENOM as bad as Heartbleed? Find out here
Dig Deeper on Cloud Computing Virtualization: Secure Multitenancy - Hypervisor Protection
Related Q&A from Dan Sullivan
Docker's recent upgrade introduced support for hardware signing and in the future, automated security analysis on Docker images. Expert Dan Sullivan ... Continue Reading
Cisco's new project Contiv automates operational policies for containerized applications in the cloud. Expert Dan Sullivan explains the benefits of ... Continue Reading
Dropbox API abused by attackers posing as legitimate users in a huge spear phishing campaign. Expert Dan Sullivan explains how to mitigate the risks ... Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.