As promised from my blog back in April (sorry it took so long!), here is a follow-up examination to the vulnerabilities announced from 2010 as they relate to ESX and ESXi. As I mentioned before there were 106 different CVE’s that came out of the X-Force DB with the search I pulled. I tried to be as thorough as possible and only focused on vSphere’s ESX and ESXi as opposed to the entirety of our product lines. I also found that several of the items returned were actually for Workstation and were only detected because there was a combined VMware Security Announcement (VMSA) that covered multiple patches. So all of the stats have been updated to reflect the new total of 99. Of those 99, only 7 applied to VMware’s owned code and of those, only 3 applied to ESXi’s code. Another interesting stat was that 1 of those 3 applied only at version 4.1 of ESXi, and the other 2 only applied to version 4.0. Lastly, 6 of those 7 applied to ESX versions 3.0 and 3.5 and 2 of those 6 applied to ESXi version 3.5. That’s a lot of numbers, but what it tells me is that by moving to ESXi as a sole platform, we’re moving in the right direction because there are less overall patches and less patches in each subsequent version.

 
So looking at the breakdown of the announcements in the chart below you’ll notice the pretty even split between specific linux exploits for the ESX COS and open source libraries used heavily in the ESX COS. There were also a lot of Java vulnerabilities announced last year. The common thread here is that these hit us just as they did for every other vendor in the industry using those tools. And they are very common tools like OpenSSL, Glibc, Java, Linux kernel, etc.  The fact that we’re not unique here should be an important factor to consider since you would have these same types of patches on other platforms.

 

1

The next important set of stats to look at is the classification. X-Force uses CVSS just like many other vendors to assign their risk ranking. One thing that was interesting though was when looking at items like vmware-libraries-code-execution (57663) it was assigned a “High Risk” classification, but the CVSS base score was only 4.4 and the temporal score was a 3.3. But when looking at vmware-web-requests-spoofing (57312) it was given a “Medium Risk” with higher CVSS scores for both rankings. It’s these interesting skews that mean we need to consider the real impact as it directly relates to each individual organization and deployment. Below is a breakdown of those risk ratings, but knowing what we do now I would recommend taking these with a grain of salt. One point to consider is that inside VMware we use CVSS for scoring, but have also added a few components for calculating potential severity in a virtual environment. These are value that the original CVSS spec never considered. For example, in a reported escape of any kind we score that a 10 (the highest value) which means it receives the most critical severity. We do this for a few other possible attack vectors. Which means we’re laser focused on making sure we produce the most secure products we can for our customers.

 

2

Lastly I think it’s important to look into the sensationalism in the security research industry. Frequently we hear of “exploits” to virtualization, but there is usually a lack of evidence as to the critical nature of the vulnerability. In typical general purposes OS’s we’re used to seeing buffer overflows that are able to fully compromise the entire computing environment. That perception continues to pervade the rest of the computing industry as if it is gospel. Yet, the environment created by a Type-1 hypervisor is drastically different than the direct hardware access a regular OS has. There are multiple layers of abstraction that I previously discussed and each of those layers builds upon themselves to create defense in depth computing for the virtual environment. It is because of this that I attribute the results of the chart below. Greater than 86% of all of those vulnerabilities were listed as “Unproven” and all 7 of the vmware vulnerabilities I listed before fell into that category.

3

Now I won’t sit here and tell you to not be vigilant with your examination of newly announced CVE’s, in fact I’ll tell you to examine each one of them very closely and thoroughly. Also I won’t say that someone won’t someday come out with some exploit code and release it in the wild, because that would be giving you a false sense of security. This is software and all software has its defects from time to time. What I will tell you is the importance of being up to date on ESX and ESXi. In fact I’m going to drop ESX entirely because soon we will be moving to an entirely ESXi offering and your only option will be the more secure ESXi platform.

We need the industry to drop the stigma that’s been adopted over the last 20 years of OS patching. It’s incredibly unfortunate that we’ve all grown up in IT in an age when certain vendors updates required the “early adopters” to test them for 6 months or years before large IT shops felt comfortable applying them. We at VMware have a very different approach. We want you to update early and often and stay on top of every update that comes out. When you move to the ESXi platform I would seriously encourage you to start looking at stateless implementations of deploying ESXi where every time you reboot the host you’re able to give it the latest and greatest update automatically. This will help you reduce the patching/updating time to your VMware vSphere environments on the whole and you’ll be better off for it in the end as you’ll be assured your hosts are running on the latest and greatest for both features and security!

 

 

If you'd like to do your own analysis or review the same CVE's I did, here is a CSV file with links to each of them in the X-Force DB.  Download XFDB Query