Detecting the Blue Pill Hypervisor rootkit is possible but not trivial

There has been much skepticism over the claim that Blue Pill (the first effective Hypervisor rootkit) is 100% undetectable and I myself was very skeptical of Blue Pill when I first read about it.  I had an extensive email conversation with Joanna Rutkowska (of Singapore-based COSEINC) weeks before her Black Hat presentation challenging the notion that Blue Pill was 100% undetectable.  Since I knew that any Hypervisor technology hardware or software based would have to have some overhead somewhere that could be detected by some form of timing analysis, I asked Rutkowska about this she opted not to go in to details before her talk at Black Hat.  Xen programmer Anthony Liguori has been one of the more vocal critics and even wrote an entire blog titled "The Myth of the Blue Pill".

As I went back and forth over this issue carefully examined the points raised by Liguori and Rutkowska and studied Blue Pill, it would seem that we are arguing over some simple semantics.  The claim that Blue Pill is "100% undetectable" should probably have been qualified with an additional phrase "through conventional means", but calling Blue Pill a myth is going way too far because there is no question that Blue Pill takes rootkits to a whole new level.

First of all, there are two levels of Blue Pill implementation defined by researcher Joanna Rutkowska.  Level 1 which is the current prototype doesn't attempt to hide the Blue Pill code residing in memory.  This would mean you could scan the computer's memory if you knew what to look for and had the signature of the specific rootkit.  But in targeted attacks, the signature of the rootkit would most likely not be known.  Blue Pill level 2 will go further and actually mask out the portion of memory where Blue Pill resides so that it is totally inaccessible to the victim operating system.

Level 2 won't be possible until something like the AMD-backed IOMMU standard or Intel VT-d I/O virtualization materializes sometime in 2007 or later and it will also require the support of nested paging.  Once the hardware permits the implementation of Blue Pill level 2, it will even make it difficult to detect a known rootkit signature because the hardware will restrict the OS from accessing the portion of memory that Blue Pill level 2 is residing in.  I asked Rutkowska about the I/O overhead such a scheme would incur and Rutkowska responded that there would be some initial overhead but it would be impractical for timing analysis detection.

One of the other possibilities of a software detector for Blue Pill raised by Rutkowska is the use of timing analysis where certain overhead intensive CPU tasks are measured to see if they get completed in the time that one would expect.  A system that has been Blue Pilled will take significantly longer for some CPU routines than one that hasn't.  The RDMSR command for example requires 23 times longer to operate on a Blue Pilled system than a clean system so this gives us a relatively easy way of manually detecting an anomaly with a stopwatch.  If we ran the RDMSR enough times that it would take 1 second to run on a typical computer, a Blue Pilled system would take approximately 23 seconds to run the same number of RDMSR commands.  But that requires manual user intervention and what's really needed is an automated software solution that will either say yes I'm Blue Pilled or I'm clean.

The problem with a software detector is that Blue Pill can easily adjust the clock to make it look like a task was completed just as quickly as it did when talking directly to the physical CPU instead of going through Blue Pill.  To counter this trick, an external time source such as an NTP (Network Time Protocol) server would have to be used to check if the clock had been shifted back to cheat the test, but even NTP replies can be tampered with by Blue Pill to make it look like there is no difference between the internal clock and an external clock.  The NTP servers would actually have to reply with encrypted packets that only the software detector can decrypt to make the system work.  So what we have is a software detection method but one that would only work with an encrypted external time source which is not something that's currently available to most enterprises.  This is precisely what I meant by saying that Blue Pill was undetectable by conventional Malware detection methods.

But an even scarier thought occurred to me and I asked Rutkowska if it would be possible for Blue Pill to go in to a temporary hibernation mode if it detects a timing analysis to detect Blue Pill and Rutkowska replied that this wouldn't be easy but would be very interesting.  This means that those slow RDMSR commands would no longer have to be slow and you won't be able to detect any measurable differences in performance and you'll think the system is clean.  But minutes later the Blue Pill rootkit will wake up and we would be back where we started.  If this feature could be implemented, it would make Blue Pill almost immune to timing analysis.

Rutkowska offered some advice to the CPU makers that they need to implement some kind of tamper proof command called SVMCHECK and a unique password for each CPU.  Then this password would make it impossible to make a generic Blue Pill rootkit that could cheat the SVMCHECK command [UPDATED 8/18/2006: kind of SVMCHECK command that will let an OS know if it's operating inside of a virtual machine or not.  Since we don't want malware running inside of the OS to be able to use the SVMCHECK command to check for the existence of a hypervisor-based antivirus package, the SVMCHECK command would have to be password protected.  This password would have to be entered in to the antivirus program for it to check on the existence of a Hypervisor.  The SVMCHECK command with no password or a wrong password will simply always yield a no answer for the existence of a Hypervisor.  If a DRM application asks the user for the SVMCHECK password, it would have no way of knowing if the right password was entered or not.]  Rutkowska said that unique password would have to be delivered via certificate with each new CPU though that would most likely be lost in my experience.  It would probably have to be something printed on plastic that's survivable and kept inside the case and/or printed outside the case for easy access to the consumer.  I'm not convinced that such a scheme would be scalable because it would require manual antivirus software installation and that simply isn't user friendly or practical for a large number of computers in an enterprise.

Rutkowska's advice to computer buyers was to turn off SVM if possible, but her own machine didn't have that option on the motherboard BIOS.  Her recommendation [with sarcasm] was to avoid buying SVM enabled CPUs which is all AMD AM2 desktop or revision F server socket based CPUs [UPDATE 8/18/2006 3:00 AM: Rutkowska noted that she said this in sarcasm to prod the vendors that they need to come up with a good fix].  Of course this has certainly not endeared her to the CPU makers and Intel is not eager to jump for joy because the same rootkit technique applies to Intel VT-x processors which apply to all the Pentium D and Core 1 and 2 line of processors.  Dino Dai Zovi had independently come up with an Intel-based VT-x rootkit and gave a presentation at the same Black Hat conference.  I'll personally continue to buy these newer processors, but I'll be keeping a close watch on the development of Hypervisor rootkits.