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."
Is it *really* undetectable? (Score:1, Insightful)
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
Not much less detectable (Score:5, Insightful)
Maybe it's time for some new paradigm (Score:4, Insightful)
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:Is the solution DRM? (Score:2, Insightful)
Re:Motherboards already block this... (Score:2, Insightful)
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.
So let me get this straight... (Score:3, Insightful)
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 (system management interrupt). This
> is a *very* non-maskable interrupt (more non-maskable than NMI...)
> that causes the processor to save pretty much all its register state
> in a special memory area, and jump to a handler in the system BIOS.
> The BIOS SMI handler examines the saved register state, figures out
> what the OS was trying to do, runs a software model of the PS/2
> keyboard controller's state, chats with the USB keyboard, formulates
> an appropriate response, emulates the I/O instruction the OS was
> trying to do, and resumes execution of the OS at the instruction
> following the I/O instruction.
>
> Some chipsets might do it directly in hardware rather than using
> the SMI+BIOS strategy.
http://groups.google.com/group/comp.os.plan9/brow
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]
Re:Virtualisation used for rootkit-safe environmen (Score:2, Insightful)
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.
Another Problem Reaction Solution (PRS) triple: (Score:2, Insightful)