Friday, April 8, 2016

It should be avoided virtualization software open source? – TechTarget ES

The Xen Project has reported multiple errors guest / host escape during the past year, which has led to growing concerns about the security of the hypervisor. Is there anything you can do to protect against these risks until a patch is released? Should one avoid virtualization software code?

Every time a major vulnerability found in any software, companies must assess the potential impact on their systems. For example, a heap overflow vulnerability (heap overflow) in Xen can allow a privileged guest, in a guest operating system, obtain administrator privileges when an emulated IDE CD-ROM is enabled. If none of your guest operating systems has allowed drivers CD-ROM virtual, then this vulnerability does not affect your organization.

While a patch is expected, you can choose to run their virtualized servers on dedicated machines. AWS provides an option to use dedicated hardware to start an instance. Will pay more, but your virtual machines are only going to share hosts with other VMs running from your account.

The question about avoiding virtualization software open source seems to imply that the probability a vulnerability in the software is a function of the model under which it is distributed. I have not seen any evidence to indicate that this is the case; vulnerabilities they get both open source and proprietary systems for many reasons. Sometimes, for example, programmers make mistakes, such as not checking the boundaries of array references to use languages ​​that do not provide boundary checks.

This type of risk can be mitigated by performing code reviews, using static analysis tools, and using languages ​​secure memory operations to avoid potentially unsafe pointer. In this case, the design choices and practices of software engineering have more to do with the likelihood of a vulnerability that the issue of open source software versus commercial source.

The complexity is another factor that You should consider when evaluating software options open source virtualization. OpenSSL, for example, consists of hundreds of thousands of lines of code through two major components for TLS services and cryptography. The heartbleed mistake was one of the most important vulnerabilities found in any software recently, but I can not remember anyone saying it was because OpenSSL was an open source project. Amazon believes that the problem lies in the evolution of OpenSSL to a level of complexity that is not manageable. As a solution to the problem, Amazon launched S2N, an open source alternative to OpenSSL TLS requires components that only several thousand lines of code. Reduce complexity, though at the cost of removing features in the process- is another way to reduce the risk of vulnerabilities.

You may want to consider the question of the trade against open for legitimate business reasons code but if security is your main concern, there are many other factors application design and software engineering practices that should be considered first.

LikeTweet

No comments:

Post a Comment