Slashdot Mirror

← Back to Stories (view on slashdot.org)

Undetectable Rootkits Through Virtualization?

Posted by ryuzaki0 on 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."

7 of 237 comments (clear)

  1. said this before by dknj · · Score: 4, Interesting

    Implementing malware with virtual machines

  2. Real Beneficiaries of Hardware Virtualization... by Anonymous Coward · · Score: 3, Interesting

    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.

  3. Let's make this a bit easier to understand. by khasim · · Score: 5, Interesting
    I'm sure someone will correct me if I'm wrong but ...

    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 ... so what? And that would directly contradict their claim:
    Rutkowska stressed that the Blue Pill technology does not rely on any bug of the underlying operating system.
    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.
    1. Re:Let's make this a bit easier to understand. by tool462 · · Score: 3, Interesting
      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
      That's exactly what it does, according to this paper that somebody else posted in the comments. I don't know that it fakes all the hardware names and such (unlikely), but I doubt that the typical user would recognize that the hardware in their control panel was any different than before.
  4. Re:ok, but... by Scooter · · Score: 3, Interesting

    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!

    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 :D "yeah but we just paid for a 1 Ooodlegig/s line - it'll be super quick!"

    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.

  5. Virtualisation used for rootkit-safe environments by grumbel · · Score: 5, Interesting

    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.

  6. MOD PARENT UP, he's right. by 3l1za · · Score: 3, Interesting
    ...and he provides a critical rejoinder to grandparent who misunderstood what BluePill does (or rather what it claims it does).

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