Virtualize or die?

'Blue Pill' Prototype Creates 100% Undetectable Malware

There's a scary headline for you.

Well, first off this particular pill is only digestible by AMD machines. The author says the exploit isn't due to a bug or flaw; it's just taking advantage of how the AMD virtualization works. Basically it creates a hypervisor "on the fly" (no reboot). Your OS (and, yup, Vista is vulnerable) never knows what hit it: one minute it's running on real hardware and the next it's deep in a virtual machine. Sleep quietly little OS, Daddy is here..

Quick overview: an OS running in a hypervisor should be generally unaware that it is in fact being controlled by something else. A hypervisor could even mess with the bios if EFI is employed, and that means that even powering off and booting from a CD might not wrest control from the Puppet Master hypervisor. This is scary stuff.

However, generally doesn't mean absolutely. For one thing, the existence of the controlling machine means that it is stealing cpu cycles. While it may be able to hide that from a process running in a controlled OS, the loss of time can't be hidden from an outside observer - the hypervisor can't affect your wrist-watch. So while detecting this kind of infection might be more than annoyingly difficult, and eradicating it might move into hellish territory, this isn't HAL and we aren't Dave. Not quite yet, anyway.

Secondly, most hypervisors aren't built to nest: that is, if you are running a hypervisor already, it's probably not going to go to the trouble of letting another hypervisor run under it. The "blue pill" type exploit might make that effort (to remain invisible), but an "honest" VMM (virtual machine manager or hypervisor) is not likely to. If this type of subversion becomes a real threat, I'm quite sure that hypervisors will be explicitly designed to thwart any attempt to be replaced (which might make upgrades quite the tricky proposition, of course). That's the thought behind my title: the best protection against this sort of takeover may be to have a "good" hypervisor already running.

Is this our brave new world? Will the bios of the future have to be a hypervisor to protect the machine from other hypervisors? I think that's probably where we are headed: it makes sense for other reasons: simplification of OSes, easier protection from virii, and now this. Did I say "headed"? Heck, looks like Intel is halfway there already.

What does this mean for companies like VMware? Is it good news because their technology is most likely to be burned into the raw hardware, or bad news because maybe it kills them outright? Where is this all going? What do you think?

More at Introducing Blue Pill

A discussion of Can Operating Systems tell if they're running in a Virtual Machine? is also interesting.

Click here to add your comments




Fri Jun 30 14:45:07 2006: Subject:   BigDumbDinosaur


Repeat after me: New technology isn't always good technology...



Fri Jun 30 16:00:06 2006: Subject:   TonyLawrence


Maybe so, but I've said this before: Virtualization is coming like a big freight train. You can get on the train, just watch it go by, or get splattered all over the place by it.

I'm planning on riding :-)




Tue Sep 26 23:33:38 2006: Subject:   TonyLawrence


Tom Yager ( http://weblog.infoworld.com/yager/archives/2006/06/blue_pill_is_an.html ) says
this is a non-issue, nothing to worry about.



Fri Sep 29 10:15:03 2006: Subject:   drag


Tom Yager is wrong.

Not hugely wrong, it's not going to destroy the internet or anything. But it's something people need be aware of.

This is why we have this 'Trusted Computing' stuff. It's a way to create hardware calls (or whatever) that cannot be abstracted by a hypervisor. Software using this should be able to detect weither or not they are in a VM. (assuming that your system isn't rootkit'd to stop this detection) It should allow you to know if your system has been modified also.

It's all about the trusted keychain. The cpu boots, the bios boosts or whatever. The bootloader is checked with checksum. If that is fine, then the bootloader checks the kernel with a checksum, if that is fine then it loads the kernel. The kernel boots and checks important system files by checksum so on and so forth up till you get to your applications.

I don't understand all the details, but I know all of this is setup to prevent threats such as kernel-level root kits and rouge hypervisors.

For non-trusted system your just going to have to depend on software security and bar physical access. If the machine gets rooted, or you get infected by a virus or worm or whatever.. Then format and reinstall.

Nothing realy different then it is now...

Don't miss responses! Subscribe to Comments by RSS or by Email

Click here to add your comments

If you want a picture to show with your comment, go get a Gravatar

Take Control of Your Domain Names

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.