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.
