Taking The BluePill
Alan: The "kernel-level" rootkit is the one that gets all of the attention in the mainstream press. In this situation, the operating system kernel itself is compromised. Since there is nothing with a higher level of access, there's no ability to "look down" and search for the virus. That is, with a kernel root kit, when an anti-virus wanted to scan "infected.file," I could substitute a "clean.file" instead without anyone knowing.
Joanna: Right, the advantage of kernel-level rootkits over user-mode rootkits became pronounced after the various anti-virus products started to rely on kernel-mode agents to perform, for example, filesystem scans.
Having the two opponents (a rootkit and an A/V) operating at the same privilege level (ring 0) doesn't mean that either of the two is a clear winner in the long term. In fact, in the long term there is always a draw. It’s that malware usually wins in the short-term, and this is pretty bad because, for malware, it is just enough to survive a few weeks (or days maybe even) to do its job.
Alan: The kernel rootkit was thought to be the exploit with potentially complete stealth and limitless damage potential...
Joanna: No, it has never been. Since the early days of kernel-mode rootkits, even the original on Linux/*BSD back in the 90's, people have been coming up with various kernel-mode detectors for known types of rootkits or rootkit hooking.
Alan: Hold on, chicken and egg. When you have a kernel rootkit, it’s like the DOS era again. You could come up with the slickest kernel-mode detectors for detecting other kernel rootkits, but if I had a slick kernel rootkit, my version n+1 could detect your detector and then thwart that. That’s in contrast to a perfectly designed operating system where I’m the bad guy forced to operate in user-mode, and you’re the security guard operating in the kernel. You’d always have the upper hand and the only way to sneak around you is a bug in the software that lets me get into Ring 0.
Joanna: Yes.
Alan: So the whole point of all the last 10 minutes was to emphasize the idea that it’s all about being one privilege level “more secure” than your opponent. For the sake of nomenclature, the smaller the number, the more access. So let’s talk about "Ring -1" exploits and your “blue pill."
Joanna: Ring -1 is an informal name, coined when AMD and Intel introduced hardware-based CPU virtualization (AMD-v and VT-x) some three years ago. Those new technologies introduced a new operating mode, which is called the "root mode" or "host," depending on which vendor spec you read. This has been informally called "Ring -1" to stress the fact that the hypervisor has more privileges then the OS kernel that was usually in Ring 0.
I wrote BluePill in 2006 to demonstrated how this hardware virtualization technology can be abused by malware to create a stealthy hypervisor and move, on the fly, the running OS into a virtual machine, controlled by this stealthy hypervisor.
Suppose we had a system integrity scanner, something that would be able to monitor all of the kernel code, data structures, and function pointers to see if any of them have been hooked. Even such an ideal scanner would be unable to detect BluePill-like malware. This is because, unlike all the previous kernel-mode rootkits, BluePill doesn't hook anything in the kernel code or data. It just sits above the kernel, and doesn't need to modify it in any way.
Another unique feature of BluePill, which has made it truly one of its kind, is its support for nested virtualization--one can load BluePill, and then, inside the virtual machine created by BluePill, start a normal hypervisor like Xen or Virtual PC (that itself makes use of VT-x/AMD-v). You can even load several instances of BluePills inside each other. I'm actually quite proud of this nested virtualization support!
Many people tried to prove that BluePill is "detectable" by writing various virtualization detectors (but not BluePill detectors). They simply assumed that if we detect a virtualization being used, this means that we are “under” BluePill.
This assumption was made because there were no products using hardware virtualization a few years ago. Needless to say, if we followed this way of reasoning, we might similarly say that if an executable makes network connections, then it must surely be a botnet.
Alan:Let’s clarify then. If I’m legitimately running inside a virtual machine and I have access to all of the tools that are out there, you’re saying that I can’t tell if the virtual machine manager (or hypervisor) has been compromised by BluePill? I can use the virtualization detector, but I already know I’m supposed to be virtualized!
Joanna: Yes, detecting virtualization versus detecting if your (legitimate) hypervisor has been itself bluepilled are two different things.
Alan: So the only reason the virtualization detection strategies work is that, in my host/root operating system, I shouldn’t be in a virtual machine and if I am, something’s fishy?
Joanna: Theoretically, you can try to do time profiling of certain instructions in order to measure if, or how many, additional "layers" of nested hypervisors are above your legitimate one. We showed that at Black Hat last year when talking about bluepilling the Xen hypervisor. But that's a very tricky approach, which is very sensitive to the actual implementation of the hypervisor that sits directly above us (the legitimate one)--we need to perfectly know its timing characteristics to be able to "extract signal from the noise." I think such an approach to solve the problem of Bluepill-like malware, although well suited for an academic paper (lots of charts!), is a blind avenue. To make it clear though, I don't believe we will see BluePill-like malware in the wild anytime soon because the currently-used, good old kernel-mode malware seems to work just fine. The anti-virus industry sucks at even detecting and preventing against this kind of threat. So, there is little incentive for the organized crime to migrate towards a much more complex technology. Of course, we security researchers should not wait, and start thinking now about how to make sure such malware will never get into the wild. One solution is Intel TXT (Ed.: that's Trusted Execution, for those of you who don't know) technology, that we, however, bypassed a few months ago at Black Hat DC earlier in February.
