Slashdot Mirror
Blue Pill Myth Debunked
njyoder writes "As previously posted about, Joanna Rutkowska claimed to have discovered an allegedly undetectable vulnerability in Vista that takes advantage of AMD cpu's virtualization capabilities. a virtualization professional (Anthony Liguori of the Xen project) has now voiced his opinion to state this is bunkum.
There are two parts two this — the ability to take over the machine and seamlessly drop the OS into a VM (which is very difficult, but possible) and the ability to have windows run in the VM undetectably (which is impossible). In fact, Rutkowska's prototype is VERY detectable.
This is unfortunate mistake that people make when they jump to conclusions based on what is unfounded speculation and that includes the assumption that this would somehow be Vista specific, if it worked (noting that Vista doesn't run with administrator privileges by default)."
I would probably take heart to this if a hardware (or firmware) engineer spoke up and noted that this is a possibity. Are processors now offering virtualizaton in-chip?
I'm not so sure Anthony Liguori is right.
t ml more detail at http://static.ephemeralsecurity.com/mosvm/Mosref%2 0Howto.html and the continual move toward VM
Most people in the security community are well aware of http://www.ephemeralsecurity.com/mosref demo at http://static.ephemeralsecurity.com/mosvm/demo1.h
If mosquito and similar tools are not moving towards VMMs, I'd be very suprised. After all, it is a logical step (From VM as a payload, to a VMM as a payload).
Which is why malware's going to do this on Windows XP, then lie dormant until it detects Vista installed.
At least with Beta 2 Vista did run with admin privledges, just as all previous versions of Windows. But you have that box that pops up when ever you use those privledges. MS has done a good PR campaign to make people think it doesn't, but install beta 2 for yourself, the user created in setup is an admin just like in XP. I sincerely hope that this is changed with RC1.
-- "Freedom is the right of all sentient beings" -Optimus Prime
Though there is a littlee war the authors neglect to mention. If I am writing a blue pill virus vm, and I KNOW there is software out there that is trying to detect me, it's completely worthless. Since I own the machine at that point, I can modify the programs running, with impunity. That's like all the viruses that are out there right now that are more or less immune to Norton... they know what the "threat" is, and they plan accordingly, they know its weaknesses and simply sidestep right around it.
A vm that sees you load BluePillDetect.exe just goes in and twiddles a few bits here and there in the app before it actually puts it in the execute queue, or subtly mucks with its registers while it's executing. Now the program blissfully reports just what the VM wants it to report... "no VM detected.".
Now how are you going to get around THAT? If you are running on a totally owned system, you cannot tell me there is anything you can do that is guaranteed to work, especiially if you are using a commonly available tool that the vm author had access to..
You simply cannot win at their game if they are the ones writing the rules. You can claim victory for a day or two, until the VM authors get their hands on your tool and make the necessary modifications to their VM to cripple your tool, and then you are back to the drawing board.
I work for the Department of Redundancy Department.
With Open source there's no problem. I can hear about a thing, test it, look at code, and decide whether it's an issue to me. Or if it's outside of my abilities, That wonderful peer review process can do the job for me. People who are being paid to say good things soon fall silent or get drowned out in the face of proof to the contrary from many sources who are not being paid, but do it out of interest.
With closed source code of any type I have no such option. Instead all I get is 'experts' to tell me. But these guys have to eat, so they get paid by someone, and have a vested interest in being paid tomorrow. Therefore there can be no impartial advice.
Heck, if the cheif engineer on the shuttle program can be convinced to retract his refusal to sign off the shuttle because of O-ring problems, what hope is there for trustworthy answer from anyone regarding closed source software?
Ok, possibly I'm being too extreme with my example, but seriously I worry about the *true* safety of using an operating system which has not, in fact, been designed with consumers in mind. It is, by microsofts own cheerful admission, purposely built to help 'rights holders' of stuff you use keep you from deviating from their precious business plan.
Perhaps this is fair enough, but there should be a trade off. I see no evidence that the rights of the OS purchaser are being properly considered. Even XP assumes you are a pirate unless proven otherwise. That reveals a lot about their views of the lowly home consumer.
This is hardware virtualization we're talking about, not software. The processor manufacturers have built virtualization calls into their chipsets.
:-)
They've added extensions to facilitate trap-and-emulate virtualization.
The side-effect of this is that the hypervisor can simply tell the bios "I'm the hypervisor...but, only call me when these specific requests are made."
VT/SVM have absolutely nothing to do with the BIOS. Instead, they both introduce a new processor mode that can be entered at any point that allow certain operations to be trapped. These operations are more or less the set of classic x86-sensitive instructions.
So, the hypervisor could simply choose to ignore the sound and video hardware, leaving those as fast as they were before.
Yup. But we're not talking about hardware here. Keep in mind, that if you do allow direct access to hardware, one now has a channel to access all of memory which could be used to detect a virus in RAM. Let's ignore that for now though
The only way to tell the hypervisor is there is to find a CPU call that the hypervisor *does* care about, and compare how long it takes to run that command before & after the rootkit pushes the OS to a guest OS.
Yup, and as I pointed out to Joanna, there are a number of CPU operations that one would *have* to trap. Things like %cr3 moves, msr reads/writes, etc. Otherwise, one can just search memory for a signature. BTW, how does she hide the memory of the VMM from the guest? I didn't address this because there are some potential solutions (like memory hotplug) but this, in practice, would be a very hard problem to solve. You can just take away memory from an Operating System and expect things to function normally.
Why do you think she addressed this in her talk? I brought it up to her before she presented...
Anyway, you have to take a trap at some point. There are only a small number of possible instructions that trap. A very thorough "detector" could simply check the timing of every trapable instruction.
If she's not trapping any instructions, then the monitor is never getting run so is it really a monitor anymore?
BTW, on VT at least, the VMM doesn't get a choice for certain instructions. They always trap no matter what.