Breaking

VMware did it again: vCenter Remote Code Execution

Yesterday 7Elements released the description of a Remote Code Execution vulnerability in VMware vCenter. The information came in at a good point as I’m at the moment drafting a follow-up blogpost for this one which will summarize some of our approaches to virtualization security. The vCenter vulnerability is both quite critical and particularly interesting in several ways:

  • Once there is proper network isolation & restriction, the vulnerability should not be exploitable from the overall corporate network (or maybe even the Internet — a quick inaccurate shodan search for “vcenter” returned about 1800 results and at random checks actually revealed vCenter systems). It should also not be exploitable from ESXi hosts managed through the vCenter: ESXi hosts need to be able to connect to the vCenter for heartbeat messages, however “only” on ports 443 and 902 — the vulnerability exploits a service running on TCP ports 9875 – 9877.
  • It is questionable whether the exploited Java RMI functionality is really required for the operation of VMware infrastructures. This blogpost provides further detail on the known type of vulnerability in Java applications. VMware had a similar issue back in 2010, where their workaround to fix a vulnerability was to just disable the affected component, resulting in the impression that it wasn’t even required in the first place. Let’s see whether the future will bring up more vulnerabilities which could have been prevented by implementing more thorough hardening of all components (e.g. following the minimal machine principle). Furthermore in 2011 there was a similar 3rd party component vulnerability in vCenter which we covered in this blogpost. The totality of our posts on VMware security can be found here.
  • For high-security environments we have been recommending for some time to use a dedicated vCenter per hypervisor cluster (i.e. if you have two hypervisor clusters, one for internal and one for DMZ systems, you should use two separate vCenter systems). Vulnerabilities like these illustrate the need for that, given that the ESXi hosts need to be able to access the vCenter on the network level.

Happy patching & stay tuned,

Matthias