Slashdot Log In
Undetectable Rootkits Through Virtualization?
Posted by
Zonk
on Thu Jun 29, 2006 05:28 PM
from the two-rooted-plants-die dept.
from the two-rooted-plants-die dept.
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."
Related Stories
[+]
IT: Hackers Serving Rootkits with Bagles 150 comments
Iran Contra writes "Security researchers at F-Secure in Finland have discovered a rootkit component in the Bagle worm that loads a kernel-mode driver to hide the processes and registry keys of itself and other Bagle-related malware from security scanners. Bagle started out as a simple e-mail borne executable and the addition of rootkit capabilities show how far ahead of the cat-and-mouse game the attackers are."
[+]
IT: Microsoft Research Warn About VM-Based Rootkits 336 comments
Tenacious Hack writes "According to a story on eWeek, lab rats at Microsoft Research and the University of Michigan have teamed up to create prototypes for virtual machine-based rootkits that significantly push the envelope for hiding malware and maintaining control of a target OS. The proof-of-concept rootkit, called SubVirt, exploits known security flaws and drops a VMM (virtual machine monitor) underneath a Windows or Linux installation. Once the target operating system is hoisted into a virtual machine, the rootkit becomes impossible to detect because its state cannot be accessed by security software running in the target system."
[+]
Ask Slashdot: A Closed Off System? 177 comments
AnarkiNet wonders: "In an age of malware which installs itself via browsers, rootkits installing themselves from audio cds, and loads of other shady things happening on your computer, would a 'Closed OS' be successful? The idea is an operating system (open or closed source), which allows no third party software to be installed, ever. Yes, not even your own coded programs would run unless they existed in the OS-maker-managed database of programs that could be installed. Some people might be aghast at this idea but I feel that it could be highly useful for example in the corporate setting where there would be no need for a secretary to have anything on his/her computer other than the programs available from the OS-maker. For now, let's not worry if people can 'get around' the system. If each program that made up the collection of allowed programs was 'up to scratch' and had 'everything you need', would you really have an issue with being unable to install a different program that did the same thing?"
[+]
Entertainment: Canadian Sony Rootkit Settlement Stirs Controversy 96 comments
An anonymous reader writes "Canadian law professor Michael Geist is reporting
that Sony BMG Canada has quietly kept a key legal document secret as part of
its class action settlement over last year's rootkit case. The
document, which is not on the Sony settlement
site but has now been posted
on Geist's site (pdf), contains a series of bogus arguments about why
Canadians are receiving far less than U.S. consumers."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
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.
Parent
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)
Parent
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.
Parent
Re:Think about what it means if they're right. (Score:3, Interesting)
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:
- They'll do what SubVirt did -- move the VMM which is usually operating as a process on a host OS below that host OS. So, not only are all the guest OSs not going to know a/b the the mal-VMM, but also the host OS itself effectively becomes another guest OS.
- Unlike SubVirt which required that the mal-VMM exploit a vulnerability in the *host OS* in order to do this swallowing-up of the host OS, these folks' claim is that there are generic mechanisms to inject code into the Vista kernel. And these generic mechanisms are sufficient for this subversion.
- Moreover, they're saying that this is the case, despite security mechanisms in Vista that prevent kernel-mode code from running if that code is not signed (by a trusted party).
Anyway these are some pretty tall claims (particularly, re: the ability to inject arbitrary code into the Vista kernel). I initially thought the same thing as the grandparent: that they were saying that you could create a mal-VMM so that any VM running on that mal-VMM would not be able to detect the badness of the VMM (which is pretty trivial, actually).Parent
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: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.
Parent
Re:Before people start the Windows flamefest (Score:3, Interesting)
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: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.
Parent
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!
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.
Parent
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,
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
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)
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
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.
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.
So what? (Score:2)
Virtualisation used for rootkit-safe environments (Score:5, Interesting)
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.
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."
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)
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)
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:5, Funny)
Parent