Thoughts on the VMware Code Leak

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.

• VMware Security & Compliance Blog post on the breach.
• Ars Technica’s informative post on the subject, with additional links.
• TechTarget’s article on the breach.

This post was written by Bob Plankers for The Lone Sysadmin - Virtualization, System Administration, and Technology. Licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License and copyrighted © 2005-2012. All rights reserved.