Blue Pill Attacks

Are any QubesOS users here up to date with the status of “Blue Pill” hypervisor based attacks?

Has there been any mitigation put forward?

What does your current research tell you? Can you link to your findings, the documentation you’ve been reading, or at least a definition of a Blue Pill attack?

1 Like

The best papers I have seen thus far,

Describing the rootkit as a kernel module which loads a malicious hypervisor nested on top of another

This paper describes a mitigation based on integrity measurement at boot and during runtime using
a TPM (Trusted Platform Module):

My thought was to consider checking kernel modules to identify the malicious module, only the name of
the module is an unknown.

The other method would be using CPU cycles and potentially even fan noise, because the number of CPU cycles increases non-trivially when the system is “blue pilled” with this kernel module.

1 Like

Another interesting approach was to measure the assembly instruction set latencies and then compare the timing of running code with an external timer based on what the instruction set latency tables predict for the timing. If there is discrepancy between the latency table and the external timer, then there may be malicious assembly running.

that’s pretty much how AEM works.

Is this also the case when using Heads/Coreboot?

depends if they support all the necessary measuring infrastructure and initialization of the TPM components (Which TrenchBoot approach should do)

So Trenchboot would detect the insertion of an additional kernel module.

Wouldn’t the offending module(s) be not signed by the OS ?
Or could it fake modinfo output ?

in order to insert additional module the attacker would need to get control of the system first somehow.
Since your selected vector of choice is via earlier breaking of boot chain of trust, you don’t even need a module, can patch (or substitute) the kernel (or xen) binary before it’s even run.
That’s what the AEM / trenchboot and other systems that do measured boot protocols guard against.
What they don’t guard against is some external attack that happens post boot and penetrates the system deep enough to insert kernel modules or some such. But a properly implemented secure system should be able to return to clean state after reboot (or stop booting after noticing it’s compromised).
That said if an attacker is able to have full root access in dom0 in qubes, all bets are off pretty much because rootfs is not measured and could be changed at will


Coreboot and Trenchboot have similar measured boot techniques?

coreboot is just a bootloader of sorts, you can enable/disable all sorts of stuff when building it.
trenchboot is the framework to implement measured boot

The Blue Pill attack requires Intel vt-x and EPT (Extended Page Tables)

Does the Thinkpad X230 have EPT enabled by default (Extended Page Tables)?

Considering that Joanna originally designed and demonstrated Blue Pill, then subsequently designed and created Qubes OS with the ITL team in order to protect against Blue Pill and other security threats, would it be too cheeky to say that the mitigation is Qubes OS? :grin:

Well, there’s also this, but it’s not exactly new. :stuck_out_tongue:


This “red pill” script is supposed to run inside dom0? There is a link to a .exe for Windows but no .rpm or .tar for linux

Er, no. That post was from 2004, many years before Qubes existed.