Programatically Detecting VMWare environment

[BorisVidolov]

Hello,

I am working for one of the biggest software companies and my team is developing a Windows application that needs to be aware of being run in a guest OS. On non-virtual environments we are using CPU programability that is not available on guest OS-es. We have a workaround, which we apply when we detect such virtual environment. While there is an official way of detecting VPC, we could not find any for VMWare. Thus, we are inclined to advise our customers to install VPC as a replacement of VMWare products. Is there an official method of detecting VMWare that we could use instead?

Thank you,

Boris Vidolov

[oreeh]

There are different ways to detect if you are in a VMware VM.

1. the VM hardware (disk, CD ROM, vmxnet, BIOS, ...)

2. the blue pill approach (can be easily disabled)

3. the presence of VMware Tools (can be easily disabled)

4. timing attacks

[BorisVidolov]

We are not using this detection for security/licensing reasons, but rather for making sure that our tools work on that platform. Thus, I am not concerned about users explicitly disabling functionality as in #2 and #3.

However, which of those is the official way? I want to be sure that our solution would work on any future versions of VMWare software.

Thank you,

Boris

[oreeh]

There's no official way, but ...

#1 is recommended from most users with the 3-boxes logo here in the forum

some examples:

-the disks and the virtual CDROM always contain the string "VMware"

-the MAC address (unless modified) is within the VMware range

-a BX chipset with a P4/XEON/Core/Core2/AMD CPU is only available in a VM

#2 doesn't work as soon as VT is used

#3 doesn't work when isolation settings are used / the tools are not installed

#4 too difficult to program

[esiebert7625]

fyi...this thread has been moved to the Security forum...

Eric Siebert

VMware Communities User Moderator

-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-

Visit my website:

-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-

[Texiwill]

Hello,

As Eric pointed out the only real way to do this is to look at the drivers and devices on the host, however this will not tell you what virtualization technology is in use only that it is virtualized. You may be able to map version of driver to a type of platform, and you can definitely do that with the MAC address, but unfortunately, drivers are part of VMware Tools and not installing them is a security precaution, and MAC addresses even the VMware ones can be modified pretty easily. So you are looking for the proper devices.... If there is a floppy/cdrom (you can not add these), and the disk is not a Virtual RDM then it will say VMware somewhere in there.

For the most secure settings for a VM however, it will be hard to tell. That would be the following:

• no VMware Tools installed (no drivers)

• all isolation settings set

• no Floppy or CDROM device

• Use of e1000 type of network interface

• Use of Physical RDM for all drives

So you need to look for "a BX chipset with a P4/XEON/Core/Core2/AMD CPU is only available in a VM"

Best regards,

Edward L. Haletky, author of the forthcoming 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', publishing January 2008, Copyright 2008 Pearson Education. Available on Rough Cuts at http://safari.informit.com/9780132302074

[oreeh]

drivers are part of VMware Tools and not installing them is a security precaution

Why would this be a security precaution (besides making VM detection a bit more difficult)?

BTW: May name is Oliver not Eric

[Texiwill]

Hello,

Sorry about that Oliver, I saw Eric's reposting and thought Eric for some reason....

If you do not install VMware Tools there ability to detect that this is a VM goes down considerably and considering that currently VMware Tools version numbers are tied to releases of various VMware products you could tell what is hosting the VM. If you can tell what is hosting the VM you can plan an attack that would perhaps escape the VM or crash the VM based on various VMware attributes. For example, if the hacker knew you were using Workstation, the hacker could attempt the vmhgfs escape of the VM attack. Which would fail on ESX but which given the version # of the VMware Tools the hacker would not attempt on ESX as that attempt could give themselves away to the wary. If there was a universal release of vmware tools this would be harder to detect and the hacker would have to attempt the vmhgfs attack on any VM and perhaps give themselves away earlier. Depends on what you are monitoring within the VMs. THere are some known attacks.

Best regards,

Edward L. Haletky, author of the forthcoming 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', publishing January 2008, Copyright 2008 Pearson Education. Available on Rough Cuts at http://safari.informit.com/9780132302074

Message was edited by: Texiwill

[oreeh]

Sorry about that Oliver, I saw Eric's reposting and thought Eric for some reason....

No problem.

Why did I knew that you would mention the infamous hgfs?

Regarding the version numbering: You could install the drivers and leave out the toolbox (and the hgfs) which would effectively prevent most attacks.

If there was a universal release of vmware tools this would be harder to detect

One approach would be to use the open tools (I would love to hear an official statement from VMware regarding support of these tools in a production environment).

[Texiwill]

Hello,

Actually hgfs is not the only current attack against ESX. There is at least one other but it could just crash the VM. Newer versions of Workstation, VMware Server, and ESX prevent this, so if the tools version maps to a version that is susceptible, then a hacker can cause a DoS. Granted there are other ways to do this without explointing VMware, but it is one way that would be hard to trace. The idea is to not give out any information about what the VM is running upon. If that is possible then things would be a bit safer in my mind.

THere is a HUGE amount of information leakage within VMware products. That leakage does worry me as it can be used to further craft attacks.

Best regards,

Edward L. Haletky, author of the forthcoming 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', publishing January 2008, Copyright 2008 Pearson Education. Available on Rough Cuts at http://safari.informit.com/9780132302074