What information about a vmware host is available to the guest?

In vmware Workstation, what information about the host software and hardware is made available to the guest OS.

For the purposes of my application, I'm concerned about a process on the guest OS gaining information about the physical hardware where the host is running. This could include details such as serial numbers, MAC addresses, or anything that could identify physically computer being run.

Both the host and guest will be running Ubuntu Linux.

Edit: vmware-tools will be installed on the guest

Edit 2: Adding bounty

I've done a lot of research on this question, and most answers have words like "shouldn't" in them. I need to know with some degree of certainty, that a vmware guest cannot see any of the following items (In that, if these things were available to the guest, it would be considered a massive security breach)

• any hardware serial numbers
• mac addresses of host network interfaces
• registration serial number of vmware software
• any files on the host operating system

The motivation for this question is that I need to run some highly untrusted software and I want to sandbox it away from any information that could reveal my identity. For instance, I assume this software will attempt to read my processors serial number and report it back to its creator, and I assume this could result in a trace back to my real world identity. Call this paranoid if you like. Part of my situation requires that vmware-tools is installed.

Solution 1:

Information about a host can leak to a guest in a number of different ways. VMware (and virtualization products in general) provide protection against many things. While it is unlikely to be able to provide a complete isolation environment, it probably does a pretty good job. For example, some virus researchers use VMware to provide a safe environment to study the behavior of malware.

Host information can leak to the guest:

• if the guest directly executes instructions that the virtualization layer does not intercept.
• if the guest can observe network traffic directly on the same network segment as the host.
• if the guest can communicate to the outside world and probe back to the host.

Your primary concern appears to be about the first method of leakage, though you should be sure to protect against the other mechanisms as well.

VMware (and other hypervisors) provide virtualization by intercepting what are considered to be sensitive instructions. Sensitive instructions would either reveal to the guest information about the host, or allow the guest to escape the containment of the virtualization layer. For example, the instruction that modifies the page table base (which controls memory access) must be detected by the virtualization layer, intercepted, and replaced with a "safe" version of that instruction that preserves the illusion of virtualization.

To provide the illusion of a separate machine from the host, instructions that reveal identifying information about the host (such as serial numbers, MAC addresses etc) are also virtualized. In VMware, these things can be set in the vmx file. This stuff is well understood and presumably safe.

Sometimes, there are trade-offs about what is exposed, such as the CPUID instruction, which recent versions of VMware provide some "protection" against. (See VMotion and CPU compatibility for many details about CPUID virtualization.) When executed as a privileged instruction, this can be trapped and emulated, but it can also be executed as a native instruction which may expose some (presumably uninteresting) information to the guest.

However, the guest can also passively learn other information about the host. For example, by probing memory timings, the guest can get information the size of various caches. The ability to learn about other guests (or the host) via timing and other vectors ("side channels") is an area of active research. In October 2012, researchers discovered that it is in fact possible to extract cryptographic keys from other VMs. This may be quite scary and the limits of what can be discovered and how to protect against this are not yet fully clear.

The best way to be fully secure is to isolate your machine via air gap from the rest of the world. Then it does not matter what the malicious software learns because it can not communicate that information to anyone. When you are done, wipe the machine. Using a tool like VMware makes this wiping and state recovery easier because the machine state is encapsulated in a set of files.

Solution 2:

The guest should not know anything about the host settings such as its networks, because it is handed a virtual hw that should behavior (almost) exactly like physical hw. However some things like cpu the guest has to know, but that knowledge should not compromise any security.

So if there is any settings information leaks from host to guest, it would be a security hole.

If you enable hgfs (host-guest filesystem), however, then at least part of the host file system will be visible in the guest and it is possible to derive some information about the host. You should disable that if you are concerned.

All this may not really matter normally, as in most cases workstation is used personally, i.e., you have access to the host in any case. Otherwise you should be looking into server virtualization (vsphere, xen, kvm).

Solution 3:

The article How to extract host information from within a VM? describes utilities under ESX(i)/vSphere that can be used by the guest to get some host information. This is necessarily limited in scope because of security reasons.

The first utility is the VMware Toolbox command. It provides some information about ESX(i) and guestOS configuration including basic resource statistics.

UNIX/Linux - /usr/bin/vmware-toolbox-cmd
Windows - C:\Program Files\VMware\VMware Tools\VMwareToolboxCmd.exe

The second is the vmtoolsd (VMware Tools Daemon) utility, where the "info-get" parameter can get guestinfo set within the virtual machine's .vmx configuration file or in VMX memory while the virtual machine is running.

UNIX/Linux - /usr/bin/vmtoolsd
Windows - C:\Program Files\VMware\VMware Tools\vmtoolsd.exe