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."
Implementing malware with virtual machines
So, just as you would expect, the future of having CPUs with hardware support for virtualization will be wonderful for preserving absolutely perfect security and cloaking for rootkits and their owners. In fact, thinking of why a certain class of non-blackhat beneficiaries would very much like such a possibility, this could be why both Intel and AMD are planning to ensure that all future CPUs, including even those in ordinary non-server desktop PCs, will have compulsory (permanently enabled) hardware support for virtualization. You know the routine - think of the children etc etc.
Technically it's not rooting an OS but actually is almost it's own OS (hypervisor actually) that is running the OS in a virtual machine. Couldn't you get the same effect by hacking BIOS?
--- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
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.
Sadly, and in a large part due to the way commercial IT is funded, this can actually look good on paper - to the technology accountant: "as many servers as we like, that can be created and destroyed at will? Yes please". We also need virtual finance teams, virtual staff, virtual customers - hell don't bother running a real business at all - just model the entire thing, and play it like a RTS sim - with your score linked directly to the corporate stock price!
:D "yeah but we just paid for a 1 Ooodlegig/s line - it'll be super quick!"
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.
Can't the same trick be used to make a rootkit-safe environment? Launch a watchdog application and let that watchdog application launch the real OS in a virtualized environment, as soon as a rootkit wants to fiddle the watchdog application takes notice and there would be no way for the rootkit to either detect or by pass the watchdog. Or even more drastic, launch each (or most) process in a virtualized environment, would probally be a little slow, but should provide a extremly secure OS.
I wonder if you would be able to detect these things by, say, keeping log of the relative offset from address 0 of actual physical ram of the box of say, the top of the kernel stack, or start of userland. If this number changes and there was no mitigating software installed, you might be able to suspect you are running in a VM.
Well yes and no.
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, then you may or may never know that you have a problem.
The problem that computer security is having is that the people that can develop this stuff are not stupid. And it is rather hard to forecast what is going to happen with out knowing what the malware people are planning on.
Essentially this problem is going to result in the implementation of signed code for anything that runs outside of a very limited sandbox. Frankly, I think that we are going to see an era of virtualized everything -- where the hardware runs a hypervisor, with a master kernel, and everything else runs in the context of a virtual machine that groups simular resources. Unsigned code would then be run inside of its own virtual machine using a microkernel that links to the master kernel. Or something like that.
The views expressed are mine own and do not express the views of my employer.
I haven't read about it in detail yet, but from what I've gathered the virtualized OS does not have permission to call the virtualization operations. Thus you should be able to detect if the OS is virtualized by trying to call one of those functions.
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 hypervisor to "step in" and hide itself. Even if the malicious hypervisor patches the host OS kernel and standard apps so that the OS cannot itself detect virtualization, it should be possible to load a "detector" application which uses these instructions to detect the problem. Of course, an effective implementation of such a "detector" utility would depend on the sophistication of the malicious hypervisor's countermeasures. The basic idea is presented in a paper from Rutkowska herself, aptly named "Red Pill".
- T
You are correct that the host OS would have to have drivers for the hardware on the machine in order to even have a prayer of success, but this problem is vastly easier for malware than for commercial software. For malware, they only need to be successfully installed on a small percentage of the machines they attempt to compromise, and they only need to be good enough to avoid detection by lazy users. They won't be able to virtualize hardware accelerated video, I'm sure, but how does that affect a user who is just using a non-accelerated onboard video card? All the VMM needs is a decent enough driver to support the resolution/color depth of the original machine and the user will likely never notice. A commercial product couldn't get by with only supporting 30/40/50% of the hardware out there.
;) The people that would never notice this issue would probably be just as easily duped by a standard trojan. The only real significance is that this is harder to catch with AV software and harder to remove if found.
I also agree that this threat is overstated. Most users would at least notice that something wasn't right with their machine and dig deeper. I know for sure that I would notice if my Linksys wifi card suddenly became a RealTek Ethernet card
...the virtual hardware drivers. The driver software which is part of the vm management software is by definition standardized and thus a prime target for attack. It also operates below most antivirus software so if an exploit can be found in the virtual hardware, it concievable could leap from the virtual machine into the host operating system. At least that's the way I understand the process.
The problem with quotes on the internet, is that nobody bothers to check their veracity. -- Abraham Lincoln
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).While I didn't RTFA, I would like to inject my two cents:
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)
The summary's mention of "AMD's Pacifica virtualization implementation" seems to suggest that this proof-of-concept "virus/worm/whatever" is very similar to a virtual machine but with the major exception that it utilizes a technology in hardware that is not widely adopted -- yet. Being that the software itself does not have to virtualize the environment and instead taps hardware means that it could potentially be very small compared with a 100+MB download of VMware, and its size and ease-of-distribution (potentially within a worm/virus/trojan/rootkit/etc. could make it a huge, undetectable threat; however, if the user beats the virus to the lowest-level VM (i.e. direct access to hardware), it would be impossible for an infection to be completely undetectable.
I heard about the Cookie Monster program from a Honywell/Multics engineer while he was installing our system. He said that in one case, someone had managed to get it to run on the system console, which in those days was a paper printer/keyboard, not video. Every so often it would print out "I wanna a cookie!". The operators would just laugh and type in "cookie" to make it stop. But *this* particular implementation shortened the time delay every time it demanded a cookie, and before long it was demanding cookies faster than the operators could type... I think the fix was to deliberately crash the system, then bring it up in the bootloader to clean out the cookie program.
A key point about virtualization (even hardware virtualization) that people miss is that it does not guarentee that programs run as they normally if those programs are timing sensitive. This isn't a new revelation. If you go back to the Popek/Goldberg paper from the 70s, they make it quite clear.
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.
> That could be loads of fun for a honeypot system - dozens of infected VMs, each thinking it's at the top of the heap, owning the hardware and talking to all the other infected VMs.
This is not altogether different than what Symantec AV already does, which itself is not too different than "fakeroot", which is commonly used by Debian. It doesn't totally virtualize, but it basically sandboxes a suspected virus while not letting it know that, and lets it run for a while to see what it's up to. It's just about the only way to find the payload of some of the nastier polymorphic viruses, and the researchers let it run that way on lab machines for as long as they can (and incidentally, Symantec researchers do not use the term "virii"). Some newer viruses can get wise to this trick, but those countermeasures themseves are suspicious enough to cause immediate quarantine.