Check out this eWeek article about VM Rootkits. It's incredibly scary. Using an ordinary vulnerability to gain access to your system, an attacker installs a virtual machine monitor. The next time you reboot your machine, the VMM loads silently as the native OS, and then it loads your regular OS as a virtual machine. The VMM can go about doing anything else it wants, and your regular OS has no possibility of detecting it. It's totally invisible because the VMM has complete control of everything your OS can see. The only practical protection against this concept is what the article mentions near the end:
A secure VMM can also be used to gain control of a system before the operating system boots. It can also be used to retain control as the system runs and to add a check to stop a VM-based rootkit from modifying the boot sequence.
So, it seems to me that we're all going to be running Virtual PC, VMWare, or some other VM monitor pretty soon, not because we want to, but because we need to in order to be secure. And then the bad guys will start looking for double vulnerabilities: ways to break into our OS and then break into our supposedly secure VM monitors.
1. Philip Storry03/11/2006 03:39:46 AM
I disagree with your conclusion - and theirs.
This whole article seems to be a sly "justification" for intergarted solutions like Trusted Computing (http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html - slightly outdated, but good stuff).
They seem to be trying to scare us with an unlikely bogeyman that could easily be detected by much simpler means than stupid VMs or hardware integration of Trusted Computing.
Sure, trojans and bots are all over the place. But the effort to build such a VM trojan would be quite high - remember, this thing needs to be industrial strength code. Errors will kill the OS running on top with kernel-level panics, and that will result in an install CD being pulled out and your rootkit going bye-bye. So doing this successfully is no trivial effort - whereas writing a VB/C program that stealths itself is something that there are already coding kits for.
But, for a laugh, let's assume that the bad guys write coding kits for VMs as well. What's the best solution?
Not as "Security VM", because as you've already noted they'll just look for vulnerabilities in that. It's a silly escalation issue...
Hardware integration of security - the Trusted Computing/DRM solution - would b e effective. But it would also likely generate bad press and face consumer resistance. And its strength is likely to be tampered by its inflexibility - when a vulnerability is found, hardware upgrades may be required. Do you really want to have to upgrade your CPU or motherboard just to avoid a rootkit?
A USB key and a bootable CD are the best solution. Run your AV program, and tell it you want an offline rootkit detect (or whatever it calls it).
It downloads updates, scans the machine, and writes a snapshot (and the updated engine/signatures) to the USB key. You shutdown, boot from the CD, and read the updated signatures and the logs/snapshot from the USB key. Verify their integrity, re-scan, and look for differences.
If there are any significant differences, then they must have been down to rootkit VMs hiding files.
The only weak spot in the CD/USB key combination (which could be reduced to just a USB key, but shouldn't - the CD is inviolable, whereas the USB key isn't) is that the logfiles/updates could be intercepted by a VM and interfered with. This can be gotten around, though. For instance, updates could be sent as emails, with unique filenames - instructions being presented in the email on how to copy the file and re-enter the filename when you've rebooted. The snapshot logs could be protected by asking the user for a unique name, rather than using a predictable one. Similarly, public key encryption could be used to exchange hash salts securely with an update infrastructure, ensuring that the hashes on the updates and snapshot file are unique to that user, and making it much harder for a VM to interfere with them as they are written to the USB key.
These are basic security techniques that will make life much harder for a VM trojan or a normal trojan. They're available now, they don't require anything to be upgraded except your antivirus, and they're not very intrusive.
This isn't insurmountable. It isn't even something that Microsoft should be wasting time on right now. Frankly, Network Associates/Symantec should be dealing with this. As it is, my faith in them has been sufficiently eroded that I expect nothing from them, and we'll probably see the first offline rootkit detector from a lively, nimble Eastern European company instead. :(
(Whoops. Ran long. I should probably turn this into a blog entry, adding in some more thoughts on Trusted Computing and VM solutions, but it'll have to wait I'm afraid...)
2. Chris Linfoot03/11/2006 04:45:57 AM
1. I agree with Philip - storm in a teacup, Chicken Little (Licken) and so on and so forth.
2. Microsoft itself has researched this and published the concept. This would appear to be somewhat counter to their normal stance regarding responsible disclosure
3. Richard Schwartz03/11/2006 10:54:44 AM
@1, Philip: You're talking about detection after infection. That's fine. It works as you describe. A secure VMM under the operating system is the only IMHO practical defense against infection in the first place, and the only practical solution for machines that rarely reboot but must reboot unattended. E.g., for servers.
Yes, developing attacks that install a trojan VMM will be difficult -- but the research shows it isn't impossible, and there are open source VMM projects that bad guys can draw on to get good quality code as the basis for their work. Yes, this leads to an escalation, but I see little choice.
@2, Chris: I would take it as a good sign if MS's stance on responsible disclosure is changing.
In any case, I'll be interested in seeing what, if anything, Bruce Schneier thinks of this one.
4. Alan Bell03/12/2006 04:12:52 AM
How would your secure VMM hypervisor know that it is running on the real hardware rather than in an environment hosted by another evil hypervisor?