Anti-VM: XSETBV check

[Ynob2000]

Hi,

I came across some malware that uses XSETBV to check for VM presence.
Could we add some checks on this?

[gsuberland]

There are a couple of issues I see with this, but I think we need more information to understand how they are using XSETBV before I can concretely say whether this is something we can, or want to, do.

If they're calling XSETBV from usermode, it shouldn't do anything but throw a general protection fault unconditionally, regardless of whether or not the system is running under a VM. Now, shouldn't isn't the same as won't, and it does appear that on some VM platforms you can cause the hypervisor to fault due to buggy handling.

The only reference I could find is this article, which provides an example of using XSETBV as a detection mechanism. However, the way it does so is by registering a bugcheck callback routine in a driver, calling the XSETBV instruction with garbage parameters, then seeing if the bugcheck callback gets called before the system crashes. This indicates that the detection is being done from ring 0, using a driver, and that the detection mechanism necessarily crashes the system as part of the check.

As a policy, Al-Khaser doesn't load drivers or do any kind of ring 0 detection. There are a number of reasons, but the three main ones are that driver signing is a pain in the ass, we don't want to load a driver that could be vulnerable (or load a known-vulnerable signed driver in order to execute code in kernelmode), and we don't want to provide a nice generic signed anti-VM driver for malware authors to use.

Another policy we have is we avoid doing anything that risks crashing the box, causing data loss, or changing system settings.

If you have a reference for how XSETBV can be used in order to detect VMs/hypervisors reliably, from usermode, without crashing anything, then that's definitely something we'd be interested in.

[gsuberland]

Addendum: it also appears that this trick is only intended to work against incomplete / naive hypervisor implementations that were sloppily written (e.g. hypervisor drivers to avoid cheat detection, probably some EDR/AV products too), rather than mainstream virtual machine products.

That being said, I think I need to sit down and have a good read through the VirtualBox source code regarding handling of XSETBV VM exit conditions, because a quick read through (see hmR0VmxExitXsrtbv in HMVMXR0.cpp for a starting point) didn't make it very clear to me as to whether or not this trick can be abused regardless of whether or not the privilege level of the guest caller is properly checked. I would guess that perhaps it is checked further up the stack, based on the hmR0 prefix in the name, but I'd have to do more research to be sure, especially since they explicitly comment that the handler function causes an "unconditional VM exit".