A Bitter Pill

Since 2006, there’s been much debate about Blue Pill malware and the havoc it could wreak. But if we can’t detect it and there’s nothing we can do about it, is there really any point worrying about it?

This is your last chance. After this, there is no turning back. You take the blue pill – the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill – you stay in Wonderland and I show you how deep the rabbit-hole goes.” (The Matrix, 1999)

Many of you will remember “Blue Pill” malware from when it first came to prominence in 2006, and more recently – when the New Blue Pill (NBP) also got some significant attention. Every so often I’m truly surprised by the attention certain potential security attacks get, and how unrelated that attention is to the true nature of a threat. But in the case of Blue Pill malware, it is hardly surprising. The malware references one of the more popular film choices of computer geeks and sci-fi addicts, and the consequences of such an attack are potentially devastating.

This month, I want to address the Blue Pill, and look at what the broader implications are of this type of threat.

Doom and Gloom
Blue Pill malware was developed by Joanna Rutkowska in 2006, and at the time several newspaper articles predicted imminent doom and gloom for the computer industry. The malware was originally an attack against Windows Vista, but what interested many was less the target and more the nature of the malware itself. Blue Pill malware takes the form of a small hypervisor, similar in nature to VMware ESX or Microsoft Hyper-V.

Like those hypervisors, the malware takes advantage of the virtualisation capabilities built into the x86 chipset (specifically the AMD chip). But unlike a conventional hypervisor, this malware “inserts” itself below the existing operating system unknown to any person or any detection software. From that point on the operating system is unwittingly running virtualised, and the malware can perform nefarious activities theoretically without any fear of detection.

Various claims have been made about such a Blue Pill, including that it would be impossible to detect. Later that claim was revised to suggest it would be extremely difficult to detect. Recently, I’ve spent some time looking at publications, blog posts and articles surrounding Blue Pill, including one of Rutkowska’s more recent presentations on the NBP and its consequences (at http://tinyurl.com/4mkhzx).

On reflection, my view is that losing sleep over Blue Pill malware is a waste of time. There are a number of reasons for this – some related to the Blue Pill malware itself, and others to some general concepts of this type of threat.

Difficult to Detect
One of the main worries about Blue Pill is the claim that it is very difficult to detect. Whether that is true or not really depends on specifically what it is you are trying to detect. If you are attempting to answer the question “Is Blue Pill malware running on my system?”, then I would agree that detection is difficult. If, on the other hand, you are trying to detect a hypervisor running on a computer, that isn’t difficult at all. (You basically use an external time source.)

But the real question you need to be able to answer to address the problem is “Is an unauthorised hypervisor running on my system?” And that question is actually fairly easy too. “Normal” hypervisors should make no attempt to conceal themselves, so if you know you are running a hypervisor, and you know you shouldn’t be, or you cannot identify it, then you have an unauthorised hypervisor on your hands, and it’s time to deal with it.

The NBP supports “nesting” – you install a hypervisor on top of NBP (and that hypervisor can even be NBP). This does affect the ability to determine from your guest operating system that something unusual is going on. But no matter how much nesting you do, at some point you are at the lowest “legitimate” hypervisor, and from there it would be possible to check for unauthorised hypervisors.

The reality is that Blue Pill-type malware has never been used for any successful attack that we know of, and my opinion is that many of the more extravagant claims about Blue Pill are simply unfounded. But, just for a moment, let’s assume that they are not. What if this malware truly was undetectable, or even if it was extremely difficult to detect that you had undesirable malware on a system? (For example, if it would require an initial understanding that the malware existed, and then a dedicated, engineered solution, based on the specific characteristics of that malware.) What then?

Action Stations
The possibility is alarming. In the Blue Pill case, Rutkowska would argue that the malware takes advantage of a particular characteristic of the AMD chipset (and similar characteristics of the Intel chipset), namely hardware virtualisation technology. So a possible solution would be for AMD and Intel to remove this technology and resort to a more traditional chipset. But is this practical? Sure, it would deal with this specific problem, but if NBP represents a new type of threat, surely there must be other examples of “undetectable” malware, ones that do not require hardware virtualisation. And they may not be advertised at a Black Hat conference.

So the irony is that it probably doesn’t really change anything. We can be alarmed, but if undetectable malware does exist, there is essentially nothing you can do about it, and so nothing to do to prepare for it. Even extremely difficult to detect malware, such as the type I’ve already described, can only really be dealt with at the time it is discovered.

What I am certainly prepared to concede is that this whole discussion should make us think further about the nature of malware detection, and whether current approaches to tackling the problem of malware are sufficient. I think it is very likely that the next few years will bring significant changes in the way malware is handled in the future, both in terms of the technology used to detect and combat it, and where that technology is implemented. This change will likely be related to an increasing trend to embed virtualisation in the hardware, and the likelihood that the vast majority of both server and desktop workloads will run virtualised.

Fact and Faith
Many will disagree with my analysis, and one of the most interesting parts of the whole Blue Pill controversy is that if you read the blogs, you will see that much of that disagreement is based on something other than fact. I believe it stems from two main characteristics of Blue Pill malware: one, that Blue Pill is difficult to understand; and two, that the consequences of a successful Blue Pill attack are truly scary. In cases where a lack of understanding and a fear combine, then logical argument and scientific debate frequently take a back seat to belief and faith. As an analogy, think of the number of people who do or do not “believe” in global climate change.

So, are there concrete lessons that can be learned here? I believe so. Security planners need to constantly remind themselves that humans are naturally biased towards devoting resources to preventing low-risk threats with a potentially high impact, particularly if they have been exposed to the potential consequences. Think how much we spend preventing another 9/11 type attack versus lowering the number of preventable deaths from cancer. Using a statistically based risk analysis procedure should help combat this problem.

Secondly, even if (or perhaps especially if) a threat is very difficult to understand, it is essential to get a good high-level and accurate assessment of the risk it poses and precisely what is at risk. Many of the questions I have received about Blue Pill have come from the assumption that somehow this malware reduces the security of virtualisation. The nature of the malware itself (a hypervisor) has led people to believe that hypervisors are inherently insecure. But just because the malware uses a form of virtualisation, you can’t assume anything explicit about the security of virtualisation itself. Indeed, you could argue (and interestingly Rutkowska herself does argue) that modern hypervisors such as VMware ESX and Hyper-V actually reduce the risk of this kind of attack. Certainly, not virtualising in your environment does nothing to mitigate any risk.

Finally, even if the risk is there, it is only useful to plan for events that you can in some way affect or respond to. The sun could fail to come up tomorrow, but nothing I could do today would change that outcome. And if the sun stops shining, I won’t be around much longer anyway, so there’s not much point my worrying.