Slashdot Mirror
Joanna Rutkowska Discusses VM Rootkits
Unwanted Software writes "There's an interesting interview on eWeek with Joanna Rutkowska, the stealth malware researcher who created 'Blue Pill' VM rootkit and planted an unsigned driver on Windows Vista, bypassing the new device driver signing policy. She roundly dismisses the quality of existing anti-virus/anti-rootkit products and makes the argument that the world is not ready for VM technology. From the article: 'Hardware virtualization, as recently introduced by Intel and AMD, is very powerful technology. It's my personal opinion that this technology has been introduced a little bit too early, before the major operating system vendors were able to redesign their systems so that they could make a conscious use of this technology, hopefully preventing its abuse.'"
Hmm, I guess this 'expert' doesn't realize that virtualization in hardware has been with us since the 80386 first came around. It handled a virtual 8088 quite nicely....
Gahh, NO! You can't force-virtualise my mind!
One of the questions there is
Why should we be worried about stealth malware? Do you see this as a big trend going forward?
To which we received only a half baked answer. Why didn't she say more about this?
Personally, however, I think it's mostly irrelevant to discuss whether this going to be a big trend or not. It's not about whether 100 companies or 100,000 companies are going to be infected next year using targeted, sophisticated attacks using "Stealth by Design" malware (i.e. one which does not create extra system objects) of Type II or Type III. It's about whether we would be aware of those infections at all. We already know it's possible to create such a malware, so we need to do something about it.
46487 466780 252994 376409 96920 39622 205366 244315 622115 512361 668040 63608 259203 955314 811176 652718 166330 23922
I could give a damn what the major operating system vendors are unable to do. I'm more worried about what the hobbyist operating system authors are able to do.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
But honestly, isn't that what drives a market? I know that the jury is still out on this specific technology, and it may never see its full potential... this isn't to say its a bad idea though. Something else may prove to be better.
We are starting to implement VM within our environment, but it is slow going. We do not have anything in live production yet. I know that we are behind when it comes to this, but if we cant put VM into a live enviro, how the heck can we utilize the Hardware virtualization properly??? I know I'm not alone in this.
In software, we used to have a saying, "No program is ever complete, but it has to go to market sooner or later."
Hardware virtualization, as recently introduced by Intel and AMD, is very powerful technology. It's my personal opinion that this technology has been introduced a little bit too early
Virtualization was used in commercial machines as long ago as the early 1970s - IBM's VM/370 product was announced in 1972. The amount of hardware assistance for the virtualization depended on the 370 model. But this was the same kind of virtualization as recently introduced by Intel. You could run multiple different IBM operating systems under VM/370, and you could even run VM/370 under VM/370.
In case you aren't up to speed on your r00tkit knowledge, check out Rootkits: The "r00t" of Digital Evil.
You are missing the point guys! I don't know who she is or what she is selling but if she is a geek and looks like thise /13/0,1425,sz=1&i=135407,00.jpg j pg ;-)
http://common.ziffdavisinternet.com/util_get_imag
http://static.flickr.com/66/206241643_d48861f49c.
I am subscribing to her newsletter.
I think she's mostly right. If you're migrating your OS to a chipset that enables virtualization, you bloody well better make sure code run on top of your OS can't take over and become the hypervising OS. I rather assumed that this was the case, but it seems I was mistaken. Upon reflection, I realize I have no clear idea of how the hypervisor is determined and what it takes to get code running in that mode. My laptop is running OS X with parallels using the VM technology to run Linux and Windows. I assumed that such a new, hack-like implementation would be a security concern, but now I'm thinking there really needs to be OS-level support for VMs.
Part of the issue is, I'm not sure the market will demand this level of security. It is not like users are going to choose the most secure OS, in general, so what would motivate Microsoft to put this in Windows? The other part of the equation is, in order to be wormable, or even useful, the rootkit needs to run on the existing OS. What level of permission does it need? Will running it in an existing hypervised OS stop it, or will it take control anyway? What about running it in a sandbox ala SELinux? OS X 10.5 is supposed to include both mandatory access controls and application signing. The latter should make it harder to insert this, but will the former have any affect at all?
I have had a couple machines infected with non VM based rootkits. Those were bad enough. The only reason I caught them was binaries like netstat were segfaulting. A VM based rootkit would be awful. Servers could run for years with no sign that the host machine is infected.
Seriously, what major OS vendors?
Most architectures other than x86 in common use today either have supported virtualisation for years or don't at all. In either case, the "problem" as described is unique to the x86-64 architecture.
And there's only one major OS vendor there. Almost everyone else is using a kernel which by its very nature is open to all - so as soon as the issue is addressed, it will be available to all.
I think that is taking a somewhat simplistic perspective. It doesn't really matter whether the major OS products make use of virtualization. The entire point of a successful rootkitting is leaving no visible trace of your presence. A well crafted rootkit would take hold from the bootprocess, virtualize the environment and then load the operating system. Thus - who cares if Microsoft, Linux or Apple makes use of virtualization, if the rootkit detects an appropriate target loaded into its context ... BAM, ownership.
The only way true way to detect a rootkit is to shut down a system and reboot from a separate, read-only instance of an OS dedicated for rootkit scans. No business, however, wants to hear that answer given to them as a course of action. They'll question their IT staff why they let the system get infected in the first place. They'll ask how such an action will impact on their financials. And if the scan comes up clean - IT looks like paranoid idiots. If it comes up infected - IT looks incompetent.
~ Matthew Vea
Rootkit Theory @ http://www.omninerd.com/2005/11/22/articles/43
When you understand your disbelief in other gods, then you will understand my disbelief in yours.
Just wrote a VM for the bios and reflash it. Any os installed will run under it and I will have full control. Kind of scary because it would be impossible to detect and malicious enough would be impossible to get rid of unless you throw the whole computer away.
http://saveie6.com/
Anyhow, the scare over hardware-VM-based malware scare is overblown. It was entirely possible to write VM malware without hardware VM support, just as VMware can provide virtual machines using software only, on systems without hardware VM support.
The only way to avoid such malware is to either not let it get onto your computer in the first place, or make sure it's running in a tight enough security environment that it can't get down to the bare metal. If you system isn't secure enough to prevent software from modifying the MBR or OS files, and prevent it from running at "ring 0", there's not a damn thing you can do.
Naturally, Windows is normally installed so that the main user has adminsistrative access, which means that any software he or she downloads can do exactly those kinds of potentially destructive operations.
By contrast, real operating systems are normally installed such that the user is not privileged by default.
Ultimately, it call comes down to how smart and well-educated the end user is. If the malware can trick the user into providing privileged access, all bets are off.
I must admit that my only experience in hardware virtualization comes from IBM AS/400 and RS/6000 environments. But, if hardware virtualization is (mostly) ready on the PC and PC OSes could make use of it, it could hurt PC manufacturers such as Dell.
What I'm getting at is many families are getting multiple PCs in the house now. One (or more) for the kids and one (or more) for the parents. Most of these people are just browsing the web, checking email, low CPU usage things. What if, like on these enterprise class platforms, you could order one PC with a dual core (ore more) CPU, two (or more) keyboards, monitors, mice then slice up the processing power in two then run two OSes and basically have 2 virtual PCs out of the same hardware?
It may not save money just running 2 virtual PCs but if it could run 3 or 4 it should save money once they get into mass production.
Okay, this is slightly OT but someone mentioned that there isn't much use for this technology at the consumer level but I disagree. Of course a rootkit running on top of it all wouldn't be good.
"A government is a body of people, usually notably ungoverned." - Shepard Book Quoting Malcolm Reynolds
Did you hear that? Something like the sound of thousand geek rushing to their bathrooms... Sorry guys, but you know it`s true :p
We use VMware on IBM Blades. Very many other businesses are doing the same. All the CIO management rags are all abuzz over VM. Your workplace is indeed a little behind the times.
You do know that it doesn't matter if people are using hardware virtualization, right? All new Intel and AMD chips have it, whether you use it or not, it's there for a rootkit to exploit.
There are several other VM packages that also use the hardware VM. Xen is one, and it's open source. And in any case, it's not about how VMWare or Xen deal with the new hardware, it's how Windows and Linux deal with it. If mainstream OSs don't take steps to lock down the VM hardware, undetectable rootkits will be the result.
As someone who has worked quite a bit with VMware, let me say that I am more concerned with it's freakish inability to keep accurate time. I've got a cronjob running every five minutes to reset the time via ntpdate. Running ntp on the server won't help, the offset is too random and too large to compensate for. In five minutes between running ntpdate, I've seen clocks be off by a minute.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
I don't see how that is possible. If something is running on top of the OS, it should be subject to the OS.
Something running beneath the OS would be able to control the OS.
The "Blue Pill" stuff she's talking about starts above the OS, but then it (supposedly) moves the OS to a virtual machine while "Blue Pill" takes over the physical hardware.
I do not understand how that is possible. Nor have I seen it demonstrated anywhere else. So far it is just her statement that she has done this.
I don't use any anti-virus products to secure any of my machines. The reason--I just don't like their approach, which is to block only known malware.
Riiiiiight... So, for fear of future threats, we should totally ignore current ones? Why do I not feel inclined to take advice from this person?
Overall, she makes a good point about how vulnerable current systems seem to VM rootkits. I disagree about the recentness of VM tech (we've had it in the x86 line since the 386, and in Big Iron for almost half a century), but yes, we do need some way to protect ourselves from inherently undetectable malware.
There's an interesting feasibility discusison of Blue Pill Here
Isn't the "blue pill" just some almost far-fetched theory?b lue-pill-myth.html
http://www.virtualization.info/2006/08/debunking-
Yep, the rootkit is the host OS and it runs the original OS as a guest OS, on a virtual machine.
I just don't see how she can accomplish that. And accomplish it in an undetectable fashion. Particularly given the state of hypervisors today. If it's difficult to do in a controlled environment today (run Win2003 with SQL 2005 in a hypervisor on Linux and see what hoops you have to jump through and what your performance is) I don't see it being a threat in the wild.
Seriously. If she can do this, then she's just solved EVERY LINUX DRIVER ISSUE.
Instead of worrying that your wireless card is not supported, run her "rootkit" and use the virtualized cards. The same with audio. The same with video. The same with EVERYTHING.
If she can do this, today, every OS vendor should be chasing her down to get the rights to that technology. Their OS's would reference known stable drivers and their functionality would improve.
Does this mean Sony has branched out to include rootkits in VMWare? ;)
*me ducks*
I was a big fan of VM, in particular IBM's version of it back in the 70-80s. It did exactly what we are seeing today - it allowed you to run multiple OS(s) of your choice AND depending on the hardware you had it gave various performance boosts via hardware assists.
BUT, in the long term, I only saw it used as a solution to solving temporary problems. It was used often when customers were migrating from/to other IBM Operating System (DOS to MVS). It was used to temporarily house a new OS build while new hardware was being installed. It was occasionally used as a partitioning tool for application protection. But the simple fact is that the total throughput under VM (or its hardware equivalent LPAR) never matched native performance.
I see over and over again 'new' ideas showing up in PCs that are just a repeat of what the mainframes did 20 years ago. I see no reason to believe the PC outcome will be any different for VM. It will never be mainstream and always just be a solution available and appropriate for a few temporary problems. And yes, the hardware vendors 20 years ago were saying the same things these guys are saying now, about how it WILL be mainstream and will perform etc etc. It never happened.
slashdot troll = you make a compelling argument I do not like the implications of.
You could have it for quite a time, just an example.
But dou you honestly think that anyone would market that? Instead, overtime to buy multiple whatevers is proposed to be the best.
CC.
TaijiQuan (Huang, 5 loosenings)
Quote from "z/OS Workload Manager: How It Works and How to Use It"
The z/OS Workload Manager (WLM) component introduces the capability of dynamically allocating or re-distributing server resources, such as CPU, I/O, and memory across a set of workloads based on user defined goals and their resource demand within a z/OS image. Looking over the fence of the z/OS image the Workload Manager is able to perform this function also across multiple images of z/OS, Linux or VM operating systems sharing the zSeries processor. Another function of the WLM is to assist routing components and products to dynamically direct work requests associated with a multi- system workload to run on a z/OS image within a Parallel Sysplex that has sufficient server resources to meet customer defined goals.
No virtualization here, move along.
CC.
TaijiQuan (Huang, 5 loosenings)
The thing I don't get about the "blue pill" threat, is that I ass/u/me that you have to be running in Supervisor mode in order to install a hypervisor. True?
If no, then it sounds like the virtualization "feature" is really a bug -- a way around the supervisor/user distinction. So yeah, I see a threat, but it's such a glaringly huge and obvious one that I can't believe the designers didn't anticipate it. And that's really what it comes down to: I don't believe it. If anyone tells me user mode is able to install a hypervisor that modifies the execution of supervisor code, my bullshit detector is going to go off.
If yes, then I don't see what the big deal is. If you postulate that hostile code will be run in supervisor mode (so that it can install a hypervisor), then you're screwed no matter what. Virtualization doesn't change the situation much. The fact that it's "impossible" to detect such a compromise is irrelevant, because it's already nearly impossible to provably verify the system is uncompromised. Just because the mainstream relies on malware scanners, doesn't mean the technique's invalidation is significant. Anyone who has thought about it, already knows that searching for malware was never serious security technique.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Before an attack can install something like "Blue Pill", it has to be running in kernel mode. At that point, it already has full control of the machine. The only question is what to do with that control. Installing a hypervisor underneath the OS is kind of neat, but there are lots of other things to do.
What this does demonstrate is that after-the-fact malware detectors are a dead end.
There's a great comment in the article:
The solution (includes) checking all the possible "dynamic hooking places" in kernel data sections.
(This) is actually impossible to achieve 100 percent as nobody knows all those dynamic hooking places, but we could at least start building a list of them. I believe the number of the hooking places is a finite number for every given operating system.
In other words, there is only a finite number of "ways" to write Type II malware of any specific kind (e.g. a keystroke logger).
Now that's a big part of the problem - Microsoft's use of "dynamic hooking", or places where user code can insert callbacks which privileged code might access, is so messed up that security researchers can't even find all the places where it is allowed. "Dynamic hooking" is really a lame method of interprocess communication left over from the DOS version of Windows. It should never have made it into NT/W2000/XP/etc.
There's less of a temptation to do this in open source operating systems, since, if you really need to legitimately add a feature, you can put it in the source, rather than tapping into some binary. The Linux netfilter/ipchains mechanism offers a "dynamic hooking" attack vector into the kernel, though, so Linux isn't immune to attacks of this type.
That's my point. She seems to be saying that this is easy. And that it is undetectable.
Yet when I start pointing out the obvious benefits of her system, suddenly it isn't as "easy" or "undetectable" as it was before.
No. When the guest OS's have direct access to the hardware such as the video card or network card, the "threat" breaks down.
If my "cracked" OS has direct access to the NIC, then I can monitor what is sent over it. I can tell if the "Blue Pill" has cracked my box and is calling home.
If I do not have direct access to the hardware so that I cannot monitor it, then she has solved the Linux driver issue.
Yes, I know. Next will be the "you only have some kinds of direct access to the hardware". No. In order to limit that, her crack needs to know how to talk to that hardware so it can intercept the calls the "cracked" OS is making. Any control of the hardware by her "Blue Pill" means that she has solved the Linux driver issue for that hardware.
That is why the OS's need "drivers" to talk to the hardware peripherals.
... when I ask: Is she HOT ?
We are Turing O-Machines. The Oracle is out there.
Check out the BluePill presentation here:- 06-Rutkowska.pdf
... Clearly _real_ OS design and security aren't her specialty.
http://blackhat.com/presentations/bh-usa-06/BH-US
Basically the whole thing about it being able to subvert the OS is based on an inherent security problem in the way Vista handles direct block access. This is just basic OS architecture. If the OS won't load anything but signed driver but will still allow anyone to write anything to the swap area, then that's just an insecure OS. Because even if it wasn't some virtualization thing that was getting loaded, then page file modification would be a wonderful attack vector for lots of other stuff.
Unfortunately media has focused way too much attention on the "virtualization" part of this stunt, but reporters were probably not smart enough to understand that the blue pill thing actually exploits a intrinsic weakness of Vista (and she hasn't really made an effort to dispell that -- on the contrary, she's claimed from day 1 that the exploit isn't based on any OS flaw or weakness, which left me scratching my head until I finally got my hands on her presentation and discovered this part of the claim is bull). Fortunately for MS, though, it seems that they have smart engineers because as she admits in the article refered to in the Slashdot summary, they've made the page file out of reach. She, though, continues to think that this is somehow the wrong answer (as she hints in her presentation)
Joanna ROOTkowska
It's lame, predictable, and not even that funny. Please, please, just for once don't reward this shit?
How the malware instruments the system is to place traps in code paths of the guest system. So the hypervisor could temporarily take control during a TCP/IP queuing operation and copy buffers into it's own personal private area... and it could leak that information out later (replacing "leaky" outbound backets, say DNS or ARP, with this key information before they get checksummed).
You could detect this using timing tests, but it's not reliable. You need a good "before" profile which may be impossible to obtain if you don't know when you got hacked.
Of course, one thing she doesn't mention is that none of this matters if the hacked system is already a guest. I wouldn't deploy anything on a Pacifica or Vandermode-enabled platform without making sure some hypervisor is in place before my "primary" OS install.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
It has more to do with concepts like Xen 3+ or VMWare ESX server, specifically.
On your hardware assisted virtual machines, your guest OSs run "native", in that you can give them access to actual hardware and they directly manipulate page tables. A hypervisor makes it possible for more than one guest (with an associated group of tasks, GDTs and LDTs, etc.) can feel like they have the whole box. You can emulate hardware that you can't or won't dedicate to each guest (say a common network interface, iSCSI volumes that look like IDE drives, etc.)
What Blue Pill does is carry its own tiny hypervisor, and if the guest is running "normally" on the system, it can assert the hypervisor role and do so in such a fashion that the OS still has access to everything, and notices nothing.
Yet the hypervisor could set breakpoints, change memory behind its back, etc. without the host (now guest) knowing any different.
Of course, if you are ALREADY running a proper hypervisor on a hardware-VM capable system, then Blue Pill won't work.
So the answer is: play with Xen more. Learn about other hypervisors. And don't deploy anything critical on a hardware-vm capable box without a simple hypervisor already in place.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Major operating systems aren't ready for virtualization? We could have used virtualization five years ago.
The only OS that has any sort of problem with virtualization is Windows, and there is no reason to believe that Microsoft would have suddenly fixed thingsif hardware virtualization had been put off for another 5-10 years.
http://outcampaign.org/
Blue Pill is bullshit. Don't believe me, believe the experts:
u asi-illiterate.htmlb lue-pill-myth.html
o Keith Adams, of VMware fame (binary translation and Intel VT work): http://x86vmm.blogspot.com/2006/08/blue-pill-is-q
o Anthony Liguori, of Xen fame (paravirtualization work): http://www.virtualization.info/2006/08/debunking-
Vista 64's driver signing system is touted as preventing rootkits. Security researchers trust Microsoft that driver signing will help with this. However, as the parent poster says, once code is running at supervisor level it's all over. It's absurd to try to make administrators not administrators. Also, why are corporations magically trusted but not the computer's owner?
The whole thing is really about DRM, protecting wmplayer.exe from debuggers' eyes. (Of course, you could just virtualize the whole OS and dump out data from the sound card that way, regardless of any stupid driver signing...)
I am still angry at Joanna. When she presented at Black Hat, she stated that she was in favor of Vista 64's driver signing, and presenting it was a way to get it fixed. I was incensed, because I'd discovered the same hole independently (before her presentation but after she'd found it), and wanted to wait until after Vista's consumer release to do maximum credibility to Microsoft. I didn't even code it - I described the whole thing in 1 sentence, and any competent NT programmer could have implemented it. On the Xbox Linux Team I fought for years against operating systems' use of digital signatures to restrict whose programs you can run; I wasn't about to help Microsoft do that for Vista.
Guess what the result of her presentation is: user-mode programs, even Administrator/LocalSystem, cannot raw write to disks in Vista. This is going to be loads of fun for disk utilities. Suddenly they have to be made by corporations, and the entire utility must be in kernel mode or it will break the driver signing "security".
Microsoft has already stated their intention on MSDN that in the next version of Windows, only corporation-signed programs will be able to run as Administrator regardless of the wishes of the computer's owner. Microsoft wants to make all PCs into Xbox 360s.
I found two more attacks against their digital signature system, and like hell am I going to tell them (or anyone else). Since I now know it's DRM related, it would be a felony for me to disclose it to anyone but Microsoft, and I'm not going to tell them.
Melissa
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
"Blue Pill is the prototype resulting from a security study made by Joanna Rutkowska, which took advantage of new virtualization capabilities of AMD processors (known as SVM and previously as Pacifica) to inject a rootkit in a running Vista operating system"
q uasi-illiterate.html">undetectably" compromises your chain-loaded host. Recall with me the fundamental theorem of VT/SVM: "VT and SVM make nothing possible that was not possible before."
When people have to resort to abuse to support their argument it makes me suspect that they are trying to distract from the facts. Adams don't actually debunk blue-pill, he calls the research quasi illiterate gibberish and accuses the researcher of attention-whoring, what ever that is. Nothing in the two cited articles provides any actual technical information as to why the injection technique wouldn't work.
"The non-exploit consists of a boot-loaded VT/SVM hypervisor that "http://x86vmm.blogspot.com/2006/08/blue-pill-is-
But one of the alleged benefits of VM was total isolation of the client OSs. If a VM machine can't protect a client OS from malicious processes then what is it for. Answer me that one and name calling don't count as a valid response.
key words: attention-whoring, quasi-illiterate gibberish, Re: "Blue Pill" is quasi-illiterate gibberish.
davecb5620@gmail.com