Slashdot Mirror
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."
Can't you just take the hard drive out, mount it from another computer, and see all the malicious DLLs the rootkit was trying to hide from you?
If your system suffered a successful intrusion, you wipe.
/dev/null.
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
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
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.
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.
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.
No, the solution is to not give the malware the path to even be able to do this by using a capability-type system.
Please, for the good of Humanity, vote Obama.
I thought this only trapped writes which were done through the BIOS. Modern operating systems deal with the hardware directly. That is much harder to trap.
I'm sure someone will correct me if I'm wrong but ...
:) you shouldn't have said 'I'm sure someone will correct me if i'm wrong' unless you wanted to be corrected.
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.
https://www.gnu.org/philosophy/free-sw.html
A virtual machine can't tell anything about the state of the host it runs on other than what's exposed to it? Isn't this kinda like saying that if you use an oscilloscope to monitor bit flips on the bus, the OS can't detect it? How is this news?
Loading...
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.
There were some motherboard BIOSes that had built in boot sector virus scanning, but they didn't know anything about Free operating systems. A BIOS watchdog wouldn't be any better, most likely. The other problem with virtualization is that it does cause a slight overhead for any protected mode instructions that need to be virtualized. It doesn't help that the x386 architecture has several unprivileged instructions that can easily tell an OS whether it's being emulated or not (see this paper). Timing privileged instructions will also allow a hosted operating system to detect virtualization unless the entire system is emulated, which is very slow.
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.
Problem: Virus / Rootkits are now so good there's no way we can detect them anymore! Reaction: Somebody has to do something about this! We need to be able to make sure something like that doesn't get installed. Solution: Trusted Computing / "Palladium" / "Fritz Chip" -- what they wanted all along. It would surprise me not one bit if the hypervisor root kit was built for people who had exactly this kind of discussion in mind.