Enabling virutalization, addressing the bluepill risk?

Question

Background to this question is the ambivalence I assume with virtualization. Also to start directly with clarity: the term bluepill should here be a placeholder to denote "malware that uses virtualization to hide and fixate itself on an attacked system".

My question is how I should deal with the risk of a bluepill when enabling virtualization on my computer? And more specific if there is a way to enable hardware supported virtualization Intels x86/i64 CPU's vt-x feature that would yet protect me from bluepill attacks? To counter/address the risk that there might not be a 100% definite answer, I would consider it a big step forward (and an accepted anser) the enumeration of a set fact based "best practice rules to enable vt-x and to prevent bluepill-type malware".

This could include i.e. a suggestion for a way to check for a bluepill infection? (i.e. using that during shutdowns/reboots bluepill would need to store/conserve itself and hece become detectable on the harddisc)

The motivation to the question is: On my system Intel iCore processor's the vt-x cpu feature can be enabled and disabled in the kernel.

• disabled: bluepill attack impracticable, but no virtualization based security benefits
• enabled: bluepill attack possible, but virtualization based security benefits enabled.

I have gone through "The How secure are virtual machines really? False sense of security?" which has not given no consideration to the bluepill aspect yet. Therefore I think this question can enrich the topic of virtualization-security.

Answer 1

There are two aspects to bluepill: how the infection happens and whether you can detect it once it happened.

The first aspect is the same as for all malware really. The novelty aspect of bluepill was the "it's undetectable" claim.

There was extensive research on that, and several methods have been devised for detection.

You should note that, as of yet, there were no bluepill threats seen on the wild.

Detecting if the OS is running inside a VM

The first published methods for detection involved timing. From an interview with Anthony Liguori:

Hardware virtualization requires a technique know as “trap and emulation”. The idea is that the hardware traps certain instructions and the VMM emulates those instructions in such a way as to make the software believe it is running in a virtual machine.

Software emulation implies that these instructions take much longer to complete when executed under a VMM then on normal hardware. This fact is what can be used to detect the presence of a VMM.

I approached Rutkowska about this and she attempted to address it in her prototype by adjusting one of the processors clocks on every exit. However, there is nothing that she can due about external time sources and she’s admitted to this on her blog.

She refers to this as a theoritical weakness in her system but I assure you that it is quite practical to exploit.

The original author of the bluepill concept (Joanna Rutkowska) also published another paper (RedPill) which might be leveraged to detect a BluePill rootkit.

I couldn't find the paper, but found this excellent summary:

 int swallow_redpill () {
   unsigned char m[2+4], rpill[] = "\x0f\x01\x0d\x00\x00\x00\x00\xc3";
   *((unsigned*)&rpill[3]) = (unsigned)m;
   ((void(*)())&rpill)();
   return (m[5]>0xd0) ? 1 : 0;
 }

The heart of this code is actually the SIDT instruction (encoded as 0F010D[addr]), which stores the contents of the interrupt descriptor table register (IDTR) in the destination operand, which is actually a memory location. What is special and interesting about SIDT instruction is that, it can be executed in non privileged mode (ring3) but it returns the contents of the sensitive register, used internally by operating system.

Because there is only one IDTR register, but there are at least two OS running concurrently (i.e. the host and the guest OS), VMM needs to relocate the guest's IDTR in a safe place, so that it will not conflict with a host's one. Unfortunately, VMM cannot know if (and when) the process running in guest OS executes SIDT instruction, since it is not privileged (and it doesn't generate exception). Thus the process gets the relocated address of IDT table. It was observed that on VMWare, the relocated address of IDT is at address 0xffXXXXXX, whereas on Virtual PC it is 0xe8XXXXXX. This was tested on VMWare Workstation 4 and Virtual PC 2004, both running on Windows XP host OS.

Another method is reviewed in this article is from 2008:

The idea is to intercept a hypervisor's start by another hypervisor (let’s call the latter a Virtual Intrusion Prevention System, or VIPS). When any hypervisor (malicious or legitimate) starts, it turns VM root mode on. This event can be easily intercepted by a VIPS. So what's next? There are 2 ways to handle this event: blocking a hypervisor completely, or allowing it to work through emulation.

The first way consists in emulating a PC with disabled HVT feature in BIOS. This will block a HVT rootkit from working.

The second way consists in allowing a hypervisor to work through emulated hardware virtualization (or nesting). This should be done for legitimate virtualization software.

In both cases (blocking or emulating), a VIPS intercepts a hypervisor at the moment it tries to start. VIPS can read the hypervisor’s body and analyze it. A notification message can be shown.

Is this really a threat

Then there's the practical aspects of the attack to consider.

A bluepill rootkit needs to implement xen or something similarly complex, which is a huge endeavor. Since there really is no guarantee it won't be detected or blocked anyway, attackers will choose an easier path which is classical rootkits.

I believe this is part of the reason why bluepill rootkits haven't been seen on the wild.