Undetectable Rootkits Through Virtualization? 237
techmuse writes "eWeek has an article about a prototype rootkit that is implemented using a virtual machine hypervisor running on top of AMD's Pacifica virtualization implementation. The idea is that the target OS, or software running on it, would not be able to detect the rootkit, because the OS would be running virtualized on top of the rootkit. The prototype is supposed to be demonstrated at the Syscan conference and the Black Hat Briefings over the next month."
Before people start the Windows flamefest (Score:4, Informative)
fta:
Rutkowska stressed 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," she added.
Let's make this a bit easier to understand. (Score:5, Interesting)
This is not really different from running WinXP, then installing VMWare Workstation, then installing Win2K in a virtual machine.
The "host" OS is what gets infected. That would be WinXP. Of course nothing running in the "guest OS (Win2K) would be able to detect it. But
There are only three (3) ways for the "underlying operating system" to be infected.
#1. Worm
#2. Virus
#3. Trojan
If we aren't talking "nude pictures of celebrities", then it's either a worm or a virus and both of those are bugs in the OS.
If it's a trojan, then WTF are you doing installing unknown apps on the host OS?
Now, the only way this would be interesting would be if the worm / virus / trojan installed the virtualization software, moved the existing OS to a virtual machine and faked the names of all the interfaces (NIC, IDE controller, etc). If you can do that, VMWare really wants to talk to you.
Re:Let's make this a bit easier to understand. (Score:3, Insightful)
There are only three (3) ways for the "underlying operating system" to be infected.
There are only two ways, and you got them all wrong.
1. User/administration Error.
2. Programmer/Developer error.
any remote vulnerabilities fall under 2, and any configuration errors fall under 1.
Re:Let's make this a bit easier to understand. (Score:4, Interesting)
Think about what it means if they're right. (Score:5, Insightful)
Here's a simple test to see if they're right.
Put in a NIC that your host OS does not have drivers for. Your host OS will not be able to connect to the network. Now, if the virtual machine in their example can access the network, then they're correct.
There's no end of hype for "threats" that never seem to materialize (or are vastly over-stated). If they can do what their diagrams indicate, then this would revolutionize the computer industry. I really mean that.
For example, you would NEVER again have any problem with wireless networking under Linux. Or sound. Or any peripheral. Or hardware accelerated video. No more nVidia drivers needed! The VMM handles it for you!
So, no, I don't believe that what they claim is actually what they can deliver.
Re:Think about what it means if they're right. (Score:3, Interesting)
Re:Think about what it means if they're right. (Score:2, Interesting)
Intel's latest VT technology in Intel Macs assists in running an OS in a virtual space and allows that OS to directly (or transparently) access the hardware. AMD is working on a very similar technology that would allow the exact same hardware-accelerated VM. From Intel's Press Release: "Provides headroom for more robust hardware-assisted virtualization solutions." ( source [intel.com])
The summary's mention of "AMD's Pacifica virtualization implementation" seem
MOD PARENT UP, he's right. (Score:4, Interesting)
Grandparent seems to think that BluePill merely is a mal-VMM that sits between any guest OS and the host OS. So the guest OS won't know that he's being thwarted. What these folks are claiming is two-fold:
Pacifica doesn't emulate hardware (Score:3, Informative)
The goal of the Pacifica technology is to do the virtualization in the hardware to avoid the need to emulate devices. Microsoft's Virtual PC product is forced to emulate a particular network card (an old Intel 10mbit card, if memory serves) and then translate usage of that network card to calls to the NT device drivers for the real network card. Under Pacifica, the virtualized system talks directly to the real network card and the hypervisor software (which runs beneath the OS kernel) co-ordinates the diffe
Re:Let's make this a bit easier to understand. (Score:2)
Can someone please mod this guy down for not reading the article? It says:
Re:Let's make this a bit easier to understand. (Score:2)
Actually, the rootkit itself would serve as the host OS and the virtualization software as one.
This is not as much work as it may seem, because most functionality could simply be "leaked through" from the physical machine to the virtual one. The only functionality that the rootkit would fake would be stuff it used, such as the hard drive (to hide it's files, for example) and then whatever else it does (for example, it might have it's own network connection to a remote server, and then it would have to ma
Re:Before people start the Windows flamefest (Score:5, Insightful)
Getting to the point, people act as if virtualization simplifies things, But really it's an additional layer of abstraction and complication, another mass of code and/or hardware to go wrong. Now there will have to be software tools to manange this new underlying minimal OS, and maybe virus/rootkit software. I think the applicability will be limited.
Re:Before people start the Windows flamefest (Score:3, Interesting)
Re:Before people start the Windows flamefest (Score:2)
There might also be some flags you can read, dunno.
Re:Before people start the Windows flamefest (Score:2, Interesting)
There might also be some flags you can read, dunno.
There are a handful of processor instructions which behave differently under virtualization without causing a privilege fault. Not causing a privilege fault is crucial, because that would allow a malicious
Re:Before people start the Windows flamefest (Score:2, Informative)
Re:Before people start the Windows flamefest (Score:2, Informative)
It has no feasible way of detecting this because the host OS runs exacly as it did before completely oblivious that its not sitting on raw hardware.
There is no spoon.
Re:Before people start the Windows flamefest (Score:2)
Re:Before people start the Windows flamefest (Score:2)
Re:Before people start the Windows flamefest (Score:2)
The OS is running in the environment provided for it by the rootkit, just as a guest OS runs within VMWare or similar. In exactly the same way that the guest OS doesn't know it's being hosted by VMWare, in this case the rooted OS would have no idea it wasn't on the raw hardware.
There are plenty of valid reasons to criticise Windows or praise Linux/BSD, but this isn't one of them.
Re:Before people start the Windows flamefest (Score:2)
Re:Before people start the Windows flamefest (Score:2)
said this before (Score:5, Interesting)
ok, but... (Score:3, Funny)
Re:ok, but... (Score:2)
Everyone but you... (Score:2)
I don't know about your company, but I work for a giant Fortune 100 multinational company, by far one of the largest and most profitable and recognizable ones in the world. I'm very familiar with our computing environment, and I can tell you with absolute certainty that running applications on virtual machines is not only common here, it's a very important part of our future.
Yes, real applications, the kind that are business critical.
Is it a smart move? Maybe yes, maybe no. If you want to argue about
Re:Everyone but you... (Score:3, Funny)
Yes, gone are the wonderful days of yore when one used to be able to pass the time while the network was down by "sending an email."
Re:Everyone but you... (Score:2)
Re:Everyone but you... (Score:2)
First of all, I reiterate that I wasn't arguing for virtualization, I was merely stating that it exists and will continue to grow in the future.
Second of all, if your network goes down twice a week, then your IT people are incompetent idiots and should be fired immediately. (Sorry to have to break it to you. I hope I'm preaching to the choir.)
Third of all, remote computing and virtualization are not the same thing. In fact, they have nothing to do with each other, unless one of your virtual servers h
Re:ok, but... (Score:4, Interesting)
Technology finance will cretae some bizarre technical solutions, if sombody in the organisation doesn't put the brakes on - another good example is "hmm terminal server runs all the same apps that native desltops do for the remote workers - let's just issue everyone a Windows TS "device" and host everyone's sessions inside a big servers in the data centre - it's cheaper, and there's no difference right? This is where someone gets to try and explain latency, and how it's different from "bandwidth", to an accountant
It's not new either - mainframes have operated like this for years. IBM would have you create your entire data centre inside z/VM - including the routers, switches and firewalls. It's great for development and testing - need more Linux/Apache/WAS/Oracle servers? sure just wish 3 more into existence, re-test your fancy shmancy clustering and treacle bending widget, and then bin them off again with another wave of the virtual wand.
We have clusters of Websphere AS inside one LPAR - not for speed I hasten to add - that would be silly, but to create resilience, seperate the Java VMs and add flexibitlty for software releases.
Re:ok, but... (Score:2)
Re:ok, but... (Score:2)
People used to be able to recognize the tone and voice of the written word.
Sigh.
Re:ok, but... (Score:2)
Because you're typing, and you forgot the ;-)
;-)
Re:ok, but... (Score:2)
See? Works every time.
Re:ok, but... (Score:3, Funny)
--> The Joke <--
--> Your Head <--
the side effects are detactable (Score:4, Funny)
Boss asks: are you playing games at work?!
Me: Just checking for rootkits boss!
Re:the side effects are detactable (Score:2)
Motherboards already block this... (Score:5, Informative)
If you have this on your motherboard I highly recommend you turn it on, it isn't too often that you reinstall the OS and pressing F9 isn't that much of an inconvenience even if you did it once a day.
PS - All of the "My favorite OS is secure" posts below this are wrong if the Operating System supports some type of driver, or root program (running in the kernels memory space).
Re:Motherboards already block this... (Score:5, Informative)
This offers at best a partial protection. While the MBR is important, the actual boot is done from the partition boot record, mot the master boot record, and this badly named feature is not going to help against that. Why badly named? because it does monitor (attempted) changes to the bootrecord and doesn't know anything about viruses.
Next. even if you could protect against that, things just get a bit more OS and possibly OS version dependent because you have to move to the file that gets loaded by the partition bootrecord.
Oh, quite a few 'boot managers' change the mbr on every boot.
So while it offers some protection, that protection is extremely limited, and can be quite inconvenient.
Re:Motherboards already block this... (Score:2)
Re:Motherboards already block this... (Score:2, Insightful)
Re:Motherboards already block this... (Score:3, Interesting)
There was a proof of concept virus that has the ability to use the ACPI interface to take over the BIOS.
If you could that virus with the root kit that uses virtualization, the computer is now completely hosed. The only way to fix it is to flash the BIOS, and if it first takes over the BIOS and prevents the warning dialogs then virtualizes the OS, you now have an incrediably powerful malware that can only be stopped when it is run on the computer. If you don't detect the malware out the gate,
Re:Motherboards already block this... (Score:2)
This just reinforces the good old principle (Score:5, Insightful)
Of course, there were LKM rootkits (pretty hard to detect) for a good while now, this is just taking it to an all new level.
I wish the spread of better hidden rootkits on Windows, because only that will further sane security policies and wipe the stupid idea of virus scanners out (when it's doing IDS not IPS). There ain't such thing as 'intrusion removal'. It's like putting on a condom after sex. Oh wait, it's slashdot. Let me rephrase. It is like trying to recover data from
Re:This just reinforces the good old principle (Score:3, Insightful)
Many a BIOS already contains a pile of crap
ACPI
USB
IPMI 2.0
SATA
Infiniband
On the GX2, the BIOS is a message-passing microkernel that lives in SMI !
Wonder how your USB keyboard can be used before the OS is loaded
> The implementation is chipset dependent. Often what happens is
> that the chipset recognizes an I/O request to port 0x60 or 0x64 and
> aborts the request with an SMI (sys
Re:This just reinforces the good old principle (Score:2)
So you're saying there's a '/dev/random/' for sex that will (eventually) work?!
-
Re:This just reinforces the good old principle (Score:2)
Re:This just reinforces the good old principle (Score:2)
Funny, that's how I think of my wife too.
Re:This just reinforces the good old principle (Score:2)
A win-win situation for everyone (Score:3, Funny)
From TFA:
Not much less detectable (Score:5, Insightful)
Maybe it's time for some new paradigm (Score:4, Insightful)
Re:Maybe it's time for some new paradigm (Score:2)
Well, OS/2 (0/2/3) and Linux on Xen (0/1/3) both use 3. If you can take control of the hardware via a Xen-ed kernel, now that would be one for the hacker hall of fame.
Re:Maybe it's time for some new paradigm (Score:2)
It certainly is possible to make an OS use more than 2 privilege levels on x86 (a dude I knew in college modified Linux thusly; lots of very frequently-used kernel code and drivers needed modification and IIRC all the userland programs were unmodified because it all runs in ring 3 anyway). As far as portability goes... Linux wa
Re:Maybe it's time for some new paradigm (Score:2)
The multiple ring architecture was a Multics thing. I think VMS also used it, and it's also used by QNX (at least some builds of it). Xen runs guest OS's in ring 2.
I'm told AMD64 doesn't have rings 1 and 2 in 64-bit mode.
Re:Maybe it's time for some new paradigm (Score:2)
AST used your same argument, saying that Linux wouldn't be popular, partly because only people with 386 processors could use it.
You just need to make it available for reasonably widespread hardware.
Real Beneficiaries of Hardware Virtualization... (Score:3, Interesting)
Is this a "root kit"? (Score:3, Interesting)
While the subject is scary (Score:2)
Is this really a surprise? Given the layered design of software, if you have something that can sit between the hardware and the software (and monitor what passes between, and control said information), they why would it not have complete control? The question is how could this easily be placed on someone's machine? The next question is why can a level of virtualization be introduced between the operating system and the hardware during execution?
"your operating system swallows the Blue Pill and it awake
Re:While the subject is scary (Score:2)
Not that the average Windows user would find yet another spontaneous reboot any particular cause for concern, but I admit it would be cool.
Brilliant (Score:2)
livecd (Score:2)
Running everything off a livecd is a good idea since most infected pc's are as slow as a 486 and could take hours to days to scan. In this case it would be ineffective.
I wonder if bios virii are next/? Its the only way to go above even booting off a pc and some malware and spyware makers are working on this. That way it can't be removed at all.
Re:livecd (Score:2)
Thank God. I feel so much better now. I hope they roll that into Defender.
Towards a runtime for Voight-Kampff machines (Score:3, Funny)
Microsoft (Score:2)
Because, y'know, the only way to protect yourself against attacks like these are with Trusted Platform Modules.
20 bucks Microsoft sponsored this research in some way.
Re:Microsoft (Score:2)
So what? (Score:2)
TPM (Score:2)
The bad side of the TPM is when you lose control of it - then the machine isn't yours any more but the xxAA's.
Virtualisation used for rootkit-safe environments (Score:5, Interesting)
Re: Virtualisation used for rootkit-safe environme (Score:2)
Or the watchdog could use a similar exploit to jump above the rootkit and look down to see what is running. If we're nested one level too deep then we've got a problem.
Assuming of course we can nest. If we can't, the failure to nest would show the problem.
Or you could always run something using heavy 3D, and if the CPU ignites then something's up.
Re:Virtualisation used for rootkit-safe environmen (Score:2, Insightful)
Ob. Tron (Score:3)
ALAN
It's called Tron. It's a security program itself, actually. Monitors all the contacts between our system and other systems... If it finds anything going on that's not scheduled, it shuts it down. I sent you a memo on it.
DILLINGER
Mmm. Part of the Master Control Program?
ALAN
No, it'll run independently. It can watchdog the MCP as well.
Re:Virtualisation used for rootkit-safe environmen (Score:2)
Whoa. Déjà vu. (Score:5, Funny)
"It's a glitch in the rootkit! It happens when it changes something!"
"No, I said a SLASHDOT article."
"Ah, you're probably fine then."
Once untrusted software is run on your machine... (Score:2)
So let me get this straight... (Score:3, Insightful)
Bah, humbug! (Score:4, Informative)
Exactly the same thing was done using the ancient "cookie monster" program on Multics, long before Unix was even a gleam in T&R's eye.
The perpetrator created a user-ring instance of a user (a virtual-machine-like process), loaded in the cookie mosnter, then loaded the command interpreter and handed the result to an unsuspecting user, my boss.
He searchrd high and low, never suspecting the program that kept saying "Want cookie!" was down below the shell.
--dave
Re:Bah, humbug! (Score:3, Interesting)
Undetectable to software maybe (Score:2)
Re:Undetectable to software maybe (Score:2)
DRM? (Score:3, Funny)
Nothing new, really. (Score:5, Insightful)
Answer: either compare the system (booted from known good media) to a known good set of files, or reinstall from known good media.
There's no other answer. Any tools you run on the compromised system are by definition suspect; they might be good, or they might be compromised. You have no way of knowing; anything they tell you is suspect. Even if you have tool binaries that you know are good, you don't know that the data they're gathering reflects reality or has been altered to give you a wrong impression.
So the fact that this software is undetectable doesn't really change anything; you're still finding out about the compromise through unusual activity, so that's 'status quo'. The only thing that's different is the layer that's compromised.
The interesting question is how the software gets in place in the first instance to compromise the system. The answer is that it was run as root (or administrator, or supervisor, or whatever the super-user is called). How did it get root privileges? Two possible answers: (1) a flaw in the OS (defined as the kernel, and any processes running with root privileges); or (2) the end user ran it somehow as root.
In the first case, it's the standard security problem. The OS is flawed; anything can get root. That's a bug. In the second case, it's end user stupidity. Nothing you run as an end user should require root privileges. (If the OS is designed in such a way that you do, again, that's a flaw in the OS. If the application expects it when it doesn't really need it, that's a bug in the application, and the vendor should be shot.)
So there's another layer the rootkit can hide in. Be still, my beating heart! This is, and remains, nothing fundamentally new. [acm.org]
What's that you say? (Score:3, Funny)
Let me guess... (Score:2)
As I understand, a likely initial vector is... (Score:3, Interesting)
Actually quite detectable (Score:3, Interesting)
So how do you exploit this to detect that you're in a VM? If you're an operating system, the easiest approach is to disable interrupts periodically and wait out a few time slices. You would then compare wallclock time and see if you're wait took longer than you expected it should. If it did, you're being pre-empted. With interrupts off, that's a sure sign that you're in a VM.
The above is a general solution to the problem. It's funny the author used SVM (a.k.a. Pacifica). SVM has a feature called dynamic attestation. This essentially introduces an unemulatable instruction that one can use precisely for the purpose of determining whether you're in a VM or not.
Re:The only defense (Score:2)
All thr AV companies have labds where they make new exploits. Then design a way to detect that TYPE of exlpoit.
Besides, have software to protect your systems helps with the know problems bouncing around out there even if not the zero day ones. Fortuasntly there aren't a lot of zero day issues.
Re:The only defense (Score:2)
Not true.
Many detection tools will look for specific signatures of known exploits. Thus this part of the detection will not detect anything else. We're in agreement up to this point.
However...
There are other means of detection. One can look to see if certain system calls have been hooked
Re:The only defense (Score:2)
It'll always be possible to find something that the code won't detect. All anti-virus software does is adds another step to the virus development process.
Re:The only defense (Score:2)
It'll always be possible to find something that the code won't detect. All anti-virus software does is adds another step to the virus development process.
Absolutely.
Having said that, you don't always have access to all versions of AV solutions (some do cost and a malware author might not find a warez version), and all research-in-progress at universities, AV labs, and whitehat/blackhat circles. Not all of
Re:The only defense (Score:5, Funny)
Re:The only defense (Score:2)
Windoze has a half life of 12 minutes but other OS don't. Can you name a Linux, BSD or even a Mac worm that's managed to escap
Re:The only defense (Score:2)
Re:The only defense (Score:2)
Re:The only defense (Score:2)
Yes, but how do you know that your drive or image hasn't already been infected?
Re:Is the solution DRM? (Score:2, Insightful)
Re:Is it *really* undetectable? (Score:2)
But I think the problem is since the bootloader is putting the entire OS into a virtual machine there are not infected dlls to speak of. Heck... Bootloader might even use a filesystem you can't read, but you should be able to still see that extra partion or MBR whatever the highjack OS is using.
BootCD (Score:2)
Re:Is it *really* undetectable? (Score:2)
If the entire drive is encrypted, then either you encrypted it (which means that you should be able to decrypt it) or you didn't encrypt it (which is pretty much a sign of foul play).
Re:The virus must use some memory (Score:2)