Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Blue Pill Myth Debunked

Posted by CowboyNeal on Sat Aug 12, 2006 08:18 AM
from the setting-the-record-straight dept.
Operating Systems Software Windows Security IT
njyoder writes "As previously posted about, Joanna Rutkowska claimed to have discovered an allegedly undetectable vulnerability in Vista that takes advantage of AMD cpu's virtualization capabilities. a virtualization professional (Anthony Liguori of the Xen project) has now voiced his opinion to state this is bunkum. There are two parts two this — the ability to take over the machine and seamlessly drop the OS into a VM (which is very difficult, but possible) and the ability to have windows run in the VM undetectably (which is impossible). In fact, Rutkowska's prototype is VERY detectable. This is unfortunate mistake that people make when they jump to conclusions based on what is unfounded speculation and that includes the assumption that this would somehow be Vista specific, if it worked (noting that Vista doesn't run with administrator privileges by default)."
+ -
story

Related Stories

[+] AMD: Would Blue Pill create a matrix for PCs?
Will you choose the red pill, and stay in Wonderland, or the blue pill, and wake up and believe whatever you want? If Joanna Rutkowska, a security researcher for Singapore-based IT security firm COSEINC, has her way, you'll choose the blue pill. She has developed a 'blue pill' that will create a fake reality for anti-malware sensors, including those baked into Microsoft's upcoming Windows Vista operating system. "The idea behind Blue Pill is simple, she said. The operating system "swallows" the Blue Pill and it awakes inside a Matrix controlled by the "ultra thin Blue Pill hypervisor." This all happens without restarting the system. "There is no performance penalty and all the devices, like graphics card, are fully accessible to the operating system, which is now executing inside [the] virtual machine," she said. "This is all possible thanks to the latest virtualization technology from AMD called SVM/Pacifica." " You can check out a demo at the Black Hat Briefings in Las Vegas Aug. 3.
[+] Vista Hacking Challenge Answered 388 comments
debiansid writes "Microsoft's most secure Operating System yet has been compromised at the Black Hat hacker conference. We all know that Andrew Cushman, Microsoft's director of security outreach invited the Black Hats over to touch and feel Vista in order to showcase the superiority of this OS. Joanna Rutkowska, from Coseinc, a Singapore-based security firm, obliged and showed how it is possible to bypass security measures in Vista that prevents unsigned code from running with the help of a little software she calls the 'Blue Pill.'" To be fair, the hack was possible only when the target is in administrator mode rather than a limited user account.
[+] IT: VM-Based Rootkits Proved Easily Detectable 128 comments
paleshadows writes "A year and a half has passed since SubVirt, the first VMM (virtual machine monitor) based rootkit, was introduced (PDF), covered in the tech press, and discussed here. Later Joanna Rutkowska made news by claiming she had a VMM-based attack on Vista that was undetectable — a claim that was roundly challenged. Now in this year's HotOS workshop, researchers from Stanford, CMU, VMware, and XenSource have published a paper titled Compatibility Is Not Transparency: VMM Detection Myths and Realities (PDF) showing that VMM-based rootkits are actually easily detectable."
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Blue Pill Myth Debunked 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • I always take (Score:2, Funny)

    by Anonymous Coward
    the red pill but I still wake up in hell each morning ... Vista will be shipping.

  • Detection (Score:5, Insightful)

    by CastrTroy (595695) on Saturday August 12 2006, @08:25AM (#15893959) Homepage
    I think the problem is not whether or not it can be detected by a professional, or a malware detection program, but whether or not it can be detected by the user of the computer. If you can run the entire OS in a VM, without the user knowing, then there's a lot of stuff you can do that would probably be a lot harder to do if you were just running regular malware. Although it's reassuring that this wasn't as bad as we expected, I still expect to see a few exploits that use this method to install malware, and spy on what the user is doing.
    • If you can run the entire OS in a VM, without the user knowing,

      So would the best solution is to try to run 3d FPS games to see if they work?

      As far as I know one of the problems with VM is that 3d acceleration may not work as expected, but most VM companies are trying to get around this with much success.
      • So would the best solution is to try to run 3d FPS games to see if they work?

        Well, this is Vista. In theory, most PCs should be able to run some of the 3D effects (maybe not all of them). So you should notice a lack of the 3D effects all of a sudden, and a huge slowdown as Windows is no longer relying on the video card for desktop drawing.
      • Well, that's mostly not because of virtualization, but because of coexistence with the host OS. In this case, there is no host, just a hypervisor hacking specific calls. Any call to the graphics hardware could be let through, if desired. The performance hit would be acceptable for the non-inquisitive user.

      • Re:Detection (Score:5, Informative)

        by gclef (96311) on Saturday August 12 2006, @09:59AM (#15894213)
        This is hardware virtualization we're talking about, not software. The processor manufacturers have built virtualization calls into their chipsets. The side-effect of this is that the hypervisor can simply tell the bios "I'm the hypervisor...but, only call me when these specific requests are made." So, the hypervisor could simply choose to ignore the sound and video hardware, leaving those as fast as they were before.

        The only way to tell the hypervisor is there is to find a CPU call that the hypervisor *does* care about, and compare how long it takes to run that command before & after the rootkit pushes the OS to a guest OS. That's what the Xen guy is talking about.

        (I was at Rutkowska's talk...I'm not sure I buy the Xen guy's response.)

        • Re:Detection (Score:3, Informative)

          by Sancho (17056)
          It was quite an amazing talk, wasn't it?

          She admitted that timing attacks were her weakness, as did the other guy who talked about virtualization-based rootkits. The problem is that you have to have a benchmark to compare it to, and you have to assume that the hypervisor doesn't modify the time whenever it is called. If the time does get modified, then the only way we know of to detect the rootkit is to measure clock skew on the infected PC using a real time source. This, of course, assumes that there isn
          • She admitted that timing attacks were her weakness, as did the other guy who talked about virtualization-based rootkits. The problem is that you have to have a benchmark to compare it to, and you have to assume that the hypervisor doesn't modify the time whenever it is called.

            The difference is order of magnitudes. Hypervisor exits incur penalties on the order of thousands of cycles. If you don't know the specifics of the system you're on, you can always compare the cost relative to a similiar instruction.
            • If I understand your method correctly, it still requires the use of an external clock. If that's the case, there's still no programmatic way to do it, you're still relying on external sources, which is something your average end-user is unlikely to do.

              Or do I misunderstand?

        • Re:Detection (Score:5, Interesting)

          by Anthony Liguori (820979) on Saturday August 12 2006, @11:07AM (#15894499) Homepage
          This is hardware virtualization we're talking about, not software. The processor manufacturers have built virtualization calls into their chipsets.

          They've added extensions to facilitate trap-and-emulate virtualization.

          The side-effect of this is that the hypervisor can simply tell the bios "I'm the hypervisor...but, only call me when these specific requests are made."

          VT/SVM have absolutely nothing to do with the BIOS. Instead, they both introduce a new processor mode that can be entered at any point that allow certain operations to be trapped. These operations are more or less the set of classic x86-sensitive instructions.

          So, the hypervisor could simply choose to ignore the sound and video hardware, leaving those as fast as they were before.

          Yup. But we're not talking about hardware here. Keep in mind, that if you do allow direct access to hardware, one now has a channel to access all of memory which could be used to detect a virus in RAM. Let's ignore that for now though :-)

          The only way to tell the hypervisor is there is to find a CPU call that the hypervisor *does* care about, and compare how long it takes to run that command before & after the rootkit pushes the OS to a guest OS.

          Yup, and as I pointed out to Joanna, there are a number of CPU operations that one would *have* to trap. Things like %cr3 moves, msr reads/writes, etc. Otherwise, one can just search memory for a signature. BTW, how does she hide the memory of the VMM from the guest? I didn't address this because there are some potential solutions (like memory hotplug) but this, in practice, would be a very hard problem to solve. You can just take away memory from an Operating System and expect things to function normally.

          Why do you think she addressed this in her talk? I brought it up to her before she presented...

          Anyway, you have to take a trap at some point. There are only a small number of possible instructions that trap. A very thorough "detector" could simply check the timing of every trapable instruction.

          If she's not trapping any instructions, then the monitor is never getting run so is it really a monitor anymore?

          BTW, on VT at least, the VMM doesn't get a choice for certain instructions. They always trap no matter what.
    • I don't, the size of the app alone to get the OS into a VM would take days to download on most people's "broadband". Knowing most mom and pops the computer would be turned off long before it could finish.

    • debunked? I don't think so... (Score:5, Interesting)

      by v1 (525388) on Saturday August 12 2006, @10:30AM (#15894340) Homepage Journal
      Though there is a littlee war the authors neglect to mention. If I am writing a blue pill virus vm, and I KNOW there is software out there that is trying to detect me, it's completely worthless. Since I own the machine at that point, I can modify the programs running, with impunity. That's like all the viruses that are out there right now that are more or less immune to Norton... they know what the "threat" is, and they plan accordingly, they know its weaknesses and simply sidestep right around it.

      A vm that sees you load BluePillDetect.exe just goes in and twiddles a few bits here and there in the app before it actually puts it in the execute queue, or subtly mucks with its registers while it's executing. Now the program blissfully reports just what the VM wants it to report... "no VM detected.".

      Now how are you going to get around THAT? If you are running on a totally owned system, you cannot tell me there is anything you can do that is guaranteed to work, especiially if you are using a commonly available tool that the vm author had access to..

      You simply cannot win at their game if they are the ones writing the rules. You can claim victory for a day or two, until the VM authors get their hands on your tool and make the necessary modifications to their VM to cripple your tool, and then you are back to the drawing board.
      • Now how are you going to get around THAT?

        Periodic live-CD system file scanning?

      • A vm that sees you load BluePillDetect.exe just goes in and twiddles a few bits here and there in the app before it actually puts it in the execute queue, or subtly mucks with its registers while it's executing. Now the program blissfully reports just what the VM wants it to report... "no VM detected.".

        Yes, but writing code from the VM to reach inside OS-specific structures (or even read their contents) is difficult and fragile -- you need to find structures with known memory locations and find a way to fol

      • You can claim victory for a day or two, until the VM authors get their hands on your tool and make the necessary modifications to their VM to cripple your tool, and then you are back to the drawing board.
        :%s/VM/virus/g
        and you've just described the state of the art in virus scanning as it's been since more-or-less forever.
      • Actually, I think most people would be able to detect it when it fails utterly to work, and instead performs a quick BSD.
      • You know there are programs to evade those particular programs from the kernel. And they are pretty good at that. Now a VM outside your OS might be detectable (nothing installed on your computer isn't), but it may be harder than to run that latest "vista-running-inside-vm-detector-by-microsoft" thingie. But hey! maybe I'm wrong and rootkits are still the way to go :)

      • Re:Detection-My buddy, the program. (Score:5, Informative)

        by Sancho (17056) on Saturday August 12 2006, @10:46AM (#15894395) Homepage
        When people talk about Blue Pill as being "undetectable" they mean "through the use of a program."

        And that's Joanna's point. Properly constructed, Blue Pill 2 (the successor with full emulation support coded in--she herself admitted that her prototype is imperfect) would be undetectable by software running inside the VM. She discusses the possibility of a timing attack using an external clock, but also notes that this is infeasible in a large deployment. Certainly it would be infeasible for your average person running a computer (evidence by the fact that some of them don't even run antivirus/antimalware programs at all and get horribly infected!)

        I was at Joanna's Black Hat briefing. Not once did she imply that this was Vista specific--in fact, she mentioned another briefing with the same sort of rootkit--only running on a MacBook. Her briefing was entitled "Subverting the Vista Kernel for Fun and Profit" because the first half of her talk was about elevating privileges in Vista, which would allow a rootkit such as Blue Pill to run.

        I think that the danger here lies somewhere between "The end is very fucking nigh" and "This is absolutely nothing to worry about." Yes, it's extremely hard to implement. But that shouldn't mean we don't worry about it, because one implementation and it will be much easier to reverse engineer/modify to do other nasty things. Also, the eventual inability to detect in software means that if such an attack ever comes to pass, it will be extremely difficult to clean en masse (virtually requiring a reinstall or a livecd).
        • I'm curious if this will not give rise to a new breed of network bootups. This breed would be initiated from a BIOS that only allows itself to be flashed with very visible and bright red user confirmation off a non-bootable physically attached disk (such as CD or floppy). This BIOS will only boot off the network, and what it boots would be anti-VM software which confirms the local boot process of your machine, then once determined to be clean, transfers control back to the local machine. The BIOS would h
          • Right. As has been said, "undetectable" means "from within the VM itself". You're also talking about prevention, which is equally important. TPM could also prevent virtualization-based exploits, already exists in a fairly convenient form, is more robust (doesn't require an external server which could be down or bogged down), and fits in fairly well with corporate culture.
        • When people talk about Blue Pill as being "undetectable" they mean "through the use of a program."

          And that's Joanna's point. Properly constructed, Blue Pill 2 (the successor with full emulation support coded in--she herself admitted that her prototype is imperfect) would be undetectable by software running inside the VM.

          This is the fundamental problem I have. So she has a crappy prototype but claims that the next version will be undetectable? Where's the paper? What is she exploiting to make this actuall

          • Re:Detection-My buddy, the program. (Score:5, Informative)

            by Sancho (17056) on Saturday August 12 2006, @11:22AM (#15894578) Homepage
            The paper was presented at Black Hat. She explained what is required in order to fully "emulate" the instructions required to make it undetectable. Essentially, Blue Pill would need a shim that passes virtualization instructions back up the chain until they could be executed for real, then return everything back down. It's not as huge as everyone thinks, but it's not trivial, either. But yes, she's outlined what has to be done.

            I bet you can find a PDF of her slides somewhere online, if you're interested.
          • The problem is that you're thinking of software virtualization rather than hardware virtualization (as in the Core Duo chips and AMD's newer chips). Both of your cases outlined above are dealt with using the instruction sets in these chips.

            1) The hardware is the same unless the hypervisor changes what the software sees. All the hardware in the device manager will look just like it did pre-virtualization. This was demonstrated at Black Hat.

            2) This is simply not true with hardware virtualization. It may b
  • Most operating systems don't take advantage of the facilities the 'processor' provides for them. This has been true for quite some generation of operating systems.

    I would probably take heart to this if a hardware (or firmware) engineer spoke up and noted that this is a possibity. Are processors now offering virtualizaton in-chip?

  • Impossible to not be detected? (Score:3, Insightful)

    by nurb432 (527695) on Saturday August 12 2006, @08:46AM (#15894014) Homepage Journal
    I dont agree with that statement.

    While i agree it would really really damned hard to do it, you could create a VM that the host os wont reconize as being a VM. Sure, it would have to accomodate for each new PC out there as hardware changes, and that it would be a massively complex beast that more then likely could never be turned into a worm/virus/trojan that you wouldnt see coming a mile away, but it could be done.

    Never say impossible when logic says it could be done. Just say impractical..

    • Re:Impossible to not be detected? (Score:5, Insightful)

      by Anthony Liguori (820979) on Saturday August 12 2006, @09:41AM (#15894134) Homepage
      Never say impossible when logic says it could be done. Just say impractical..

      There are actually things in computer science that are impossible. Usually, they are problems in the form "figure out whether another program has propery X". Classic examples are the halting problem.

      Recall, I'm disputing the claim of "100% undetectable". You could make something that's really, really, really hard to detect.
      • I think that it would be impossible to provably show that a complete Blue Pill implementation is on your system from within that system. The idea being, it might be possible to detect anomalies by using software on the infected VM. It would be impossible to definitively say "You are infected with Blue Pill." The most it could do is say, "I found X, Y, and Z timing/instruction anomalies which lead me to believe that I am running in a VM. User, am I running in a VM to the best of your knowledge?" This is

  • my take (Score:5, Interesting)

    by brennz (715237) on Saturday August 12 2006, @08:47AM (#15894017)
    I'm not so sure Anthony Liguori is right.

    Most people in the security community are well aware of http://www.ephemeralsecurity.com/mosref [ephemeralsecurity.com] demo at http://static.ephemeralsecurity.com/mosvm/demo1.ht ml [ephemeralsecurity.com] more detail at http://static.ephemeralsecurity.com/mosvm/Mosref%2 0Howto.html [ephemeralsecurity.com] and the continual move toward VM

    If mosquito and similar tools are not moving towards VMMs, I'd be very suprised. After all, it is a logical step (From VM as a payload, to a VMM as a payload).

    • Re:my take (Score:5, Informative)

      by Anthony Liguori (820979) on Saturday August 12 2006, @09:44AM (#15894146) Homepage
      If mosquito and similar tools are not moving towards VMMs, I'd be very suprised. After all, it is a logical step (From VM as a payload, to a VMM as a payload).

      Of course, VMM's can be used to do all sorts of nasty things. VMM-level virus could certainly be nasty. And, an important point to note, is that it may be entirely possible for a virus to be hidden in a VMM and for a virtual machine not to be able to detect that virus. Will VMM's need anti-virus software? I hope they don't suck that much.

      What "blue pill" is though is something much different. It's claim is that you can take a native Operating System and turn it into a virtual machine without the OS knowing about it.

  • Of course it's difficult to do in Vista (Score:5, Interesting)

    by Ant P. (974313) on Saturday August 12 2006, @08:49AM (#15894022) Homepage
    Which is why malware's going to do this on Windows XP, then lie dormant until it detects Vista installed.
    • Very few will buy Vista to reinstall over XP. Most will just get it with a new PC. And if they DO reinstall, most will probably completely blow away the drive, and do a full install instead of an upgrade install.
      • You mean everyone except just about every engineering desktop in America, right? Installing all the S/W required for non-admin types is an IT killer. Even if they don't fuck up the installs, it takes them forever to prep each new machine. Hell, we figure one to two weeks of end-user downtime into every machine upgrade.
  • At least with Beta 2 Vista did run with admin privledges, just as all previous versions of Windows. But you have that box that pops up when ever you use those privledges. MS has done a good PR campaign to make people think it doesn't, but install beta 2 for yourself, the user created in setup is an admin just like in XP. I sincerely hope that this is changed with RC1.

  • It's a prototype (Score:3, Insightful)

    by Bartmoss (16109) on Saturday August 12 2006, @09:21AM (#15894084) Homepage Journal
    The exploit is the first of its kind for Vista. Give this a few years and add the high motivation of criminals who make millions by exploiting PCs and you can be sure we'll eventually see some quite nasty stuff.

  • Not the only one to come to this conclusion... (Score:3, Informative)

    by Anthony Liguori (820979) on Saturday August 12 2006, @09:51AM (#15894176) Homepage
    FWIW, Keith Adams of VMware posted a recent blog entry "Blue Pill" is quasi-illiterate gibberish [blogspot.com] and there have been a number of other folks that have come to the same conclusion [openrce.org].

  • I'm thinking any subversive VM thing would be like an uber-rootkit. When infected, the user's ntldr or winload.exe (for Vista) would be overwritten to load our new OS instead of Windows. On the next boot (which could come early by the delivery system resetting the computer), the new OS would load which would be little more than a very thin VM wrapper around windows. It would immediately boot up windows, and the user would be none the wiser. Basic things it would do (that would classify it as a rootkit)

  • this stuff is what bothers me (Score:3, Interesting)

    by rucs_hack (784150) on Saturday August 12 2006, @10:35AM (#15894358)
    With Open source there's no problem. I can hear about a thing, test it, look at code, and decide whether it's an issue to me. Or if it's outside of my abilities, That wonderful peer review process can do the job for me. People who are being paid to say good things soon fall silent or get drowned out in the face of proof to the contrary from many sources who are not being paid, but do it out of interest.

    With closed source code of any type I have no such option. Instead all I get is 'experts' to tell me. But these guys have to eat, so they get paid by someone, and have a vested interest in being paid tomorrow. Therefore there can be no impartial advice.

    Heck, if the cheif engineer on the shuttle program can be convinced to retract his refusal to sign off the shuttle because of O-ring problems, what hope is there for trustworthy answer from anyone regarding closed source software?

    Ok, possibly I'm being too extreme with my example, but seriously I worry about the *true* safety of using an operating system which has not, in fact, been designed with consumers in mind. It is, by microsofts own cheerful admission, purposely built to help 'rights holders' of stuff you use keep you from deviating from their precious business plan.
    Perhaps this is fair enough, but there should be a trade off. I see no evidence that the rights of the OS purchaser are being properly considered. Even XP assumes you are a pirate unless proven otherwise. That reveals a lot about their views of the lowly home consumer.
    • And how, pray does the openness or otherwise of the OS allow you to know whether you could silently drop it inside a hypervisor without knowing? This is not a Vista-specific exploit.

      • His complaint is not about a technical matter. Openness may have a very limited (or no) effect on whether or not a compromise is possible. But it does have an effect on whether or not the threat is analysed and whether or not you can trust that analysis.

        It's really a question of integrity and loyalty. It may be strange to talk about an inanimate object (software) having "loyalty" but it's the best analogy I can come up with. Free software gives its ultimate loyalty and allegiance to the user. You can

  • VI: Where are risks in this scenario?

    AL: If a virus cannot be removed or detected, it's pretty much a worse case scenario for corporate security. Once there was an outbreak, you couldn't trust any of your systems at all. I'm not sure how one could even mitigate such a threat--perhaps do frequent reinstalls of every system on your network?

    I'm still just amazed that people don't do this anyway. My understanding is that today's approach to AV is that people run AV applications on possibly infected systems,

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.