APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Virtualize or die?

www.eweek.com/article2/0,1895,1983037,00.asp (link dead, sorry) '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.

Got something to add? Send me email.


Increase ad revenue 50-250% with Ezoic

More Articles by

Find me on Google+

© Anthony Lawrence

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

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

Fri Jun 30 16:00:06 2006: 2199   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: 2486   TonyLawrence

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

Fri Sep 29 10:15:03 2006: 2491   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...

Kerio Connect Mailserver

Kerio Samepage

Kerio Control Firewall

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

If you just want to use the system, instead of hacking on its internals, you don't need source code. (Andrew S. Tanenbaum)

Don't blame me for the fact that competent programming, as I view it as an intellectual possibility, will be too difficult for "the average programmer" — you must not fall into the trap of rejecting a surgical technique because it is beyond the capabilities of the barber in his shop around the corner. (Edsger W. Dijkstra)

This post tagged: