Hyper-V versus VMware: Virtual Disk Security

  • Article

Another great email came across my desk from Jeff Woolsey, Principal Program Manager at Microsoft for Windows Server, along with Yoganand Rajasekaran, one of our development team members and Ben Armstrong, the Virtual PC guy. This time the discussion is regarding access to other customer’s data across a multitenant system by an attacker. Here’s what they had to say…

--------------------------------------------------------------------------------

Q: I read an article where an attacker could potentially upload a malicious or compromised VMware VMDK, change the disk paths to access alternative files on the host and potentially access VMs from other tenants on the system. The article is here:

https://www.insinuator.net/2012/05/vmdk-has-left-the-building/

The summary of the article read as follows:

“Summarizing the most relevant and devastating message: VMware vSphere 5 based IaaS cloud environments potentially contain possibilities to access other customers’ data.”

I am EXTREMELY concerned about this issue and wondering about Hyper-V. Should I be concerned?

A: Two points:

  1. You’re right to be concerned if you’re using VMware. The importance of isolation in a multi-tenant environment is paramount.
  2. No, Hyper-V is NOT vulnerable to this attack.
  3. Re-read #2.

Let’s discuss.

Summary of the attack

The VMware VMDK files (equivalent to Hyper-V vhd(x) files) include a descriptor file and the actual disk files. The descriptor file, among other things, includes paths to the actual disk files. When an attacker controls the .vmdk files, the attacker changes the path of the disk files in the descriptor files to point to files on the host. Though it was not possible to load any random host file from the guest, the attacker was able to successfully load binary files from the host inside the guest. This way, the guest can now access contents of the host files.

Applicability to Hyper-V

Hyper-V was specifically designed and threat modeled to avoid such an architecture. Hyper-V doesn’t have an equivalent of the descriptor file for the vhd(x) files. Thus, even if an attacker uploads a vhd(x) to a hosted environment, there is no option of loading random files from the host inside the guest.

This attack simply isn’t possible with Hyper-V.

We’re Not Done Yet

However, we didn’t stop there. We reviewed the attack vector further. Are there similar types of attacks that could be used? The closest analogy for Hyper-V would be that a vhd file could be configured to have a parent path that would give the guest, access to the contents of the parent vhd. If a similar approach of the demonstrated attack is to be performed, an attacker would try to read host file contents by setting the parent path to any desired file on the host. However, this attack wouldn’t be successful either because our validations prevent any random file on the host being used as a parent vhd. The parent vhd path specified has to be a valid vhd file.

So, this theoretical attack isn’t possible either.

In short, we’ve done our homework, and after 10+ years of Trustworthy Computing and the Secure Development Lifecycle (SDL), it shows. Microsoft designs, develops and tests its products to be secure by default and we provide tools to help the world build better software such as:

Finally, don’t forget that Microsoft manages a cloud-based infrastructure (Windows Azure, Office 365, etc.) supporting more than 200 services, 1 billion customers, and 20 million businesses in more than 76 markets worldwide. We understand what it takes to build and deliver highly-reliable cloud platforms, solutions, and services that are secure and private. To learn more check out this Trusted Cloud link.

--------------------------------------------------------------------------------

signature2 (100x78)