Now, imagine a malware (e.g. a network backdoor, keylogger, etc...) whose capabilities to remain undetectable do not rely on obscurity of the concept. Malware, which could not be detected even though its algorithm (concept) is publicly known. Let's go further and imagine that even its code could be made public, but still there would be no way for detecting that this creature is running on our machines...
Over the past few months I have been working on a technology code-named Blue Pill, which is just about that - creating 100% undetectable malware, which is not based on an obscure concept.
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.How does the Blue Pill-based malware relates to SubVirt rootkit, presented a few months ago by Microsoft Research and University of Michigan? Well, there are couple of important differences:
- SubVirt is a permanent (i.e. restart surviving) rootkit. And it has to be, because the SubVirt's installation process requires that it takes control before the original operating system boots. Consequently, in contrast to Blue Pill, SubVirt can not be installed 'on-the-fly'. It also means that SubVirt must introduce some modifications to hard disk, which allows for the 'off line' detection.
- SubVirt was implemented on x86 hardware, which doesn't allow to achieve 100% virtualization, because there are number of sensitive instructions, which are not privileged, like the famous SIDT/SGDT/SLDT. This allows for trivial detection of the virtual mode - see e.g. my little Red Pill program. This however, doesn't apply to Blue Pill, as it relies on AMD SVM technology.
- SubVirt is based on one of the commercial VMM: Virtual PC and/or VMWare. Both of these applications create virtual devices to be used by the operating system, which are different from the real underlying hardware (e.g. network cards, graphic cards, etc.), which allows for easy detection of the virtual machine.
I would like to make it clear, that the Blue Pill technology does not rely on any bug of the underlying operating system. I have implemented a working prototype for Vista x64, but I see no reasons why it should not be possible to port it to other operating systems, like Linux or BSD which can be run on x64 platform.
I will be talking about Blue Pill and demonstrating a working prototype for Vista x64 at the end of July at SyScan Conference in Singapore.
Also, I will present a generic method (i.e. not relaying on any implementation bug) of how to insert arbitrary code into the Vista Beta 2 kernel (x64 edition), thus effectively bypassing the (in)famous Vista policy for allowing only digitally singed code to be loaded into kernel. Of course, the presented attack does not require system reboot.
97 comments:
So the Matrix is real after all just as i thought, sounds very interesting, i'm looking forward to hearing much more about the Blue Pill etc. See you in Singapore, haha i Wish !
Regards
Spanner
Hi,
will your "blue pill" code be available for download? Even though the concept in itself is very impressive, I'm still not convinced on the "undetectable" aspect of it. Also, I saw no comment on how it is able to, with user privileges and no exploitation whatsoever, put itself between the hardware and the OS. Too bad I can't make it to singapore...
I'll look further in the SVM/Pacifica documentation, anyway ;)
Thanks
No, blue pill is not going to be available for download - it has been developed exclusively for COSEINC Research. However, we (COSEINC) are planning to organize trainings about blue pill (and other cool technologies) which would give an opportunity for the attendees to experiment with blue pill and see it's source code :) More details will be posted at coseinc.com in the near future...
Also, please note, that the strength of the blue pill is based on the SVM technology - so, if you could write a generic 'red pill' for SVM, then it would mean that you could detect blue pill (and that Pacifica is buggy). On the other hand - if you would not be able to come up with a general detection technique for SVM based virtual machine, then you should assume, that you would also not be able to detect blue pill...
cheers,
joanna.
papers about blue pill (and more details) will be availabe after SyScan and Black Hat USA conferences...
joanna.
Hello.. is this blue pill is researched for a good or bad usage?
I'm afraid many undetectable thing could be used for any bad thing such as virus or else..
Thanks anyway..
I personally think that this is just another attack victor previously un thought of. So it's quite ground breaking. But it come as a result of poor designs at multiple levels. From software to hardware. In the old days of computers. people learned to load before the OS by targetting boot loaders, partition tables ...etc later all of those were detected. some did wierd things the bios and almost anywhere they can store and excute code
I think the concept of a Redpill that would actually be a low level app that would interact directly with SVM could eventually be part of any malware removal kit. It would be even easier for someone to write a "Pill-Proof" pill that would detect attempts to execute a bluepill and stop it.
One thing is certain, things will continue to escalate.
Amazing ideas/research. This and your other work reminded me the part of CS that I had forgotten all about in school.
Heh, almost enough to make me think about changing jobs too :-/
Hi,
Very impressive!
Can you give any hint on how
you inject code into the kernel
with no sploit?
U sure it cannot be blocked?
Thanks
I did not write it can not be blocked - I only stated it's a 'generic' attack, by which I mean that it does not rely on any implementation bug (like buffer overflow), but just exploits some design flaw. Surly it can be blocked and I will even discuss three approaches of how this could be done. It's just that each of those solutions (which I'm aware of) seem to introduce some 'penalty' to either functionality or performance of the operating system.
To get more details you have to... either come to SyScan or Black Hat ;)
Very interesting work! Even more as you went all the way through implementing it.
Reading about the two pills reminds me of an idea I carry around me for a while now...
In both pills you seem to exploit bugs (privilege escalation / information leakage) of a CPU model. And hey, CPUs do have bugs.
If I only see that intel is describing the "int" or "ret" opcode behaviour in 8 pages of pseudocode each, I come to belief there are exploitable bugs, too.
Ususally we only run opcodes on our CPUs which come in a well-formed and organized manner out of a compiler. Running the right combination may lead to surprises.
Some month ago I had started hacking on some code which should do "genetic programming" on a opcode-level. For doing so I had recycled parts of nasm's backend. It's not finished and probably will never be. But while targeting the (genetic) search and solution for small but complex problems, I ran into thinking what might happen and how do I count the exceptions my generated code raises in the OS, and will it find bugs in the OS?
Then I also got the idea that running this kind of random opcodes is very similar to fuzzing the CPU HW, and whether I may find bugs there.
How likely is it that we find an "off-by-one" or other exploitable bugs in HW? In the end the chipdesigners aren't putting together millions of single transistors, but they write "c=b+a" and a,b,c are described by datatypes.
It is very likely.
thanks for presenting two of them!
mazzoo
PS: detection should always be possible through the page handler scanning for the evil opcode combination. For a while it won't even matter, *alloc is slow anyway ;)
It's very interesting what you wrote - but I need to make one clarification:
Blue Pill does *not* rely on any bug in Pacifica neither in OS. Blue Pill uses only the documented features of Pacifica.
Red Pill, in contrast, does rely on a 'bug' in x86 architecture, which in this case is the presence of a sensitive, but non-privileged instructions, like SIDT.
joanna.
I'll take the red pill, thank you very much.
I am very impressed with your documentation and presentations on invisiblethings.org. I really appreciate your explainations and suggestions for how to counter some of these concepts like "Stealth by Design" and appreciate that have some ethics in code distribution.
Have you actually tried to find whether it's detectable by rigourously analyzing the architecture? I understand you mainly just want to get the concept out there, but still...While I know you found one instruction to exploit for your redpill, the people in the USENIX paper you subsequently found knew about 17 instructions. This does not speak to a rigourousness in actually proving it's undetectability; just that if anyone else wants to try if they succeed then AMD loses, and if they fail, you win (_possibly_, since their failure does not prove your success).
Have you tested whether bluepill introduces enough skew as to be detectable via timing tests over time?
Does blue pill still load if the system is booted in safe mode? (I assume/hope so but I don't know the exact differences in how safe mode boots) What about if it's booted from a CD? If not the latter then methinks MS strider/ghostbuster detects it trivially.
Am I understanding correctly that this methodology is limited to 100% AMD Pacifica cores, and thus wouldn't be possible on Intel CPUs?
So whats the intended point of the research?
Surely this isn't a good thing and it's only a matter of time till some of your idea's filter doen and ensure that we have to sit through more spam, junk and malware on our systems.
Or am I missing something?
How would blue pill handle the presence of an existing hypervisor? Does it nest or would it fail?
Also, once running, how would blue pill handle or affect the attempt to load a hypervisor?
Would either of these two cases act as a detection vector for blue pill?
Hi,
Seems that this concept's detection focus has been on the GuestOS which of course is limited in what it can see in the hardware's Host environment. But are you saying that the hardware has limited or no self-monitoring/self-managing capabilities? It would seem to me that simple enumeration of running virtual environments and applying rules to such (like don't launch a new enumerated environment without warning under certain conditions) should address this type of "vulnerability."
There's only two ways of detecting a Blue Pill like this.
1) If the TSC (time stamp counter) cannot be tampered with, then you can detect the extra cycles that blue pill is using. If it's not using any cycles, it's not a program.
2) If there's some portion of memory that can't be accessed, then you can tell there's something there. The pill may be smart enough to hop around to unused parts of memory, but if all memory gets used, there's nowhere to hop to. Swapping to disk is an idea, but where is the swap code going to live? It has to use some memory somewhere, or again, it's not a program.
Your article needs an edit, it is specifically targeting AMD as if you are being paid by Intel.
Both have almost the same type of implementation so this kind of targeting is unwarranted and gives wrong impression to a reader
Of course, if you just have an OS that doesn't allow the insertion of such things, wouldn't that be better? But then again, Windows, Linux and other 2 PL designed OS's will always have troubles.
I decided to implement Blue Pill on AMD64 processor and I spent my time on doing this. Unfortunately I'm only single-threaded, when it comes to programming, so I did not develop a code for Intel at the same time. Indeed it *seems* possible to implement Blue Pill on Intel VT, but I haven't done this yet.
As to why I decided to choose AMD and not Intel - I followed the alphabetic order ;)
Also, at Black Hat there will be another presentation, by Dino Dai Zovi, about VT based malware (undoubtedly sponsored by AMD):
http://blackhat.com/html/bh-usa-06/bh-usa-06-speakers.html#Zovi
But I don't know if (and how) Dino's work is similar to Blue Pill (e.g. if it works on the fly) or not. I'm looking forward to see it.
In reply to these other comments, I understand that AMD is targeted becuase it is not "vulnerable" to easy detection like on Intel. Simple as that.
What I want to know is why an OS could not simply run in a VM by design. That way, if a blue pill was swallowed, it would affect the only the OS itself. The VM the OS was running in could easily detect the pill.
Is that a possible method, or does SVM provide a way to circumvent it?
Joanno, chcialbym zeby moja zona takie zainteresowania miala.
GOOD JOB !!!
I am curious. If Vista had a structure like the IBM/MVS control blocks for storage and contents supervision would Blue Pill still be undetectable?
Well, any VMM is (should be) an ultimate undetectable root-kit. If the VMM is detectable, it is either because of performance reasons, or because the VMM writer is lazy.
However, if you already did have a VMM running on the SVM machine, this insertion attempt by "blue pill" would not go undetected by SVM-enabled VMM. And no, you will not be able to use the "red pill" to detect this VMM, because the VMM itself will be completely hidden from you as it uses SVM.
This claim of “blue pill” being something new or revolutionary is almost as ridiculous as someone saying, “I have created ultimate rootkit on DOS. It uses the protected mode on x386 to insert itself underneath DOS, and runs the entire DOS OS in a virtual address space”. The claim is ridiculous because, if you do not have a monitor that runs in the highest privilege level allowed on your machine, then you are painting a big bull’s eye on yourself, and just inviting someone to insert their code underneath yours.
I would say, going forward, having a VMM is not a choice, but a requirement, and I think that's why Microsoft is working on their own VMM. You just cannot leave the highest privilege level on your machine open for some hacker to hack.
One question that has not been answered -- are you doing this for good, or bad?
Shouldn't it be detectable if you already have everything running in a hypervisor that regularly checks the system for a "blue pill"?
The hypervisor stuff could incrementally check the entire "guest" memory space or maybe just the important system hooks, structures for tampering.
I'm not sure if a two CPU machine could have one CPU used to check a "guest" machine while it is running on the other CPU.
This probably isn't new. Hypervisor stuff is 1960s or earlier? So I'm sure someone had already thought of it even way before Microsoft mentioned it, or this particular implementation.
But anyway, its interesting enough that its getting more "mainstream", just not particularly surprising or remarkable - given the new VT/pacifica support.
Questions for Joanna:
1. How is GPU handled? Does Direct3D and OpenGL hardware acceleration still work when your pill is installed?
2. Why haven't you tested on Intel VT too?
3. What happens if I try to run say VMWare on top of your pill? Will it fail? If the answer is yes then that is the way to detect the pill.
I already answered why I didn't test it on Intel. I also wrote in my blog that all the devices work natively - so not performance penalty! How is it done? - you will have to come to SyScan or Black Hat to find out ;) So as to find out the answer for all other questions...
Quite interesting work, Johanna. As I look back to the days when I worked with DEC PDP-11s and VAXen, I am struck by the realization that CPU design hasn't progressed much in the interim. The same vunerabilities exist now as existed then. It gets me to wondering, in your professional opinion, is it technically possible to design and implement a CPU architecture that would be free from even Blue Pill-type exploits? I.e., every instruction and sequence of instructions has known, safe behavior immune from exploit? Or is it that this falls into the realm of a "grand problem". (One wonders how immune the supercomputers used to design nuclear weapons are to exploits...)
In your opinion, is virtualization technology like Pacifica inherently "unsafe" from exploit, or is there a way to implement virtualization to make it unexploitable? It would seem to me that the concept itself has issues with exploitability, as you have shown.
Continued good luck. Just stay away from my systems, please!
While blue-pill is applaudable in concept, I think that there will always be architectural weaknesses which will allow this to be detected and removed.
First, unless your code is capable of hooking the BIOS (and fairly early, at that), your rootkit will be detectable on a reboot using currently implemented techniques.
Staying "within" the game, without additional chipset support, your virtualization would be easily revealed by a kernel level module which can program a DMA controller. I believe that most network chips can be used to sample each page of physical memory and verify that it's not remapped.
Fundamentally, if there is communication with an external entity, you will not be able to hide timing deltas, even if your code properly adjusts TSC.
To some extent, this applies to interprocessor interrupts - virtualizing a single core is fairly well understood. Virtualizing multiple cores is probably not, and the additional latency introduced is likely to be obvious (one core in a, for example, CPUID loop, the other sending non-stop interrupts and busy-waiting until a shared bit is set would reveal that CPUID is taking significantly longer than a non-trapped instruction like IMUL.
Even playing on a single core, there are some cases which are very difficult to properly virtualize with virtual page table algorithms - consider self-modifying code executing out of the page tables that map to that code. Making sure that this code is kept in-sync with the proper changes from A&D bits is somewhat difficult. I'd like to see how you manage this.
Similarly, in the complicated x86 architecture, there are various nested-interrupt conditions that are unlikely to be properly virtualized, at least not without significant code which would introduce bugs.
Hopefully you will be providing more details on how you dealt with these techniques, or possibly updating red pill for some of them?
I am unaware of whether the AMD implementation has this, but I seem to recall that the Intel implementation has a write-once kill bit that a BIOS implementation can set that will disable VT instructions.
Somehow I expect that most BIOSes will disable VT and it will require updating the BIOS to enable this feature on many motherboards.
So it sounds like I'd want to install hypervisor on my personal pc before/as I install the os, just to make sure I have the first one installed and I can police my own computer? It's a very interesting concept and I can only wonder what the eventual effects on personal and work PCs will be.
Joanna,
Kewl work! I'm sure you're saving the good stuff for the conference, so I look forward to reading up afterwards.
I would be interested in hearing more about what happens when there is existing hypervisor, and what happens if you "take two blue pills."
Cheers
BC
Fantastic explanation and very interesting responses. Well done! I only have one question as it relates mostly to AMD technology: is there (or will there be) an applicable aspect to Intel technology as well? If I missed that being mentioned already, please forgive my question.
Any kind of hypervisor will be detectable using timing attacks. A loop of a few million VM privilaged instructions will always take substantially more time in a hypervisor environment. Even if the hypervisor virtualizes the TSC, PMC and all other hardware timers, to hide how long a privilaged instruction really takes to execute, such trickery can be easily detected by a user with a watch as the VM's efforts to hide itself from software will cause the virtual time to diverge from the real-world time.
Further, it's impossible for a hypervisor to completely hide its memory footprint. Reducing the size of system memory is obviously detectable. If the hypervisor attempts to hide by keeping memory size the same and swapping a few pages out to disk, then a timing attack will easily discover that some pages have an extremely high latency.
Finally, hypervisor malware has no special resiliance against detection by off-line methods such as a signature scanner booted from a livecd.
Since this AMD only, curious to know if you can tell us whether this research has be financed directly or indirectly by Intel Coroporation?
I suggest you all read the commends. As Joanna has already stated and others have pointed out, as far as we know Intel VT is just as vunerable to the blue pill (although obviously it would have to be programmed for Intel VT). Intel is not any safer in this regard. The reason Joanna choose Pacifica instead of VT sounds to be because that's what architecture she was working on.
Joanna,
I do not believe this or any other exploit could be undetectable to an experienced programmer who has a copy of the exploit.
What would happen if you attempt to install blue pill on a system already compromised by blue pill. Is there code to avoid this situation? If so it could be used for detection. Does it install succesfully in a recursive VM? Then what would happen if it was installed 50 times?
As a general concept it could be undetectable as long as a specific exploit is unknown, however there's ways to block this too.
What if the BIOS on all machines blocked Pacifica by default, and on attempting to install a legit VM a cold restart was requred during which the BIOS would show a warning about the dangers of the technology before giving the user the choice to enable it or not?
Overall your work sounds interesting (allthough it is evil) but I think your claims are overstated.
One question that has not been answered -- are you doing this for good, or bad?
Since this AMD only, curious to know if you can tell us whether this research has be financed directly or indirectly by Intel Coroporation?
You people really are too suspicious. Anyway, it shouldn't matter if this is "for good or bad", it's just interesting.
Basically you simply make a stronger case that absolutely EVERY resource on the computer (file, registry, etc...) must be managed. The management system must calculate the correct end state for that specific node to be in, and make corrections to its as-found state to bring it to the desired end-state.
Yes, as a duct tape solution, I suppose people can deal with jumping through the hoops of getting all software digitally signed... and of course THAT protection is only as good as the person with the keys. (And the quality of the keys... "So is that copy of XP legit or not? Does MS even know!?") Do YOU trust the person with the keys? I don't! I'll pick my own files - signed or not - thank you very much.
Michael Lueck
Lueck Free Software Foundation
www.lfsf.org
Even if the Blue Pill is undetectable any operating system can be equiped with the same technigue for the vulnarable parts in the processor design. If the vulnerability is already exploited by the OS the OS or programs running under the OS must be able to detect the Blue Pill and even to remove or block it.
Joanna, I do not understand why you cannot answer whether VMWare works if installed after blue pill?
I need to save something for my presentations, right? ;)
Hi Joanna, you said:
You people really are too suspicious. Anyway, it shouldn't matter if this is "for good or bad", it's just interesting.
I think that Einstein thought in the same way at his time, but do you think that he was happy about the dead in Hiroshima or Nagasaki?
What do you think about the Chinese and other states preparing the Cyber War in their armies? Crash down all computers in the northern world and you have a bigger chaos, then in a conventional war. Congratulation, you give them the perfect weapon. Thank you very much!
It is NOT only interesting, it is also a question of moral and responsibility for your doings.
I hope you know what your doing.
cu
Ron
1. I did not write those words - they were posted by somebody else! Please do read more carefully what others write, before starting to accuse people! (I know, I know, you posted as 'anonymous', so you don't care...)
2. Comparing Blue Pill to Nuclear bomb is just ridicules!
3. What makes you think, that if I didn't publish my research, other people (those working for "Chinese and other states preparing the Cyber War" as you said) would not be able to come up with the same technology by themselves? Do you think that I'm the only single person on this planet capable of creating such things? ;)
joanna.
Hi Joanna,
perfect reply! Eventhough I am not a programmmer - as a scientist I can only support your standing!
I got to your site by a newspaper article describing the Blue Pill project in a glance.
Just one question from my side: what would you use it for?
greetings from Vienna :)
I'd be much more interested in the method used to bypass the prohibition of loading unsigned r0 code on x64. If that "bug" (by design?) is taken care of before Vista is RTMed, this or any other rootkit technology would simply become purely theoretical. The only thing that bothers me is that 2 KM bugs that can be used to esecalate to r0 that I reported 8 months ago to MSRC are still unpatched..
You probably won't read this, but you should know that any SVM based VMM is easily detectable. It's not a design flaw. Read the Popek/Goldberg paper carefully and you'll see all VMMs have this basic property.
For "blue pill" to work at all, you have to trap certain instructions. In the very least, you have to trap write cr3s (to implement shadow paging). Since cr3 is just a register, the number of cycles it requires should be no more than the number of cycles any other register write takes.
Using this simple fact, you could determine if cr3 writes are being trapped. Even if you found a way to avoid trapping cr3 writes, you can do this sort of analysis for every possible trap. A sufficiently motivated system could very easily determine that it's under a VMM.
Google for the Pioneer paper at SOSP. It presents a very neat system based around this idea for pre-VT/SVM systems. Unlike your "red pill" hack, it's not relying on artifacts of specific VMMs.
It always surprises me, when people start criticizing a work which they haven't seen before, because they assume that this is done in a way *they* would do this... Dear Anthony, and what if I decided not to hook CR3? ;)
It might be interesting but I fail to see the bigger picture. What's the point? Is it just fun to find security cracks or is there a greater purpose? Do we find the exploits so that we may teach the industries how to protect their technology, as their technology is inevitable our technology?
I think most people who don't know the implications of your research are probably prejudiced against anyone supporting black hat. I know of no one who wouldn't want to wring the neck of the programmer who created the virus or bug that drove them crazy.
All the "critisizers" need is more information. You could be building a weapon or a machine that solves world hunger but we won't know because you think we ask too many questions?
Forgive the skeptical scientist who wants more answers about that which he does not know.
A reply to all who suggest detection by time measurement:
You need a clock to measure time. All clocks that you can observe from within the Matrix can be theoretically compromised (including possible requests you can make to external NTP servers).
Hi Joana,
I wonder if the x86 flaw you ar exploiting is the SEH mechasnim, which is known to be very different and more secure or the x64 platform.
Cheers,
Fabian
To all the naysayers, prove or disprove the following statement:
"This statement is a lie."
Or similiar examples from Hofstadter, Turing, Gödel, et al.
Nice work, Joanna. I hadn't realized AMD and Intel were so far along, but I got slipped a few blues a few years ago and have been basically offline for over a year. And of course they don't print this stuff in the Morning News...
Looking forward to more details.
Joanna Rules!!! Another concept. The future of security is full of surprise and excitement, having around scientists of the like of Rutkowska.
She's such a nice person...even if she doesn't reply to my emails!
Her mind is razor-sharp.
Her name is Joanna.
Your strong friend from Greece.
Incredible technology. I'm just thankful that Joanna is on our side. Imagine, people, if this wonderful lady was one of the black hats? We'd all be a lot worse off than we already are.
It astounds me to see so many people logging on here and criticizing and ridiculing Joanna. Instead of doing this you should be thanking her for all her hard work and dedication. Thanks to her we will soon (if not already) have a working prototype of the blue-pill technology which will give us significant insight in how to counter act this technology when the "bad guys" develop their own.
Way to go, Joanna. You keep up the great work.
And Thank You.
--Freejack13 (anonymous because I'm just too damn lazy to fill out the form for a blog I'll never use)
Bonjour,
Bravo et félicitations pour votre travail.
Cordialement
Chris BART
REIMS
FRANCE
I think this kind of work is for good because the target technology can be reviewed and patched what will avoid the bad use of the revealed fail.
Sadly I could understand less than a half of all... But it is enough to say: Jonna rocks!
Go ahead, girl! ;)
Gratulacje
Hi Joanna. Are you a math whiz as well? I know that most great programmers are good at maths also. Whats your iq, like 150, 160?
Hello,
I have some questions regarding Your article : why simply don't use hypervisor supplied by CPU vendor ? Couldn't it detect and report any other virtualization-like activities using hard-wired functionality ?
And what makes us thing, that, for example, a "Grey Pill" isn't already in place ? ;) In that case - i think it's better to have the idea publicly discussed, rather then left behind in hope that no other will be smart enough to use it covertly for some evil purpose.
Good Luck on Your research !
Well done Joanna
I just wanted to know a couple of things:
Is Bluepill equally potent for the Intel 64-bit platform?
Are Macs vulnerable to Bluepill as well?
Since you have created the malware, do u know how to combat it as well?
An earlier poster posted..."If you would have a system infected by a blue pill, and this system runs about 3 virtual machines. would the blue pill instaciate a 4th machine? if so would the malware be able to 'spy into the other systems?."
But what if the Blue Pill is not malware? What if it works best if it is the exact opposite, improving programmed/programmers source code rather than infecting it adversely and drawing attention to itself.
All it would take would be for a few doses of the Blue Pill to "unsettle" the Operating System for it to be recognised that ITs processor/ITs kernel had been compromised/hacked. The fact that processing had been improved, rather than harmed, would then render control of machines to the "blue pill pusher" for as long as the processing remained Mutually Beneficial.
Any Denial of Service countermeasure to regain Control being counterproductive as it removes what is in effect a superior, stealthy Hypervisor improving Hypervision Control.
I've been thinkign about what You all have posted here (at least I kept the constructive comments in mind), and... a few conclusions:
a) man-with-a-watch-security: as someone already pointed out, all clocks within the Matrix are being controled BY the Matrix, so it can also make sure their values are returned "correctly" - at least I know I'd do that if I were the Matrix ;-)
b) I couldn't attend the conference (I'll poke around for some sort of a transcript shortly), but to answer one of the questions - namely what would happen if two or more Blue Pills ran together - I believe that since the whole idea is based on a simple design instead of a particular flaw, there would be no "sharing violation" involved - they would just stack on top of each other and every one of them would believe IT is the Matrix ;-) Well, that would be the ideal state anyway - I would think before allowing them to somehow detect and communicate with each other, since that idea alone would mean that there already exists a simple detection method ;-)
The whole idea of the Matrix wasn't to sort out WHICH ONE was real - simply because they were all fake. That's all there is to it, I believe, and it all comes down to Your personal choice of 'reality' You so choose to believe to be "real". The sole idea of someone deciding for me what is real and what is not, depraving me of that choice - it's making me sick. Trusted Computing, for example, is IMO yet another way of giving more power to those who already have enough. But hey, what else is new...
Back to the matrix thingie ;-) I believe what I'm trying to say here (oh, my overconfidence ;P) is that the easiest way to detect the Blue Pill (the Matrix) is the free will to choose Your own reality, and to observe how the reality You are currently presented with deviates from what You chose. The problem here is not the code - it's us, our lack of knowledge and our ignorance.
As to how it can be used - every person will have his or her own answer to that already in their mind. I, for one, visualized being able to abstract a lot of common things (like hardware handling, code auditing etc.) away, and concentrate on the very problem at hand without worrying about unrelated details (I know, I'm contradicting myself here, but hey, the world is based on binarism ;PPP). If You wish to use it for evil deeds, go right ahead, I can't stop You. Someone will. It's a constant race, so why bother? :-)
Now - I'm no tech when it comes to writing extremely complex code (I wrote a few basic apps, and a lot of PHP code, so there You go), but I think I see a sort-of-a-way-out-of-this-problem-thingie: trick the parent virtualization to recurse itself and terminate the previous one gracefully. In such a case the Blue Pill would NEED to know that it is a blue pill and not just yet another abstraction, hence it would need to be able to identify itself correctly, and there are many ways to detect something if it can be refferred to, even if only by itself. If the Matrix knows it is the Matrix, there's a whole world of difference, since it's impossible for that information to be "virtualized away".
I hope my post was at least a bit amusing ;-)
Best regards
Marcin Grzechowiak, Poland
you do know that the real black hats never show up to the conventions....
red hats. black hats. they are all the same. do what they love to do some get paid and others dont. you do it for the rep and sng's of course
Good work Joanna :) keep up the good work on ur research :)
Greets from Suomi Finland
Yoshi
Hi Joanna,
You're thinking too small.
:-)
Wonderful paper, very smart thinking.
Up the page a bit a commenter, DiGriz said:
"Nice work, Joanna. I hadn't realized AMD and Intel were so far along, but I got slipped a few blues a few years ago and have been basically offline for over a year. And of course they don't print this stuff in the Morning News..."
I concur with those thoughts and have been dealing with a similar situation(s) that your paper appears to touch on.
There is a difference though, they're Macintoshes (PPC).
Don't stop reading.
You're on to something here and I'm way past worrying someone will think I'm paranoid, etc.
No one I've seeked out will touch this because they think I'm in error, and that ... is just arrogance.
We have Xserves and workstations (PPC), I'm the SA.
Most talk is x86 based, so I have to "dance backwards in high heels" at times to get some of these concepts across.
This link is ring 0 related and speaks of "legal executions" that you also allude to.
http://www.securityfocus.com/columnists/402
Read the (my) comments too.
I'd love to talk with you, or a colleague about this. I have examples, drives, screenshots and witnesses.
Really, nice work.
hylas
I'd encourage everyone to listen to Steve Gibson's Security Now podcast - he did a very good job of explaining the principles to me (a lapsed programmer - now electronics engineer) and I think if hal the posters above had listened to it they'd have made more intelligent comments.
The research which produced "Blue Pill" is simply part of the continuum of the masses introduction to itself, as I see it. Such research, and the products produced keeps mankind headed in the direction which is ever present in his mind; who am i? why am i here?
That some producers of technology may look unfavorably on such research is not, well, precedent setting.
Research is most often controversial - my opinion based on personal readings and observations, and statements of those more academically suited to speak on such matters - and have made some fantastical contributions to mankind.
I for one hope that we continue to ask and search out things we want to know.
There was a time when computing equipment consumed entire rooms, and access to such equipment and the algorithms employed were restricted to those having a need to know.
Today, we - mankind - live closely within the technology we create.
Vista to AMD: "let us go forward and drink of the blue waters, for the time shall come when the waters shall mineralize, taking pill form and thus establishing the beginning of our end."
AMD to Vista: "be not distressed one of many ages, the red one shall come on his mighty steed, ending it all in a purple haze, and we shall be saved."
Hello joanna;
very nice work and impressive!
I m a french security consultant.
Your research is opening new ways...
Thanks again !
The great Taoist master Chuang Tzu once dreamt that he was a butterfly fluttering here and there. In the dream he had no awareness of his individuality as a person. He was only a butterfly. Suddenly, he awoke and found himself laying there, a person once again. But then he thought to himself, "Was I before a man who dreamt about being a butterfly, or am I now a butterfly who dreams about being a man?"
Have anyone checked their own system environment :)
Joanna,
whilst obviously wanting to flatter you ;) , i think you
are right with regards to other people being capable of developing similar approaches to "blue-pill".
(looking at comments in the blog)
therefore i think your research
is very valid and extremely interesting. for a number of reasons.
what are the chances of a Super "blue-pill-network"
being developed of "blue-pill" hosts communicating via covert channels?.
karl
I think it could be harder than some people believe to defeat timing measurements. NTP requests may be easy to identify, but there are plenty of ways that such clock servers could be disguised. If I make two calls to two different external servers from within the Matrix, how do you know that those requests aren't cryptic communications with synchronized clock servers? You don't, that's how.
What I wonder is if the Blue Pill sacrifices no system performance, could this technology be used in a similar way to do a "fast OS switch" on a number of different virtual machines with no performance loss?
I look forward to reading more.
Good work.
It is NOT only interesting, it is also a question of moral and responsibility for your doings.
I hope you know what your doing.
Oh come on, all you people spinning morality doom and gloom. Its better than concepts/technology like this be made public knowledge sooner rather than later. I'd much rather know what the Black Hats may be using before they start using it :D
Amazing, just like out of a Vinge's novel!! Great work!
the olddddd blue pill swollowed by the OS trick!
oh joanna.. if only you'd have used your powers for Goodness instead Of evilness :)
interesting job you have. back in the day we didn't get paid For playing and having fun heheh. great work you've done tho and i'm impressed.
hi my name is muhtfe very nice informations and very nice blog thank you very much...
Let me echo everyone's sentiment and say nice work. Any word on how it's been received?
Wow this is a wonderful blog and the 'blue pill' idea is fantastic and...scary at the same time. It seems that no matter what new technology we come up with to make our lives easier, those same implementations can be used against us as a potential attack vector, given someone clever enough.
Regards
Turellius
This is a wonderful blog I have just stumbled upon. I must take the time to thank the person who maintains this blog, obviously a security professional. All the technology we develop to make life easier ends up being a possible attack vector, given a clever mind. This is just a fellow IT professional saying keep up the awesome work.
Kris
I can't be but suspicious when I read about people making 'research' on such subjects.
Is it really for the sake of knowledge?
I am stunned by the number of people questioning Joanna's motives in investigating this! I think it is fascinating stuff.
You can be sure that 'bad' people will already be doing the same. So I am all in favour of it being discussed in the public domain. With enough 'good' people thinking about and investigating something, hopefully any weaknesses in operating systems can be patched up.
I am very interested in the idea of running internet servers, firewalls and so on, on virtual machines; of course it is of paramount importance that virtualization is bullet-proof. The worst-case scenario imaginable would be where, by exploiting a design or implementation flaw in the virtualization hard- or software (of the same ilk as the flaws discusssed in this thread) an attacker was able to access a resource in the host machine from within the guest machine.
With people proactively investigating the mechanics of virtualization, hypervisors and so on, and bringing any potential vulnerabilities or abuses into the PUBLIC eye, we are more likely to move forward and use virtualization in increasingly important roles.
These comments have been invaluable to me as is this whole site. I thank you for your comment.
this kind of thing is kind of rediculous. If it is undetectable then it is not doing anything. If it were doing something we can see what it was doing.
So, I ask, what is the point of having software that does nothing?
Bla bla bla, to all of those good-guy evil-girl slowpokes, there is no spoon, so how can there be something like good and evil ?
Undetectable...
Userland code can be undetectable too (Not undetectED, but undetectABLE) if the code is agressively polymorphic.
Unfortunately, the term polymorphic is a poor choice since we HAVE had poly code for a long time and usually the changes are minimal and easily countered with opcode equivalency and heuristic detection. NDAs (Non-Deterministic Automatons) can pick them off quite easily.
What do you need for 'detection'? Well, you either need identifiable code (soft signatures) or identifiable behaviour (heuristics) or some other characteristic such as extra delays on certain sensitive handlers.
It is possible to avoid both of these in a userland entity which parses its own structure into a data vector paradigm and then recursively rebuilds that paradigm using a table of mnemonic vectors that stack to produce black-boxes that exhibit the vector under reconstruction.
The result is code that is entirely different from one generation to the next. The only stable elements (the actual vector tables and any data required) are encrypted and accessed through an executable decryptor which is in the reconstructed space... this leaves nothing for AV engines to get a handle on other than the overal heuristic detection of behaviours.
This too can be easily dealt with.
Once you take these techniques to the kernel level there is very little that can be done provided that you don't do the obvious. For example, you don't want to patch interrupt tables because this can be checked - but patching the handlers themselves can be fair game if done correctly.
Virtualising the system, getting in under the existing HAL or using kernel mode or hypervisor techniques is all well and good - but they don't really solve the problem of undetectability except on the infected platform itself.
One wouldn't ask an insane man whether he thinks hes sane... and if you did, well, what faith could you ever have in the response. No, to be undetectable you have to be unrecogniseable given a snapshot of the system under EXTERNAL scrutiny.
For that, you need a 100% fluid polymorphism based on a vector reassembly paradigm. In effect, providing completely fresh executable code per iteration with no signature potential.
And thats something you won't see on demo at a conference or available for download in a public off-the-shelf rootkit.
I suspect that very much like Joannas 'blue pill' we're talking about 'feasable detection' ... since anything can be detected given the required time and resources. The point is, is it feasable or prohibitive to routinely check for such infections.
Whats worse, if you don't even know what the code will look like when you see it... well, then things get tricky even when analysing offline snapshots of the heap and filesystem state.
Unfortunately (Or fortunately, I'm very dark-hatted), the answer is probably a firm no at present.
I agree with ANCIENT´s comment:
"The point is, is it feasable or prohibitive to routinely check for such infections."
That has been the goal of some virus writers for some time, i.e. ValleZ from 29A.
Coding the undetectable malware is probably impossible (Z0MBie, former member of 29A was probably the person who was more near to that whis his ZMist), but if you make detection a really time consuming task, then, you won.
Great post! Thank you.
I was very disturbed by your presentation at the Nordic virtualisation forum, even though as a technician rather than a academic I didn't really understand a large part of what you were saying.. I'd never thought of the concept of hostile vitualisation as an attack vector.
Thanks for ruining my day! (and being very thought provoking) :)
The Blue Pill - counterpart of Red Pill...undetectable
I went to see you speak at Sector and what you presented really opened my mind. As a student in IT security you are very inspiring.
How likely is it that we find an "off-by-one" or other exploitable bugs in HW? In the end the chipdesigners aren't putting together millions of single transistors, but they write "c=b+a" and a,b,c are described by datatypes.
It is very likely.
please answer
Would your redpill program be able to detect running in a simulator rather than a virtual machine? I haven't thought deeply about it, but at first glance it seems like no.
Post a Comment