Oleksandr - Fotolia

Should open source virtualization software be avoided?

Xen bugs have been popping up, creating concerns about the security of open source virtualization software. Expert Dan Sullivan explains why open source is not to blame for security pitfalls.

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.)

Next Steps

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