Data centers

10:08 AM
Mike Fratto
Mike Fratto
Commentary
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
50%
50%

VMware's Lost Source Code: Not A Panic Situation

VMware lost some of its ESX source code. Cue the sky-is-falling claims. Don't worry, there's no need to panic.

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.

Mike Fratto is a principal analyst at Current Analysis, covering the Enterprise Networking and Data Center Technology markets. Prior to that, Mike was with UBM Tech for 15 years, and served as editor of Network Computing. He was also lead analyst for InformationWeek Analytics ... View Full Bio
Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
Cartoon
Hot Topics
7
VMware NSX Banks On Security
Marcia Savage, Managing Editor, Network Computing,  8/28/2014
5
How To Survive In Networking
Susan Fogarty, Editor in Chief,  8/28/2014
White Papers
Register for Network Computing Newsletters
Current Issue
2014 Private Cloud Survey
2014 Private Cloud Survey
Respondents are on a roll: 53% brought their private clouds from concept to production in less than one year, and 60% ­extend their clouds across multiple datacenters. But expertise is scarce, with 51% saying acquiring skilled employees is a roadblock.
Video
Slideshows
Twitter Feed