Lab rats at Microsoft Research and the University of Michigan have teamed up to create prototypes for virtual machine-based rootkits that significantly push the envelope for hiding malware and that can maintain control of a target operating system. The proof-of-concept rootkit, called SubVirt, exploits known security flaws and drops a VMM (virtual machine monitor) underneath a Windows or Linux installation. Once the target operating system is hoisted into a virtual machine, the rootkit becomes impossible to detect because its state cannot be accessed by security software running in the target system.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-07-06
> "VMM" is something on which a virtual machine runs;
> "hypervisor" is something which runs underneath an OS
> and performs functions that the OS is not sufficiently
> privilaged to execute. The two are independent, though
> quite often occur at the same time. (Xen likes to
> confuse the two terms, I believe for marketing
> reasons.) The research paper is about turning a VMM
> into a hypervisor
I wouldn't say they were independent, I'd say "hypervisor" is a subset of "VMM". All environments that enable an OS to run within a container are VMMs, not all of them are hypervisors. But hypervisors by definition allow an OSS to run within a container, and hence are VMMs.
I'm leaving language virtual machines out of the picture, since I've always seen them described as "the virtual machine", not a VMM: AFAICT they are fairly separate uses of the term that happen to include some common characteristics.
I seem to recall there's some hack to find out if you're running in a VMM on x86 hardware anyhow... It exploits the existing difficulties in virtualising x86. With hardware support (VT / SVM), this kind of test can be fooled, since it enables proper full virtualisation of x86. But this can be disabled (at least at BIOS level, I think) in order to prevent it being a problem.
I've just read through the research paper myself and I was slightly surprised at the approach they took. I'd have expected something more like the approach I proposed would be a lot more practical, and could be activated at runtime, rather than having to subvert the reboot path... Also, it could be used to support more conventional malware running within the OS itself. I'm not sure that'll represent the most expedient (and therefore likely) direction for malware authors (vs more conventional attacks on anti-malware) but it seems like it's a more likely direction than a heavyweight virtual machine technology as discussed in the paper.
I have something of an inclination to try to implement a proof of concept of what I proposed, except that I don't think I have time left from the work I'm meant to be doing! I'll have to list it on my homepage, maybe someone else will want a little research project.
Member since:2006-01-21
> I wouldn't say they were independent, I'd say "hypervisor" is a subset of "VMM".
> All environments that enable an OS to run within a container are VMMs, not all of them are hypervisors.
> But hypervisors by definition allow an OSS to run within a container, and hence are VMMs.
IBM and Sun have had non-VMM hypervisors for quite a while on big iron. Used for partitioning (e.g. 4 CPUs to partition 1, 8 CPUs to partition 2, etc.), but they aren't VMMs because they perform no virtualization - there is no abstraction involved, just partitioning and administration of the machine (e.g. turn off machine).
The VMM detection hack is, if I recall correctly, the load global IDT instruction (I forget the mnemonic); it must always point to a physical address so it escapes the virtualization of memory. VT avoids this particular flaw (at least, in VT mode). Ring-3 has no practical reason to need that instruction, but it IS in the architecture, so no CPU will trap it (except VT).
But that's only the easiest hack. The timing ones are most effective: measure time. Perform a bunch of ring-0 operations (randomly generated, if possible, to defeat optimizations - from a user program, this means force the OS to perform ring-0 operations). Measure time again. If it was fast, real hardware; if slow, virtualized. Make the time measurement against a remote host over a secret protocol, and it's impossible to defeat.
Anyway, I believe the paper is fundamentally flawed because the authors think a lightweight VMM hypervisor is easy. It isn't, not on generic hardware (that is, not on hardware most of us have. It is only possible on hardware that you know about ahead of time, or when the VMM trusts the virtualized OS to use unknown hardware safely, like Xen's dom0). Which tells me they don't really understand virtualization.
Member since:
2006-01-21
> I'm using the terms "VMM" and "hypervisor" fairly interchangeably here.
"VMM" is something on which a virtual machine runs; "hypervisor" is something which runs underneath an OS and performs functions that the OS is not sufficiently privilaged to execute. The two are independent, though quite often occur at the same time. (Xen likes to confuse the two terms, I believe for marketing reasons.) The research paper is about turning a VMM into a hypervisor.
Agreed that once running on a VMM, it's impossible to hijack again using this mechanism (at least, with current VMMs - VMware, Xen, VirtualPC, etc.). Why? Because it's easy to find out if you are running in a VMM.
How to virtualize a computer:
Step 1: Virtualize instructions. This means virtualizing interrupts, faults, exceptions, and all privilaged instructions. As you point out, the memory is still present, so...
Step 2: Virtualize memory. Works fine within the CPU, but non-CPU hardware breaks. (e.g. DMA, if you say "transfer memory to location X", the location written to registers differs from the virtualized location... btw, this is what VT-d and Pacifica correct for, finally).
Step 3: Virtualize all I/O, perform the I/O under controlled conditions where memory accesses are translated. Requires knowledge of actual hardware (i.e. device driver per device), cripplingly slow hardware (no AGP, no DMA), or use virtualized device (i.e. hardware change).
--- state of the art stops here ---
Step 4: Virtualize time. Best way to detect if you are running on a VMM is a timing attack. VMM cannot hide all sources of time from you (think network traffic); at this point, a VMM can only hide itself from a totally useless computer.
In short, this paper makes a great deal of noise about VMM-based rootkits, but it's all FUD. You cannot hide a VMM - not with any modern technology. And the authors expend a great number of words starting from this flawed premise. Their VMM rootkit is not undetectable, and in fact a real rootkit on a real OS is far less detectable than a VMM rootkit.