VMTN Blog

Posted by Charu Chaubal
Technical Marketing Manager for Datacenter Management

Recently, security consulting company Intelguardians presented at NDSS claiming they could execute malicious code on the host OS of a computer running VMware hosted virtualization software, such as the free VMware Player or the licensed VMware Workstation. Their subsequent presentation at SANSFIRE 2007, which was reported on in a number of blogs (such as PaulDotCom), apparently extends the NDSS presentation and talked about some other similar exercises (the slides from SANSFIRE 2007 are not yet posted anywhere so the exact details can’t be referenced).

It’s important to understand that this whole issue of guest-to-host compromise only exists for hosted virtualization platforms, such as VMware Player, Server, and Workstation, which run on top of general-purpose commodity operating systems. It specifically does NOT pertain to VMware ESX Server, for reasons that will be apparent below.

Although this series of demonstrations of guest-to-host attack does legitimately show one of the risks of virtualization, it is not due to flaws in virtualization technology as some might like to claim. Rather, it shows the dangers of using a product feature without fully understanding it.

So what should one make of these supposed new security exploits? All of them are based on the ability to pass information from the guest OS to the host OS in a trusted manner. Specifically, there are several ways of doing this in VMware’s hosted virtualization products:

• Host-Guest Shared Folders
• Host-Guest Drag-n-Drop
• Host-Guest Cut-n-Paste

The security of each of these ultimately depend on the host OS trusting the guest OS not to behave badly. If you trust the guest OS, then you believe that information that it passes to the host OS is not malicious or compromised. If the security of the guest OS cannot be guaranteed, then one should inspect any transferred file before doing anything with it. Alternatively, this type of functionality should be disallowed. For this reason, VMware has provided configuration settings which allow you to disable each of these. These settings are described in the VMware Workstation User’s Manual, in the section appropriately titled “Transferring Files and Text Between the Host and Guest”.

Bear in mind: these channels for passing information from the guest to the host are not related to the core virtualization layer. They are added on top of it, to provide ease of management and operation. The ability to transfer files from the guest to the host, e.g. without using scp, can be very convenient. By disabling these mechanisms, you lock out VMware-specific means of transferring malicious files to the host OS. (There are, of course, plenty of other ways of achieving the same thing – one cute way would be to have a hacked web server in the guest serve up an AJAX exploit to a browser on the host.)

As alluded to earlier, this issue doesn’t exist with ESX Server, since the “host” in this case is a purpose-built, thin, light-weight kernel which only runs code that ships with the product (for more information, see this white paper on the security architecture of VMware Infrastructure 3). There is neither any mechanism nor any reason for transferring files from the guest to this “host” OS.

The real lesson, however, is that VMware needs to be more prolific in educating the market about what features require implicit trust. (It doesn’t help that Drag-n-Drop and Cut-n-Paste are enabled by default when a VM is created.) Instead of “Escaping the Cave,” as PaulDotCom says, it’s more like “Being Escorted Out of the Cave.” In the end, security exists only to the extent of your least trusted component, and VMware will strive to provide more proactive guidance in the future that clearly details this.