So one side of the fence is screaming about how a hardware assisted hypervisor rootkits are 100% undetectable, and the other side is yelling back saying thats totally wrong and timing attacks against it are trivial. This of course can be countered saying that an HV can trick timing attacks by modifying a VCPU's TSC_OFFSET value and an external clock would be required to measure time skew which may or may not be conclusive that there is something malicous going on. Without any numbers or demos of this attack its hard to say really how this all plays out. Being impatient for someone else to do this and REALLY hating people calling things like this 100%, I figured id try some things out (all tests were on a Pentium D in 32bit mode)....



First lets take a look at the simple case, a plain old #VMEXIT. Note that im using many iterations to try and get a cleaner reading since many things could interfere with it. Examining this test closer you can see interrupts being handled some but it doenst seem to effect the reading.


Attempting to detect a #VMEXIT on a cpuid instruction...
Total iterations : 10000000
Total ticks : 0x0022a54b17
Ticks per iteration: 58
Doesnt look like a VM based on CPUID time to execute

Attempting to detect a #VMEXIT on a cpuid instruction...
Total iterations : 10000000
Total ticks : 0x1264c45a78
Ticks per iteration: 7900
Looks like a VM and CPUID is causing a #VMEXIT


Pretty clear which one is in a VM now isnt it? Of course the #VMEXIT handler could have fixed up the TSC_OFFSET to fool us so lets mov onto something else.

RDTSC which reads the tick counter in the CPU normally is not trapped by a hypervisor however take a look at this. Ill explain why I used so many iterations in a moment (other then seeing the large time skew).


Attempting to detect VM guest mode via rdtsc's TSC_OFFSET overhead...
Total iterations : 1000000000
Total ticks : 0x01aff2bf11
Ticks per iteration: 7
Approximate time : 4 seconds
Approx. tick res. : 0x006bfcafc4 / second
Does not appear to be in a VM based on completion time
Does not appear to a VM based on RDTSC execution time

Attempting to detect VM guest mode via rdtsc's TSC_OFFSET overhead...
Total iterations : 1000000000
Total ticks : 0x2eeb56366b
Ticks per iteration: 201
Approximate time : 67 seconds
Approx. tick res. : 0x00b3461018 / second
Appears to be in a VM based on completion time
Appears to be in a VM based on RDTSC time to execute


So 7 vs 200 ticks, whats up with that? Well the overhead is in adding the TSC_OFFSET while in virtualization mode. The reason I have such large iterations is first because I am lazy and only using the return value of time() instead of GetTickCount() to calculate a ticks/time resolution and wanted to keep the code ANSI C for anyone that wanted to try this out on *nix or whatever. The tick resolution isnt going to be all that accurate since itll be rounded off to the nearest second but for our purpose here its more then accurate enough. Also it reinforces the fact this difference can be visually observed without a doubt and without using any measuring device.

Ok so lets set aside the fact this is sooooo visibly noticable for a second and assume you have this running once a day as a background service or something and dont visually pay attention to the execution time. This here is still attackable using the same #VMEXIT and TSC_OFFSET fixup since a hypervisor (generally not by default) can intercept rdtsc instructions, this however is going to increase your execution time to ~8000 ticks in my setups case and with some really quick math that should put us up to 40 minutes to complete! Remember though.... we are not at the terminal and we dont notice this....

Lastly lets actually try and programmaticlly detect this skew, to the best of our ability anyway directly in the VM itself.


Attempting to calculate an estimated *kosher* tick resolution...
Observed 0x0354e96681 ticks in 9 seconds
Estimating approx. 0x005ec4999c / second
Reported tick resolutions appear to match, no malicious hypervisor suspected.

Attempting to calculate an estimated *kosher* tick resolution...
Observed 0x02fe74bb6a ticks in 8 seconds
Estimating approx. 0x005fCe976d / second
Reported tick resolutions appear to match, no malicious hypervisor suspected.


Here we just do a bunch of busy work for a while that doesnt cuase a #VMEXIT to get a rough, hopefully clean tick resolution. It doesnt have to be that accurate since the *report* only triggers on a difference of a factor of two. If there was an attack against this the difference will be HUGE so a factor of two on a per second resolution is more then safe. This could be attacked by the hypervisor in two ways, first either the before/after stats readings could be fudged but more then likly would require an implementation specific attack against this tool. The second would be for a hypervisor to skew the hardware clock by delaying the the delivery of the hardware clock interrupt by a factor of X where X is the factor at which it is skewing TSC_OFFSET. This for sure would fool the the utility, which would take forever to execute still, but also would probebly have some severe side effects in terms of thread scheduling and your system clock (provided you turn off network time syncing) and who knows what else.

So there ya have it. Throw away that external timing device, just run the damn utility. Assuming your not worried about an implimentation specific attack on it, itll do a pretty good job at telling you if your in a hardware assisted VM or not. If you had time to take a nap, have a shower, and take the girlfriend out for dinner and it STILL hasn't finished then you can start to worry, otherwise dont sweat it. Im not going to make any claims its 100% fool-proof but I dont believe anything in systems are binary =).

There are a couple other little tricks I think you can do that are not timing based you can do to detect virtualization mode however testing them out is pretty low on the priority list for now.

Code is in my vault. I need to update my site so when I do ill put it up there too. It only compiles for windows at the moment and only for 32bit however if you want to add in that gcc inline stuff that totally confuses me or add a 64bit .asm file for windows go for it, try it out and please mail me the changes so I can update it for everyone to get access to.

read comments (13) / write comment

recent comments:

my default was off	bugcheck	16.Aug:15:29
nice work	darawk	15.Aug:03:34
computers easily say ff than 100 but not the humans so we are	toto22	13.Aug:10:29
Great!	koala	13.Aug:05:52
com	koala	13.Aug:05:49

. . .

views: 7687   printer-friendly version