Undetectable Rootkits Through Virtualization?

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."

Comments

This just reinforces the good old principle

[A beautiful mind]

If your system suffered a successful intrusion, you wipe.

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 /dev/null.

Not much less detectable

[mrcaseyj]

I don't think this changes the situation much. Viruses have always tried to hide. This just requires different methods to detect them. Ultimately some viruses can only be reliably detected by booting off of readonly media. The same now as before. I think OS providers should provide a boot disk for routine scanning as a matter of standard procedure.

Maybe it's time for some new paradigm

[supradave]

Perhaps there could be an OS that wouldn't allow malware to be injected through root-trust, signed applications, memory compartmentalization with read, write, execute permissions and 4 privilege levels (instead of 2). Of course, that wouldn't be Windows or Linux or BSD or any other generic OS.

Re:Before people start the Windows flamefest

[timeOday]

Rutkowska stressed that the Blue Pill technology does not rely on any bug of the underlying operating system.

It's doesn't rely on any bug of the guest operating system, and isn't detectable from the guest operating system. But if something is mitigating access between multiple guest operating systems to hardware, then that thing is itself some sort of minimal operating system, and it is there that the problem lies. As far as the guest operating systems are concerned, this is really more like what would previously have been a hardware hack, in fact it's almost like your healthy computer is running behind a compromised firewall that's sending out the spam or whatever.

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.

Nothing new, really.

[Anonymous Coward]

The fundamental question of systems administration: once you have had a root compromise, what can you do to the machine to get it back up and running, in a known good configuration, with all chances of future compromise as a result of the initial compromise removed?

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.

Think about what it means if they're right.

[khasim]

I don't think they're right. Look at page 3 where they have their diagram showing the VMM in direct contact with the hardware.

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.