Hardware-Assisted Virtual Machine Rootkits

Thanks to www.rootkit.com I learned of a new paper by Michael Myers and Stephen Youndt titled An Introduction to Hardware-Assisted Virtual Machine (HVM) Rootkits. Like most good papers they discuss the underlying technology before explaining how to exploit it. I selected a few choice excerpts.

HVM rootkits, theoretically at least, are not vulnerable to any action the operating system can take since the rootkit runs in a more privileged state than the OS. A hypervisor need not even exist in memory that is accessible to the operating system. When a hypervisor bootstraps itself, it makes any instructions or memory accesses which could betray its existence more privileged than the operating system. When these instructions occur, the processor traps to the hypervisor, allowing it to modify the results. Thus, the hypervisor need not make any changes to the operating system to hide its own presence. The hypervisor can, however, make any such changes with impunity and make them undetectable by the operating system...

Unlike the typical hypervisor which loads before it starts its guest VM, an HVM rootkit loads into an already loaded operating system and turns it into its guest VM. Therefore the rootkit must initialize the hypervisor functionality and dynamically take over as host, turning the running operating system into a guest. This process has been repeatedly referred to as “forking” or “migrating” the OS to a guest state, but these terms are misleading.

The hypervisor and OS do not run concurrently (as they would if they were “forked” in the UNIX sense) nor does the OS need to be altered or moved in any way (“migrated”). The process of installing an HVM hypervisor in a running OS is more like that of installing a “shim,” in the software engineering sense of the word. A shim is a piece of code between two layers, in this case between the CPU and all other software running on the system.

At this stage, the practical detectability of HVM rootkits is still hotly contested. The trend is clear, however. Researchers are continually suggesting new detection methods, and the code required in the HVM rootkit to evade each one is successively layering more and more complexity into the rootkit’s design. Paradoxically, the more complicated an HVM rootkit must be to avoid known detection schemes, the more presence it has within the system to have to work to hide...

[T]he popular consensus has been that HVM rootkits will eventually become too difficult or costly to implement, or even that they are ultimately unfeasible. One might point to the fact that there are no known HVM rootkits in the wild. But neither are there any HVM rootkit detectors to find them if there were...

If detection of an HVM rootkit is difficult and impractical, actually procuring a forensic copy of an active HVM rootkit may very well be impossible. The HVM rootkit only needs to exist in RAM, meaning a forensic examiner is tasked with obtaining a copy of all of physical memory in order to search for the presence of an HVM hypervisor...

There are two common approaches to imaging physical memory. One approach is to run software on the local system which accesses physical memory through an operating system hardware interface layer. In this case, an HVM hypervisor is able to intercept and control access to the physical memory by way of its exception conditions. It could present the pages of memory containing its hypervisor code to appear to contain all zeros or all ones, for instance. This subversion of memory would go unnoticed by the forensic capture process.

The second approach to imaging physical memory is to take advantage of the abilities of certain hardware peripheral devices that can perform Direct Memory Access (DMA), that is, devices which can read and write system memory without intervention by the CPU. Normally, this would be the most reliable and forensically sound method for capturing he contents of physical memory. However, AMD-V introduces a feature to secure the system memory against any unwanted access from DMA devices.
(emphasis added)

Two years ago during the rise of the public Windows kernel-mode rootkit, I wrote Rootkits Make NSM More Relevant Than Ever. Several years ago we passed the point where suspected compromised hosts could be trusted to accurately report their own integrity to tools running on the victim. HVM rootkits only sink the problem deeper into the platform.

If you're relying on a host to reliably report its security posture, you are bound to be disappointed. You have to complement that host-centric view with an outside view, like that depicted in my TaoSecurity Enterprise Trust Pyramid. Obviously a look at network traffic will not be 100% conclusive, but it will give you a trustworthy vantage point for very little investment of resources.


Anonymous said…
The last two paragraphs are equally applicable to kernel level rootkits.

Also HVM rootkits will never be a major problem in my humble opinion. They're very cool, but steps are already been taken to make them less of a threat (which was already at pretty much 0 level anyway, just a response to all the media hype). All the major OS's are bringing in their own hypervisor shims which would stop this type of rootkit.

Anyway, the kernel is too sweet a place to be living.

ALF said…
Hey!! because of your blogs popularity, we published your link on:

Blog Activities & Stuff.
James said…
Cool idea but Sophos anti rootkit removes all rootkits, it even removes unknown rootkits.

Popular posts from this blog

Five Reasons I Want China Running Its Own Software

Cybersecurity Domains Mind Map

A Brief History of the Internet in Northern Virginia