VMware has confirmed that there was a theft of the ESX source code around April 8th, 2012. I have some non-linear thoughts on this whole thing.
First, the code is from 2003 & 2004, and for ESX. ESX was the big, bloated hypervisor that shipped with whole Linux installs, and the purported 300 MB of source code sounds like they might have code for a lot of the Linux utilities that shipped with. So what? The newer version is ESXi which forgoes the Linux install in favor of being very small. That said, I’m going to assume they have the source code for the base hypervisor itself. I’m also going to assume that some of the hypervisor code from then has made it forward into current products, which would make everything vulnerable if there is a bug found.
I can only assume that VMware is doing internal code reviews and using automated security testing tools to find at least the basic problems in their software, like null pointer dereferencing, buffer overflows, SQL injections, etc. Certainly if they are not doing this now would be a good time to start to get ahead of this problem.
I’m also going to assume that if a problem is found that it won’t be made public by the hackers. There’s big money in the sorts of things you can do with a vulnerability in software like this. As such, it’s an arms race now, and whoever finds the problems first wins.
There are all sorts of problems a hacker could cause for an ESX host if a vulnerability is found, but many of them should also be prevented by your “defense in depth.” Defense in depth is the idea of using multiple security controls in layers so that when one fails, like in this case, another will be able to cover it. If a remotely exploitable vulnerability exists in ESX a properly configured firewall should be able to prevent exposure or compromise.
The holy grail, though, is a VM escape, where a VM can be made to interact with the hypervisor outside of the standard APIs. If you can find one of these you can compromise anything you have a VM running on, and potentially access your neighbor VMs, which is bad news for cloud providers and multi-tenant setups. These are very rare, though, and very high-profile when they’re found. Frankly, it’s much more productive & possible to attack infrastructure in other ways.
Beyond security, though, there are also industrial espionage implications, in that you get to see the way the virtualization industry leader is doing proprietary things like vMotion, etc. Hopefully their competitors are already well past 2003 & 2004 levels of code, but who knows.
The biggest and most persistent problem is all the enterprises that just don’t update their software. All OSes & software need updates, and your failure to acknowledge and prepare for that fact is not the vendor’s fault, despite an event like this. A proper configuration for vSphere clusters should allow vMotion, which then allows you to do rolling updates of the underlying infrastructure without affecting the workloads once a patch is made available. Which in turn means you should be doing these updates.
So, in short, this is a serious situation, but it’s no different than using an open source hypervisor where everybody can see the code. If you’ve been using good security & system design practices it isn’t something to freak out about, but I’d be prepared to apply some security-related releases in the near future. And if you aren’t there now I’d be thinking about getting to the latest levels of the major version you’re on pretty soon, because, if nothing else, it’s just a good habit to have.
Yes, the code thats out there is “old” code. BUT it may still have the proprietary stuff connected to it (i.e. the memory mapping/over-provisioning code) that VMware keeps under lock and key. That is the code that separates VMware from all the rest. I’m not saying its a THAT big of an issue, but its like government, the more that the issue is not discussed/hidden/only alluded to and not opened to the public, the worse the issue most likely is.
That is definitely a concern, though less for traditional end users and more for VMW shareholders. Traditional end users may actually benefit from the leaking of proprietary information, in that Hyper-V, KVM, Xen, etc. will be able to compete more effectively with VMware and the overall price of these solutions should drop.
I also equated this to open-source code, which isn’t quite accurate since open source code has had the benefit of public review from the start, and probably has fewer software errors in it than the stolen proprietary code.