As we are receiving a lot of questions about our VMDK has left the building post, we’re compiling this FAQ post — which will be updated as our research goes on.
How does the attack essentially work?
By bringing a specially crafted VMDK file into a VMware ESXi based virtualization environment. The specific attack path is described here.
What is a VMDK file?
A combination of two different types of VMDK files, the plain-text descriptor file containing meta data and the actual binary disk file, describes a VMware virtual hard disk. A detailed description can be found here.
Are the other similar file formats used in virtualization environments?
Yes, for example the following ones:
- VDI (used by e.g. Xen, VirtualBox)
- VHD (used by e.g. HyperV, VirtualBox)
- QCOW (used by e.g. KVM)
Are those vulnerable too?
We don’t know yet and are working on it.
Which part of VMDKs files is responsible for the attack/exposure?
The so-called descriptor file, describing attributes and structure of the virtual disk (See here for a detailed description).
How is this to be modified for a successful attack?
The descriptor file contains paths to filenames which, combined, resemble the actual disk. This path must be modified so that a file on the hypervisor is included (See here for a detailed description).
How would you call this type of attack?
In reference to web hacking vulnerabilities, we would call it a local file inclusion attack.
What is, in your opinion, the root cause for this vulnerability?
Insufficient input validation at both cloud providers and the ESXi hypervisor, and a, from our point of view, misunderstanding of trust boundaries, such as that one should “not import virtual machines from untrusted sources”.
Does this type of attack work in all VMware ESX/vSphere environments?
Basically, the ESXi5 and ESXi4 hypervisor are vulnerable to the described attack as of June 2012. Still, the actual exploitability depends on several additional factors described here.
Can this type of attack be performed if there’s no VMDK upload capability?
No.
Which are typical methods of uploading VMDK files in (public) cloud environments?
E.g. Web-Interface, FTP, API, …
Which are typical methods of uploading VMDK files in corporate environments?
In addition to the mentioned ones, direct deployment to storage, vCloudDirector, …
Will sanitizing the VMDK (descriptor file) mitigate the vulnerability?
Yes, absolutely.
From our perspective this should not be too difficult to implement. There are basically two steps:
- Striping leading directory paths/relative paths from the path to be included
- Restricting included files to customer-owned directories
However a certain knowledge about the specific storage/deployment architecture is necessary in order to sanitize the VMDK descriptor file and not break functionality.
Will VMware patch this vulnerability?
Probably yes. They might do so “silently” though (that is without explicitly mentioning it in an associated VMSA) as they have done in the past for other severe vulnerabilities (e.g. for this one).
Could you please describe the full attack path?
All steps are described here.
More details can be found in a whitepaper to be published soon. Furthermore we will provide a demo with a simplified cloud provider like lab (including, amongst others, an FTP interface to upload files and a web interface to start machines) at upcoming conferences.
Do you need system/root access to the hypervisor in order to successfully carry out the attack?
No. All necessary information can be gathered during the attack.
What is the potential impact of a successful attack?
Read access to the physical hard drives of the hypervisor and thus access to all data/virtual machines on the hypervisor. We’re still researching on the write access.
Which platforms are vulnerable?
As of our current state of research, we can perform the complete attack path exclusively against the ESXi5 and ESXi4 hypervisors.
In case vCloud Director is used for customer access, are these platforms still vulnerable?
To our current knowledge, no. But our research on that is still in progress.
Are OVF uploads/other virtual disk formats vulnerable?
Our research on OVF is still in progress. At the moment, we cannot make a substantiated statement about that.
Is AWS/$MAJOR_CLOUD_PROVIDER vulnerable?
Since we did not perform any in the wild testing, we don’t know this yet. However, we have been contacted by cloud providers in order to discuss the described attack.
Given AWS does not run VMware anyways they will most probably not be vulnerable.
Is it necessary to start the virtual machine in a special way/using a special/uncommon API?
No.
Which VMware products are affected?
At the moment, we can only confirm the vulnerability for the ESXi5 and ESXi4 hypervisors. Still, our research is going on 😉
Stay tuned,
Matthias and Pascal