Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

Undetectable Rootkits Through Virtualization? 237

Posted by Zonk 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."
This discussion has been archived. No new comments can be posted.

Undetectable Rootkits Through Virtualization? More

Undetectable Rootkits Through Virtualization?

Comments Filter:

  • Before people start the Windows flamefest (Score:4, Informative)

    by Anonymous Coward on Thursday June 29, 2006 @06:30PM (#15632309)

    fta:
    Rutkowska stressed that the Blue Pill technology does not rely on any bug of the underlying operating system. "I have implemented a working prototype for Vista x64, but I see no reasons why it should not be possible to port it to other operating systems, like Linux or BSD which can be run on x64 platform," she added.

    • Let's make this a bit easier to understand. (Score:5, Interesting)

      by khasim ( 1285 ) <brandioch.conner@gmail.com> on Thursday June 29, 2006 @06:53PM (#15632462)
      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.
      • I'm sure someone will correct me if I'm wrong but ...

        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. :) you shouldn't have said 'I'm sure someone will correct me if i'm wrong' unless you wanted to be corrected.

      • Re:Let's make this a bit easier to understand. (Score:4, Interesting)

        by tool462 ( 677306 ) on Thursday June 29, 2006 @08:23PM (#15633003)
        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 [umich.edu] 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.

        • Think about what it means if they're right. (Score:5, Insightful)

          by khasim ( 1285 ) <brandioch.conner@gmail.com> on Thursday June 29, 2006 @09:42PM (#15633364)
          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.
          • 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 wh
          • 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 [intel.com])

            The summary's mention of "AMD's Pacifica virtualization implementation" seem

        • MOD PARENT UP, he's right. (Score:4, Interesting)

          by 3l1za ( 770108 ) on Thursday June 29, 2006 @11:37PM (#15633881)
          ...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).

        • The goal of the Pacifica technology is to do the virtualization in the hardware to avoid the need to emulate devices. Microsoft's Virtual PC product is forced to emulate a particular network card (an old Intel 10mbit card, if memory serves) and then translate usage of that network card to calls to the NT device drivers for the real network card. Under Pacifica, the virtualized system talks directly to the real network card and the hypervisor software (which runs beneath the OS kernel) co-ordinates the diffe

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

        Can someone please mod this guy down for not reading the article? It says:

        "The idea behind Blue Pill is simple: your operating system swallows the Blue Pill and it awakes inside the Matrix controlled by the ultra thin B

      • Actually, the rootkit itself would serve as the host OS and the virtualization software as one.

        This is not as much work as it may seem, because most functionality could simply be "leaked through" from the physical machine to the virtual one. The only functionality that the rootkit would fake would be stuff it used, such as the hard drive (to hide it's files, for example) and then whatever else it does (for example, it might have it's own network connection to a remote server, and then it would have to ma

    • Re:Before people start the Windows flamefest (Score:5, Insightful)

      by timeOday ( 582209 ) on Thursday June 29, 2006 @06:58PM (#15632496)
      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.

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

          • Re:Before people start the Windows flamefest (Score:2, Interesting)

            by Anonymous Coward
            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
    • You would have to be rather closed-minded to think a rootkit would apply only to Windows. From wikipedia [wikipedia.org]:

      The term "rootkit" (also written as "root kit") originally referred to a set of recompiled Unix tools such as "ps", "netstat", "w" and "passwd" that would carefully hide any trace of the intruder that those commands would normally display, thus allowing the intruders to maintain "root" on the system without the system administrator even seeing them.

      Generally now the term is not restricted to Unix-ba

  • said this before (Score:5, Interesting)

    by dknj ( 441802 ) on Thursday June 29, 2006 @06:31PM (#15632321) Journal
    Implementing malware with virtual machines [umich.edu]

  • ok, but... (Score:3, Funny)

    by celardore ( 844933 ) on Thursday June 29, 2006 @06:31PM (#15632325)
    Who runs anything *real* on a virtual server?
    • Hey Stef, your post seems familiar [userfriendly.org].

    • I don't know about your company, but I work for a giant Fortune 100 multinational company, by far one of the largest and most profitable and recognizable ones in the world. I'm very familiar with our computing environment, and I can tell you with absolute certainty that running applications on virtual machines is not only common here, it's a very important part of our future.

      Yes, real applications, the kind that are business critical.

      Is it a smart move? Maybe yes, maybe no. If you want to argue about

    • Re:ok, but... (Score:4, Interesting)

      by Scooter ( 8281 ) <owen@annicnova.f ... t minus language> on Thursday June 29, 2006 @06:58PM (#15632495)
      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.

    • Oh, I don't know, perhaps people who use Java or Perl?

  • the side effects are detactable (Score:4, Funny)

    by Anonymous Coward on Thursday June 29, 2006 @06:41PM (#15632378)
    Current virtualization doesn't virtualize anything but basic VGA graphics. That's certainly noticable.

    Boss asks: are you playing games at work?!

    Me: Just checking for rootkits boss!

  • Motherboards already block this... (Score:5, Informative)

    by Manip ( 656104 ) on Thursday June 29, 2006 @06:43PM (#15632386)
    Some, albeit high end, motherboards support a visual warning message that alerts the user to a program, or the OS trying to modify the boot sector on the hard disk. If you had this enabled it would stop this rootkit dead in its tracks. It's just a shame that more bioses / motherboards don't offer this support by default.

    If you have this on your motherboard I highly recommend you turn it on, it isn't too often that you reinstall the OS and pressing F9 isn't that much of an inconvenience even if you did it once a day.

    PS - All of the "My favorite OS is secure" posts below this are wrong if the Operating System supports some type of driver, or root program (running in the kernels memory space).
    • Hmm.. I have quite a pile of system boards here, dating from old 486 systems upto p4 and athlon xp, with ami, award, phoenix and biosses, and all of them have the boot sector virus protection option (tho sometimes just called virus protection).

      This offers at best a partial protection. While the MBR is important, the actual boot is done from the partition boot record, mot the master boot record, and this badly named feature is not going to help against that. Why badly named? because it does monitor (attempted) changes to the bootrecord and doesn't know anything about viruses.

      Next. even if you could protect against that, things just get a bit more OS and possibly OS version dependent because you have to move to the file that gets loaded by the partition bootrecord.

      Oh, quite a few 'boot managers' change the mbr on every boot.

      So while it offers some protection, that protection is extremely limited, and can be quite inconvenient.

      • and this is where TCPA would come in handy. the bios hashes grub, grub hashes the kernel and initrd, get a "known" good result. This should be fairly stable. If executing within a hypervisor, the resulting hash value will not be equivalent and you will know something is up.
    • 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.
    • 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,
    • Unlike SubVirt, Blue Pill does not require a reboot before it becomes active and does not alter the MBR. That motherboard setting will not be an effective mitigation strategy.

  • This just reinforces the good old principle (Score:5, Insightful)

    by A beautiful mind ( 821714 ) on Thursday June 29, 2006 @06:47PM (#15632411)
    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.

  • A win-win situation for everyone (Score:3, Funny)

    by KingSkippus ( 799657 ) * on Thursday June 29, 2006 @06:48PM (#15632423) Homepage Journal

    From TFA:

    Rutkowska says of the Blue Pill concept, "I am very excited about the chance to work with Sony on how this technology can be used to protect their next generation of music CDs, DVDs, and high-definition Bluray discs. I believe it will be a win-win situation for everyone involved. Well, everyone important, anyway."

  • Not much less detectable (Score:5, Insightful)

    by mrcaseyj ( 902945 ) on Thursday June 29, 2006 @06:49PM (#15632428)
    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 (Score:4, Insightful)

    by supradave ( 623574 ) <supradave.yahoo@com> on Thursday June 29, 2006 @06:49PM (#15632434)
    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.
    • and 4 privilege levels (instead of 2).

      Well, OS/2 (0/2/3) and Linux on Xen (0/1/3) both use 3. If you can take control of the hardware via a Xen-ed kernel, now that would be one for the hacker hall of fame.

  • Real Beneficiaries of Hardware Virtualization... (Score:3, Interesting)

    by Anonymous Coward on Thursday June 29, 2006 @06:51PM (#15632446)
    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.

  • Is this a "root kit"? (Score:3, Interesting)

    by TheConfusedOne ( 442158 ) <the@confused@one.gmail@com> on Thursday June 29, 2006 @06:51PM (#15632447) Journal
    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?

  • Is this really a surprise? Given the layered design of software, if you have something that can sit between the hardware and the software (and monitor what passes between, and control said information), they why would it not have complete control? The question is how could this easily be placed on someone's machine? The next question is why can a level of virtualization be introduced between the operating system and the hardware during execution?

    "your operating system swallows the Blue Pill and it awake

    • your operating system swallows the Blue Pill and it awakes inside the Matrix controlled by the ultra thin Blue Pill hypervisor. This all happens on-the-fly (i.e. without restarting the system)

      Not that the average Windows user would find yet another spontaneous reboot any particular cause for concern, but I admit it would be cool.
  • The Matrix has you.
  • Microsoft already working on one to address teh issue. I dont know if you have to pay additional money as MS hinted that ms antivirus will be a subscription service.

    Running everything off a livecd is a good idea since most infected pc's are as slow as a 486 and could take hours to days to scan. In this case it would be ineffective.

    I wonder if bios virii are next/? Its the only way to go above even booting off a pc and some malware and spyware makers are working on this. That way it can't be removed at all.
    • > Microsoft already working on one to address teh issue.

      Thank God. I feel so much better now. I hope they roll that into Defender.
  • "Is this testing whether I'm a virtual machine or a lesbian, Mr. Dowd?"
  • I remember an article a couple of months ago where Microsoft employees had done something similiar, that is using virtualization to create a low level rootkit.

    Because, y'know, the only way to protect yourself against attacks like these are with Trusted Platform Modules.

    20 bucks Microsoft sponsored this research in some way.
    • mod parent up. insightful! It had not occured to me that this is a good argument for "trusted computing platforms". although if the virtulization engine is one of the existing players from vmware, MS, etc I imagine it would alright be "certified" for the platform as the major users of these types of applications are corporate in nature and would require all those hoops to have been jumped through PRIOR to purchasing and implementing these types of software solutions.
  • I don't think that anyone is suprised by this. After all, it is common sense that the virtual OS's security is at the pleasure of the host, in much the same way that the security of a user-mode process is at the pleasure of the operating system. If there is anything between you and the actual naked hardware, then there is always the possiblity that that layer is doing something with your data that you don't lie.

  • TPM (Score:2)

    by throx ( 42621 )
    This is actually the good side to the Trusted Platform Module - you can set up your machine to refuse to boot, warn you, whatever if anything in the boot process changes. As it's implemented in BIOS with hashing of the boot process before it even loads it from disk, there's no real way around this short of having physical access to the machine and turning off the TPM.

    The bad side of the TPM is when you lose control of it - then the machine isn't yours any more but the xxAA's.
  • 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.
    • 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

      Or the watchdog could use a similar exploit to jump above the rootkit and look down to see what is running. If we're nested one level too deep then we've got a problem.

      Assuming of course we can nest. If we can't, the failure to nest would show the problem.

      Or you could always run something using heavy 3D, and if the CPU ignites then something's up. ;)
    • 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 [usenix.org]). Timing privile

    • Launch a watchdog application and let that watchdog application launch the real OS in a virtualized environment [...]

      ALAN
      It's called Tron. It's a security program itself, actually. Monitors all the contacts between our system and other systems... If it finds anything going on that's not scheduled, it shuts it down. I sent you a memo on it.

      DILLINGER
      Mmm. Part of the Master Control Program?

      ALAN
      No, it'll run independently. It can watchdog the MCP as well.

    • Of course, this assumes your watchdog OS doesn't have vulnerabilities...

  • Whoa. Déjà vu. (Score:5, Funny)

    by DysenteryInTheRanks ( 902824 ) on Thursday June 29, 2006 @07:21PM (#15632629) Homepage
    "A Slashdot article just went by, and then another one that looks just like it!"

    "It's a glitch in the rootkit! It happens when it changes something!"

    "No, I said a SLASHDOT article."

    "Ah, you're probably fine then."
  • ... it's not your machine anymore.

  • So let me get this straight... (Score:3, Insightful)

    by C3ntaur ( 642283 ) <centaur@@@netmagic...net> on Thursday June 29, 2006 @07:46PM (#15632789) Journal
    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?

  • Bah, humbug! (Score:4, Informative)

    by davecb ( 6526 ) * <davecb@spamcop.net> on Thursday June 29, 2006 @08:00PM (#15632879) Homepage Journal

    Exactly the same thing was done using the ancient "cookie monster" program on Multics, long before Unix was even a gleam in T&R's eye.

    The perpetrator created a user-ring instance of a user (a virtual-machine-like process), loaded in the cookie mosnter, then loaded the command interpreter and handed the result to an unsuspecting user, my boss.

    He searchrd high and low, never suspecting the program that kept saying "Want cookie!" was down below the shell.

    --dave

    • Re:Bah, humbug! (Score:3, Interesting)

      by surprise_audit ( 575743 )
      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
  • I don't know about you, but when I start up VMWare in windows (or parrellels in OS X) I definatley notice a performance hit. I find it difficult to believe that somebody wouldn't notice the fact that larg(ish depending on how exactly this is implemented) chunks of RAM and disk space are suddenly in use by some rogue program.
    • The virtualization enhancements to the Intel and AMD processors significantly reduce the overhead of running virtualized environments. Xen, an open source virtualization software, exploits the chip hardware so that typical overhead is under 5%. On a modern processor this may be undetectable.

  • DRM? (Score:3, Funny)

    by sr180 ( 700526 ) on Thursday June 29, 2006 @08:10PM (#15632923) Journal
    Can we use this to bypass the DRM included in Vista?

  • Nothing new, really. (Score:5, Insightful)

    by Anonymous Coward on Thursday June 29, 2006 @08:13PM (#15632941)
    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. [acm.org]

  • What's that you say? (Score:3, Funny)

    by kimvette ( 919543 ) on Thursday June 29, 2006 @08:30PM (#15633040) Homepage Journal
    The next version of WGA will be undetectable? Thanks, Microsoft! ;)
  • The rootkit's code name is "The Matrix"?
  • ...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.

  • Actually quite detectable (Score:3, Interesting)

    by Anthony Liguori ( 820979 ) on Friday June 30, 2006 @10:02AM (#15635849) Homepage
    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.

Slashdot Top Deals

For God's sake, stop researching for a while and begin to think!

Close