The Blue Pill
Saturday, July 01, 2006
If you thought about Viagra, then by the time you complete reading this sentence you’ll have read enough of this post :)
The Blue Pill is a proof of concept malware developed by Joanna Rutkowska (Blog Link), a researcher at COSEINC. This malware is claimed to have the ability to bypass the OS layer and not only deal directly with hardware and be invisible to the OS, but emulate hardware for the operating system. By acquiring this level, the malware becomes completely undetectable and almost unstoppable. The installation is asserted to be in real-time, without a re-boot! Joanna says the malware does that using legitimate methods, and does not make use of any security exploits.
Quote from Joanna’s Post (Link):
The idea behind Blue Pill is simple: your operating system swallows the Blue Pill and it awakes inside the Matrix controlled by the ultra thin Blue Pill hypervisor. This all happens on-the-fly (i.e. without restarting the system) and there is no performance penalty and all the devices, like graphics card, are fully accessible to the operating system, which is now executing inside virtual machine. This is all possible thanks to the latest virtualization technology from AMD called SVM/Pacifica.
I went through this times and times but I still don’t get it! Something there doesn’t make sense :S
Last year I was trying to interface simple circuit boards to my computer through the parallel port (Post Link). I researched a bit and came across two basic IO functions in C++, which are _inp and _outp. These functions are direct implementations of the assembly instructions IN and OUT and are used to send and retrieve bytes of data from and to any port address.
One of the restrictions on the _inp and _outp functions (due to restrictions on the IN and OUT instructions themselves) is that they do not run under Windows XP (Windows NT generally). This is because Windows XP implements a protection scheme that prevents direct interfacing with the IO ports. The idea wasn’t quiet new for me; I already knew that Windows XP emulates almost every aspect of the hardware, and that every single driver (even the processor driver) is nothing but emulation. That is, applications can’t at any time deal with the hardware directly; data must always pass through the OS layer. This Emulation concept is adopted by many operating systems and even some programs. It has great advantages, to name few: security, performance, optimization... etc
The thing that I did NOT get that time was a 3rd party library named Inpout32 which had a solution to the Windows XP problem with the IO ports, check this out:
http://www.logix4u.net/inpout32.htm
This library provides two functions Inp32 and Outp32 that work exactly as _inp and _outp except that they DO WORK under Windows XP?!?!
Reading the How Inpout32.dll Works page really changed many of the thoughts I had about Windows architecture. I didn’t know there is such a thing as a “Kernel-Level” driver. The word “Kernel-Level” itself didn’t make sense to me! Since when did Kernel – the core of the operating system- had a level that can be attained by applications? And why would the operating system allow this to happen in this first place?
The thing that the Inpout32.dll library does is just a tiny portion of what the Blue Pill is claimed to do. The Inpout32.dll library bypasses the IO port restriction by loading some code at the same hardware-software layer the OS executes in. The Blue Pill, on the other hand, loads itself “lower” than the operating system, i.e. it’s closer to hardware than the OS itself!
The question is: how come such an execution is legitimately possible? Why would the operating system allow a program to take control over it? If this is really possible then it’s like saying that the OS enforces hardware security but made available a key to bypass it! What’s the use of implementing security in the first place then?
In matrix terms, it’s like saying that the programmers of the matrix provided a key inside the matrix that can put the matrix as a whole into simulation … why would they do that?
Waiting to hear more on the Blue Pill thing, but till then …
"I don't believe it. It's not possible!"
12 Response(s) to "The Blue Pill"
Devil's Mind said:
All drivers run at kernel-level! The real question is, why do operating systems allow drivers to install without even a user permission, at least "unsigned driver" dialog needs to pop up!!
Black [X] Truder said:
I didn’t mean a “Hardware Driver”! That library remains a Dynamic Link Library (DLL) afterall and is called by user-level applications, so it must run in user-level. How come the calling application runs in user-level and the library executes in Kernel-level? doesn't make sense!
Anyway, as I said the library thing is a tiny example compared to the unexplained access provided by the operating system to the Blue Pill. The big question of this post: How does the operating system allow the Blue Pill to install and run below it?
Lubna said:
lsn,, we'll set a date for you to teach me this lecture "post" :P:P:P
ma3en said:
so...... this post turned out to be talkin about viagra or not????
Emad said:
Hmmmm, i think i will agree with ma3en :), cause I really didn't understand a word from that crap except "Viagra", so i guess it was talking about that! :P
Ba3dain ya ghaith, what happened to the nature and animal lover, where did the passion go? b3raf ra7 akol atleh bokra :D
Black [X] Truder said:
Sorry Ma3en and Lubna, I know I should've put a "Geek Only" warning sign on top of this post :P
Emad, bokra bil jam3a bawarjeek meen el nature and animal lover :@
Qwaider قويدر said:
Alright, to answer your question why would the Operating system allow something like this to be executed . The answer is quite simple
The Operating system doesn't even know that it's not able to access the hardware directly. It's under the illusion that it's directly communicating with the hardware. When in fact it's communicating with a shim. A think layer that is emulating the hardware and virtually and selectively passes the control to the physical hardware
You can see a good example of this in products being shipped today. One is softwindows (emulating windows on Unix and Linux machines) and the second is in VirtualPC. VMWare and the likes. Where you're actually running an operating system within an operating system. The second one doesn't even know that it's being run in a controlled environment.
The relation between it and the matrix is that If you're in the matrix, which is making you feel, smell, taste and experience everything as if it's real. If no one tells you, you would never be able to figure it out on your own.
The concept is not new. But using it for malware is the new twist.
I hope this explains it, let me know if you need more details
Black [X] Truder said:
Qwaider you misunderstood my question.
My concern is specifically about the action of taking over the OS, not about how the blue pill works once it becomes in control :)
I know enough about emulation and virtual machine technology; I wouldn’t be posting about it else, but thanks for the explanation anyway ;)
What I meant to say in my post is that the operating system can see what programs will do and can make changes to limit or stop them from doing certain things before passing execution to them, so why (how come) it allows a code that will take over it to execute?
Take a program that has an OUT instruction for example, how does the operating system prevent this instruction from being executed?
To answer this, we’ll have to talk assembly. That's what the layers and emulation jargon is all about actually: every layer modifying the assembly of layers beneath it, or in other words: code that executes first can modify and thus control code that executes next.
Back to our example, the OS will load the program from the hard disk into memory and start doing scans before launching it. When it finds the OUT instruction, the OS will understand that the execution of this instruction will be against its security policy, so it will remove it and may instead put a series of instructions that will, for example, display an “access denied” message box.
That’s how the operating system sustains hardware security; it checks code and alters it before execution.
So when the operating system comes along the Blue Pill code in memory, there are two possibilities:
1. OS does not recognize this code or know what it does. Thus it simply passes execution to it and let it become in charge of hardware. This scenario isn’t the case, because the Blue Pill would be considered using a security vulnerability, and it is NOT (it works in a legitimate method, remember?).
2. OS recognizes the code and knows what it does, but doesn’t stop it! It runs it and let it take control over everything, and this is what happens in the Blue Pill case.
So it is number 2: the OS knows what it does and doesn’t stop it, so here’s my question again:
Why did those who programmed Windows and other operating systems that are prone to the Blue Pill allow the execution of code that step between the OS and the hardware? If taking control over the OS is a feature, then why did they implement security in the first place?
Got my point?
Qwaider قويدر said:
Nobel, but impractical in many ways:
1) Scanning every piece of executing assembly or code and searching for malicious code is being done, but has it's own performance hit. AND it's always pattern driven therefore can easily be foiled by encryption out of the order execution. Anyway, it's already being done by most anti-viruses to a good amount of success.
2) The whole idea depends on something like this:
-Processor executes something
-the result is stored somewhere
-the result is executed (somehow)
Anticipating every possible combinations of these would be impossible. Remember this store and execute thing is a huge problem because it happens independently. So storing it in the processor cache where user mode apps can't see. Not even the kernel can see everything there
3) Amd tried to include a bit to ensure safe instruction execution (at processor level) Intel followed. But how will the processor know the result of something that is still to happen at a future time? Would be rather impossible
4) Regarding the OSes, This is not a Windows issue. It's an OS issue. Linux would also be at same level of risk because it's unaware of what goes on in the mini-OSes that are executed on the hardware level
Now due to it's complexity, there haven't been any (known) way to do this although I heard of some NSF research that claim that they're already doing this on a large scale and no one is aware of it. Just like the issues with encryption where NO Encryption is available to the world if the US government can't crack it. (Remember that huge fuss over PGP?)
Anyway, for this to be exploited on a larger scale it means really huge efforts have been put behind it (like Government level or Huge company level) And due to it's sensitive nature, no major corporate would ever dare go there.
In Windows Vista, they have introduced this cool new feature. It's called User Account Control. Where the user (Even the administrator) is prompted to enter their credentials to make sure the really want to execute a specific application. Now with that being very helpful and neat feature. It has annoyed the hell out of me since I know what I'm executing. But it's very promising.
Hmm ... too many ideas for a comment
Marwan said:
aaaahhhh oki finally i got it
Black [X] Truder said:
Marwan lol, what made you read all of this? :P
Qwaider Despite all the technical details am still questioning the fact that “this is not an exploit”. It is not something that OS programmers failed to account for, and it’s not something that operating systems fall victim to because they can’t anticipate it!
Quoting Joanna:
I would like to make it clear, that the Blue Pill technology does not rely on any bug of the underlying operating system.
For now, I’ll take the whole issue as an exploit to hardware architecture; it’s the only logical explanation I can come up with so far! Anyway, I’ll be following closely and will post if anything serious turns up :)
Qwaider قويدر said:
You can classify bugs in many ways, There are Code bugs, Specifications bugs, Design bugs and logic. What you're seeing are design bugs. Which means. The implementation is fine it follows what the design states. But that overlooked certain issues causing...... yes .. the interesting and unwanted behavior
Write a Comment