VMware's Lost Source Code: Not A Panic Situation

VMware has confirmed that some of its source code to its ESX Server has been leaked. Cue the dramatic music and breathlessly worded missives claiming the sky is falling and your VMware environment will be secure only if you buy someone's stuff. There's no need to panic.

Clearly, having its source code leaked is bad for VMware, but that doesn't mean it's bad for you. If you are using virtualization, you most likely are using VMware. If a security problem is found via the leaked source code, it may affect your current version or it may not. Either way, let's not panic. There are likely going to be other hurdles that an attacker will have to leap over to leverage a vulnerability in a hypervisor or even management system.

Before you freak out (or if you are dealing with someone who is curious, concerned or freaking out over the leaked source code), ask the following:

Are your hypervisors available from outside the data center in an uncontrolled manner?
Put another way, can anyone connect to the hypervisor through HTTP/HTTPS, SSH or Telnet? If the answer is yes, you have done a bad thing and you should be banished from the data center for life and made to answer level-one help desk calls.

Most likely, the answer is no. Why would you make your hypervisor available outside the confines of where it resides? There is no reason to. Sure, you might be able to access vSphere over an IPSec or SSL VPN from Starbucks, but hopefully you have that locked down pretty well. Ideally, you don't even allow that.

The point is that before attackers can do damage, they have to have access to the target. It's pretty unlikely that organizations are putting their bare ESX servers on the Internet or even on the internal network. If you are, you get what you get and you only have one place to point that finger of blame.

Are your applications on VMs running code so buggy that an attacker could break through to the underlying OS?

If the answer is yes, your programmers should be banished from writing any code that will run on a server and made to sling Microsoft VBasic for Office. While bugs and vulnerabilities in code occur, you hopefully have taken the proper steps to mitigate the damage. These can include making sure you have a software development lifecycle that addresses problems; ensuring that you have security checks built into your SDLC; using, where possible, development methods that are less prone to mistakes and services running with minimal privileges and limited access to the OS.