It would be interesting to compare the number of VMware escapes, before and after the entire US development team was laid off and replaced with a maintenance team (in China?).

https://www.theregister.co.uk/2016/01/27/vmware_fusion_and_w...

Interesting perhaps, but useless. The number of successful attacks we see on a product is an equation taking in the number of interested parties, the amount of collective experience (in the product) those parties are able to draw from, and the relative reward that the attack can give you.

Assuming that the reward doesn't drop (and it certainly hasn't -- that's gone up every year as VMs have become more and more critical), the collective knowledge keeps growing and thus this will always trend towards more attacks, not fewer.

The layoffs were only a year ago and the product itself was in a mature/stable market, which was one reason for the layoffs. Pre-layoff, VMware's desktop hypervisor had existed and been attacked for more than a decade. Other complications are a shrinking PC market and new versions of Windows.

That's only half the equation. The other half is the complexity of the design along with its assurance activities. It's why the security and separation kernels with user-mode VMM's either had no or few flaws in pentesting. Whereas, VMware's techniques take a pile of complexity, are built with less assurance (see parent comment), and process malicious inputs in privileged modes.

Definitely designed and assured to be shattered. I'd like to see what results they get on mCertiKOS or Muen.

I was at CanSecWest, though I wasn't in the room while these vulnerabilities were being exploited. The claim I heard was that the qemu toolset, compared to the VMWare toolkit, are less functional but also less vulnerable. Still, the qemu device drivers were the source of a significant number of vulnerabilities. Indeed, there was a talk, "Dig into the qemu security and gain 50+ CVE in one year". That talk was, frankly, rather scary.

So, it's not just VMWare specifically.