Story continued from Page 1
You talked about Vista and x86 hardware. What about MacOS X, Linux or (Open)Solaris? Can we blue-pill them?
Joanna Rutkowska: I have always stressed that Blue Pill is OS-independent and Vista is just an example. Any OS working on AMD processors that support hardware virtualization is vulnerable to this type of rootkits.
What is your opinion on the security of software virtualization solutions (VMWare, Xen, VirtualPC, ...)?
Joanna Rutkowska: Obviously the most intriguing question here is whether it is possible to escape from the VM and "get into" the hypervisors/VMM... So far nobody found an exploitable bug inside anyy VMM engine as far as I know. There were only some bugs in some additional mechanisms (e.g. network NAT modules).
However, I believe, that in the coming years we will see some exploits in this area, as virtualization will be getting more and more popular.
I would still risk saying that probably the isolation capabilities provided even by today's software based VMMs, are much stronger then those provided by current general purposes operating systems like Linux, Windows or BSD.
What is the so called Blue Chicken strategy?
Joanna Rutkowska: It's a funny feature that allows Blue Pill to defeat timing-based virtualization detectors, so they can't find out that they're inside a VM. Obviously we do not need Blue Chicken in case there is Virtual PC in the system or any other application that makes use of hardware virtualization already.
Do you plan to constantly update the Blue Chicken strategy to catch all the different timing attempts?
Joanna Rutkowska: I don't think we're planning to work further on "virtualization cheating". We most likely would be working further on supporting various nested virtualization scenarios, where there is no need for "virtualization cheating" and where all the virtualization detectors are pointless by definition. Our goal here is to convince people that generic virtualization detection approach is not the right way to detect virtualization based malware.
Why do you need to support nested virtualization?
Joanna Rutkowska: Nested virtualization is needed in case we have some other applications in the target system that also want to make use of virtualization (e.g. Virtual PC 2007) or we have a system with built-in hypervisor. In both cases Blue Pill must run those applications and/or OS' own hypervisor as nested ones.
Please note the distinction between "virtualization applications" and "OS's own hypervisor". While it's believed that the latter will be effective in preventing Blue Pill attacks (by blocking other hypervisor installations), the former do not prevent Blue Pill from loading. It's expected that we will have many virtualization based applications in the future on our desktops, but I don't think that Microsoft will come up with their own global hypervisor for desktop systems anytime soon (next couple of years).
If Blue Pill is more invisible by hiding in the kernel (using Blue Chicken), why do you need to use virtualization?
Joanna Rutkowska: Blue Chicken forces Blue Pill into a "sleep mode", so, even though for a few tens of milliseconds Blue Pill does live in the kernel, it's there in a "sleep mode", which means it doesn't hook anything. It just sleeps there (possibly encrypted) waiting for a DPC callback to wake it up and bring back into ring -1.
VirtualPC does not allow nested virtualization so if Blue Pill is the hypervisor and Virtual PC (or any guest OS) finds nesting is allowed, isn't this clear evidence of Blue Pill?
Joanna Rutkowska: "Nesting" is not a processor feature that you can enable or disable - "nesting" is the way we support running other hypervisors underneath our own - think of it as of an algorithm to support nested hypervisors.
Virtual PC's guest can't find out that "nesting is allowed", just because it doesn't see anything beyond its own hypervisors (the Virtual PC hypervisor).
It's theoretically possible that Virtual PC hypervisor could find out that "nesting" is taking place... to find out that it's running as a guest and some people might argue that all those techniques that were presented to detect virtualization (e.g. those presented by Tom Ptacek &co.) could be used here. This is not true however, as all those techniques try to detect that somebody is cheating that virtualization is not used, while it actually is being used. In case of nested Virtual PC hypervisor, we do not need to (we should not actually) cheat that virtualization is not used, as it expected that it's actually being in use. Thus we don't need to intercept EFER accesses nor we have to intercept CPUID, so all those virtualization detection methods do not work.
What might work here however, is if we could build some instructions into the Virtual PC hypervisor, that would be behaving differently, just because the hypervisor would be running as somebody's guest. The GIF setting/clearing problem we discussed during our presentation is a good example of this.
One might ask then, that maybe there will always be situations like this, which would mean that we would never be able to have 100% nested hypervisor support. Most likely this is true, but, unfortunately, this is not a proper way to fight the Blue Pill threat, as it requires building some tricky hacks into hypervisors code. But the principle rule for building hypervisors is... simplicity (e.g. for security reasons).
Also, we could expect that those tricky hacks built into hypervisors would have to be updated from time to time to support new processor models. So would we allow our beloved A/V programs to insert modules into hypervisors? That would be insane - we already witnessed many bugs in A/V kernel components, should we now allow them to do that with hypervisors?