Earlier this year, in May, the Zero Day Initiative published a “0day” advisory (as ZDI-14-159, with CVE ID CVE-2014-3790 assigned) for a security vulnerability in VMware vCenter Server Appliance that I’d submitted last year.
At the time of ZDI’s publication, no patch was available from VMware. Users were however provided guidance on mitigating against attacks on affected systems. Now that some time has passed, and with permission to republish granted by ZDI, my original report follows.
I suspect VMware has since patched the shell escape bugs, but I haven’t noticed this in the release notes I’ve seen. If I have the opportunity to revisit the vCenter Server Appliance, I’ll be keen to assess what’s changed.
Thanks to ZDI for assisting with the report to VMware, and for electing to publish its advisory without a patch available.
I recently performed some network troubleshooting on a newly-racked vCloud management cluster. The cluster was comprised of two ESXi 5.5 hosts. Management connectivity was OK for one but not the other, even though ESXi and switch configuration appeared to be correct and consistent between both hosts.
The lack of connectivity to one of the hosts was due to an easy-to-make mistake in identifying port numbers when cabling. The configured ports were “off by one”, but this wasn’t immediately obvious as media had been connected to adjacent ports.
The diagnosis was aided by LLDP, which is notable as vCenter was not yet available and a vNetworking Distributed Switch could not therefore be used.
VMware has made patches available to prevent data in certain VMDK files being used as a virtual disk descriptor following a vulnerability report from me.
In brief: These patches address an issue where a virtual machine user might be able to gain read / write access to arbitrary ESXi host files and execute arbitrary code on the host system given particular vSphere permissions.
I will not describe the vulnerability further at this time. For environments where untrusted users may manage their own VM disks, I would urge consulting the following material.
I would like to thank JPCERT/CC for assisting with the report and VMware, and to acknowledge related earlier work of security researchers at ERNW GmbH.
Earlier this year I discovered two security vulnerabilities in ESXi 5.0 that allow an attacker to bypass authentication controls in one of the ESXi CIM network services, or to execute arbitrary code. Further investigations showed that these vulnerabilities were also present in the earlier releases of vSphere 4.0 and 4.1.
The initial public disclosure of these vulnerabilities follows.
I gratefully acknowledge the assistance of JPCERT/CC and AusCERT in assisting with a report to VMware and preparing for disclosure.
If you’re interested by methods of aligning disk partitions used by guest operating systems in VMware environments then you’re probably already aware of the potential issues that arise when block boundaries don’t align (even in non-VMware environments). If you’re not aware of the issues or want to refresh your memory, read
Some time ago I was presented with reports of sub-optimal usage levels on storage array controllers and looked into the role played by virtual machines with misaligned partitions. Discriminating the impact of disk I/O not aligned to the block boundaries used by the array was difficult at the time (mixed workloads, earlier firmware / software), but early trials indicated improvement.
The problem we faced was, in part, due to a previous successful physical-to-virtual migration effort. The P2V tool used at the time did not re-align partitions, and there were many hundreds of misaligned partitions! I started to consider the problem, the tools available and other ways to approach realignment.
After a little prototyping I was pleased to find that – with a little VMDK preparation – it is possible to leverage vSphere storage vMotion to do the bulk of the re-alignment work… with the virtual machine powered on!