All the hype started from this article in eWeek by Ryan Naraine... The article is mostly accurate, despite one detail - the tile, which is a little misleading... It suggests that I already implemented "a prototype of Blue Pill which creates 100% undetectable malware", which is not true. Should this be true, I would not call my implementation "a prototype", which suggests some early stage of product.
That being said, I sincerely believe that Blue Pill technology will (very soon) allow for creating 100% undetectable malware, which is not based on obscurity of the concept. And I already stressed this in the description of my talk here and here. The working prototype I have (and which I will be demonstrating at SyScan and Black Hat) implements the most important step towards creating such malware, namely it allows to move the underlying operating system, on the fly, into a secure virtual machine.
The phrase "on the fly" is the most important thing about Blue Pill - it makes it possible to install a blue pill based malware without restarting the system and without any BIOS or boot sector modifications. I wish all those people who were posting about how easy it would be to detect Blue Pill by booting a system from a clean CD, spent more time on reading my original blog article, instead creating useless posts... (just a little wish).
The Blue Pill prototype I currently have is not yet complete, but this is not that important, because having successfully moved the OS into a virtual machine, implementing all the other features is just a matter of following the Pacifica specification. And I will repeat my statement again: I believe the malware based on a fully implemented Blue Pill will be 100% undetectable, provided that Pacifica is not "buggy". 100% undetectable in practice - I should add - as I'm aware of some theoretical brute force attacks, which I however do not consider as being practical and that they could be used in the future anywhere outside the lab. It should be undetectable, even if the malware code was made available to the opponent (e.g. AV company).
There are number of ways of how Blue Pill could be exploited to create the actual malware (Blue Pill itself is just a "hijacking technology", not a malware) and I will be showing a simple example of how it could be used to create a network backdoor on Vista x64.
What happens when you install Blue Pill on a machine which is already Blue Pilled? Should future OS come with own, preinstalled hypervisor to prevent Blue Pill installation? What about timing analysis? All those questions will be answered during my presentation - please do not send or post the same questions again and again...
That all being said, I don't think the title in the eWeek article was too much exaggerated, but I just wanted to clarify the things. After all, it was very positive, IMO, that the article attracted lots of attention, because I believe that hardware virtualization technology could become one of the biggest threat in the coming years (i.e. when more people will use processors with hardware virtualization support) and if we do not do anything about it. Can we do anything? I believe we can, but first we need to understand the threat.
One more thing should be commented. Some people suggested that my work is sponsored by Intel as I focused on AMD virtualization technolgy only. They should know then, that my work was sponsored exclusively by COSEINC Research and not by Intel. I implemented Blue Pill on AMD64 just because my previous research (also done for COSEINC) were focusing on Vista x64 and the natural choice of the processor for this was AMD64. And, although I wish I had more time to also try implementing Blue Pill on Intel VT, unfortunately I don't :( Accusing myslef of doing this on one processor only, instead on both AMD and Intel, is like saying that all vulnerability researches who find holes inside open source programs are paid by Microsoft ;) This is just ridicules!
you wrote "What happens when you install Blue Pill on a machine which is already Blue Pilled? Should future OS come with own, preinstalled hypervisor to prevent Blue Pill installation? What about timing analysis?"
ReplyDeletebut.. what happens if I buy a PC with an OS preinstalled and already blue pilled by the vendor? you certainly know about the Sony/rootkit matter... I'm so scared.. what do you think about it? there's a way to solve this problem?
ps. compliments for your studies :)
This entry quite much clarifies your previous post and answer some (usless ;]) questions. Both were nice for reading, I'd really like to see your presentation, but I probably won't be able to. Will ther be any video available?
ReplyDeleteI haven't messed with any processors that support virtualization, but it seems that I should be able to go into the bios, disable virtualization, and problem solved.
ReplyDeleteNo software is perfect, and this rootkit will be detected soon enough. I don't care if the rootkit can be loaded without rebooting. If all else fails, I boot from a CD, verify that each and every Windows file is correct, and double-check everything that starts with Windows. The rootkit would not be running when I boot from a CD unless it is stored in the BIOS. Or unless it is "magical," as you are leading everyone to believe this one is.
If for some strange reason they can not come up with an easy solution to prevent this kind of rootkit, AMD may have to redesign their virtualization a bit. I know some AMD fans are getting offended that you are targeting AMD processors, but I guess we should be thanking you. It's better that this flaw is known so a solution can be made to prevent it. The Intel virtualization users may go along thinking they're safe, but then one day a really nasty virus will come along and bite them in the ass.
With the processor I have now, I am safe from this because it doesn't support virtualization. But I'm planning on upgrading to a K8L next year, and I really hope this virtualization can be disabled through the BIOS. It sounds like new technology that needs to be thoroughly tested before it's put into mass use.
On AMD64, any attempt to enable hardware virtualization inside a virtualized session will trap out to the top level hypervisor. The current implementation of Pacifica isn't capable of nesting VMs natively.
ReplyDeleteOne way to deal with blue pill type threats is to virtualize the entire system early in the boot process. This could be facilitated by an antimalware driver 'blue pill'ing the OS at boot, by the OS itself, by a custom MBR boot loader, or even by the BIOS. Once this is done, any software that attempts to set up another virtualized session could be trivially terminated before it could take root.
If blue pill-based malware starts looking likely, it would be very surprising of at least one of these countermeasures were not implemented rapidly.
Disable virtualization? Prevent all VMMs from loading after system gets its own hypervisor loaded early in the boot? So, how about asking AMD and Intel politely, that they stop producing processors with virtualization! ;) That should pretty much solve the Blue Pull threat, just like unplugging your computer from network could solve most of the current threats ;)
ReplyDeleteyou write that knowing the code won't help detecting it, and you also wrote that the OS swallows blue pill.
ReplyDeleteif you insert code through the OS it should be possible to monitor (even though that if you missed your chance you won't get a second one once it's run) so I guess you're talking about inserting the code somewhere else. and that is quite intriguing. can you elaborate?
Joanna, simple but important question, can your Blue Pill be able to install itself on the system when you run it with a non privileged user?
ReplyDeleteHope that Microsoft don't do things like switch the processor to "Pacifica mode" to prevent this kinds of rootkits, I'm prefer to get my CPU most optimal as possible and if I need some protection then I use a "blue pill prevention software" in the same way I use anti viruses and anti spywares when I need active protection against malwares.
Regards,
Hernán
Very nice work!
ReplyDeleteI am interested in the presentation you must be preparing for August, 3rd. Will it be possible to have a PDF of the slides ?
Hi,
ReplyDeleteI could not make it to the SyScan conference and I'm afraid I won't be able to see your talk in Las Vegas either. Will you publish more information about your work?
The slides will be posted after the Black Hat conference. Stay tuned.
ReplyDeleteWell /here's/ a question nobody's asked yet, I shall call it "The Dog Whistle Paradox" (not really a paradox)
ReplyDeleteIf it's undetectable once installed, how do you know it worked and didn't just quit? :-p
Seriously tho, some people here seem to be missing some important points. I haven't researched the spec, but some food for thought for people with the repeating questions -
1- Detect it through timings. This may work with software virtualisation, but the whole point of hardware virtualisation is that there is circuitry within the processor to take care of virtual mappings so a virtual machine can run at native speeds. This also goes for counting op count registers.
2- Cannot nest VMs. Really? It wouldn't require too much trickery to get round this problem, for example, using a sibling VM which has memory mapped into the first VM, the VM can appear nested even though it's created by the host machine, leaving it to run at full speed.
3- I can reboot from a bootdisk to detect it. Err, how often do people do this, if they don't already suspect there's something there?
4- What if I disable the vm extensions? Then you're not running on a compatible processor, and this doesn't apply to you.
5- Why? Because knowledge is power!!!
People, get used to technology like this, as people have already spotted uses for it, such as in the TCM/DRM arena (eg, a hypervisor that pushes the OS into a virtual machine and controls what data it can/can't read based on cryptographic keys etc).
Nice work Joanna.
x2A
It does look you not only know your stuff on internals, but you are quite literally a marketing wizard.
ReplyDeleteThe moment you show that Blue Pill works and is not just hype (as some of the security community believe) you can probably write your own ticket (pay, perks, whatever), and should MS not hire you, then they are bigger fools that we hold them for.
I do have some doubts on the transportability to other platforms, but I guess I will have to wait in the queue...
I even don't understand thy hype about all your "Blue", "Red" or "green yagged" pill.
ReplyDeleteIn my oppinion, microcode updates are more - if not the most - dangerous stuff of all - more than virtualizing.
Yet we even don't know what Intel or AMD can do with a precise update of the cpu's microcode - (or what they have done in the last years).
An hacker or upset former employee of those companies can/could put informations about those microcode stuff (gate-arrays, cpu instruction interpreters etc.) onto the net - isn't it?
And - in my oppinion - more dangerous are secret services which - I'm sure - using already microcode updates to create REALLY hidden malware... Not that debug-registers-malformin stuff (try to set debugging points on reading sdt, int 0e etc.)
(Beside of that I understand the source of svv - but it doesn't work with softice - exception in rdmsr. I trust softice + my human intelligence more than an small svv)
Nevertheless, regards
Kevin Root-Ane
Congratulataions to Joanna !!!
ReplyDeleteShe has just been vindicated @ last in Las Vegas @ the Black Hat conference.
Quote -
" After security researcher Joanna Rutkowska on Thursday demonstrated how it's possible to circumvent security in Microsoft's Vista beta software and install a rootkit called Blue Pill, Microsoft said it intends to find ways to stop both potential threats before Vista ships.
At the Black Hat conference, Rutkowska, security researcher at Singapore-based firm COSEINC, showed that she found a way to bypass the Vista integrity-checking process for loading unsigned code into the Vista kernel. Then she presented Blue Pill, a rootkit she created based on Advanced Micro Devices' Secure Virtual Machine, Pacifica. "
-
Microsoft's director of the Windows client group, Austin Wilson, said Microsoft considers Rutkowska's findings "legitimate" and is looking at the problem.
-
"What she showed was legitimate and a very real threat," Wilson said.
http://www.networkworld.com/news/2006/080406-microsoft-blue-pill.html
Etc -
I wonder what her doubters will have to say now, if Anything ?
Spanner
SpannerITWks
I am one of the doubter.
ReplyDeleteAnd I have a way to detect this "100% undetectable malware".
I attended your presentation at Syscan. And I am referring to your diagram where you corrected the timing offset, so as to disguise any time delay when executing the instructions like RDMSR in the hypervisor. Yes you can do it once, and twice. But once you do it a billion times, it will become a time skew, WITH RESPECT TO AN EXTERNAL CLOCK. So to detect the malware is rather easy. And this is the same as detecting execution inside a hardware-based VM. Just execute some instructions which will caused transition to the VM kernel (like RDMSR etc), and do it many millions times over. Comparing a machine with VM to another without a VM, the one with the VM will have more instructions to execute, and thus will be slowed down relatively. But because the clock offset is corrected, timing DURATION of execution appear the same in both system. But if the one inside the VM has excess to an external clock, outside its own host environment, he can measure the SKEW, and will notice that the skew is growing wider and WIDER. Then he stopped executing this instruction completely, but executing another like "INC RAX, PUSH RBP" etc, billions times over. Then he measure the clock timing of internal and external system, and noticed there is no timing skew at all.
This is obvious someone is hijacking these special command, right?
Hi Peter!
ReplyDeleteWe talked about it, and yes, you're right - just as I said during my presentation there are theoretical ways to detected that system has been bluepilled (using externsal clock is one of them) - it's just that I don't believe they might be used in practice for many reasons. So, what should we do about this kind of threats? I don’t have the answer yet…
cheers,
joanna.
Could AMD modify the BIOS to not enable Pacifica technology and block the blue pill?
ReplyDeleteDoes this also affect Intel VT?
Oh, it will be most intresting to create a "protection profile" or "threat model" against this kind of performance.
ReplyDeleteHowever, creating counteraction (lets say, a awareness first to be realistic, shall we?) against threats like this is a summary of multiple information pieces, not only an operating system itself. It requires much more.
Basically, creating "infrastructure beyond infrastructure" sounds similar as altering current to computer transformer, and making it perform activities (like enable/shutdown a single harddisk ;)) based on deviations of electric current ;)
Pilling downlevel, very CORE system instead of apps sitting on top of it, including HW that creates presentation layer for operating system ...sounds intelligent approach.
Lets assume something else. Network components. This is much more "trickier" than implementing pill on operating system, which you are able to touch directly.
Enabling pill via remote, using bolts&dimes enabled by network INFRASTRUCTURE itself (See the word ? It has pressure!) sounds heavily "ultimate solution" approach.
To be short with summarum; good thoughts Joanna!
Hi, Joanna. Congratulations on your malware research results. I'm a guy myself, but it is about time that girls like you who do important research and publish it be properly recognized. It is a pity that your research field is so dominated by guys!
ReplyDeleteIt is also exciting to know you like The Matrix. It is my favorite, too.
I, and I trust a lot of people out there, are very proud of you. Keep up the good work, honey!
Hey Joanna,
ReplyDeleteWith actual testing of rdtsc timing attacks I feel your claims of 100% non-detection of blue pill,even your 'final' version, is totally debunked. Until chip makers have 0 overhead of rdtsc which just wont happen since virtual mode will never be as fast as native mode, you will have SIGNIFICANT measureable skew. Sure you can call this a 'bug' in AMDV but I really dont beleive it is, its just how it is. Its not supposed to be totally stealth. You secondly claim that your #VMEXIT w/ TSC_OFFSET modification can prevent all timing attacks. Id love for you to prove me wrong by your final bluepill work to bypass my little test app...
Best of luck! =)
Chris
http://rootkit.com/newsread.php?newsid=548
Joanna,
ReplyDeletethis is the way to create a base line.
It´s a great pity, that you work in the wrong site.
Tyler D.
Joanna,
ReplyDeleteThe whole Blue Pill concept and your other research topics are quite amazing.
Can you recommend a list of books that could get one started in the field of system internals/computer hardware in general and their security issues in specific?
D
The practical benefits of Blue Pill may far outweigh any negative impacts. To be able to virtualize an entire OS and disk subsystem on the fly is amazing. The technique could be used to sandbox the OS rather than just hijack it. Unfortunately, I'm not knowledgeable enough in these matters to see all the possibilities and permutations that you do. I do know that eventually the truth will come out in spite of all the hyperbole and egos. As to whether your warning will be heeded, that is also for the future to decide. We live in interesting times where little makes much sense except from the standpoint of greed. Security seems to be used more to control people ( and ensure fortunes are maintained ) rather than actually make their lives safer or better.
ReplyDelete