You Can Detect Hypervisor Rootkits Even If You’re Virtualized

Thomas Ptacek | August 27th, 2007 | Filed Under: Defenses, Uncategorized

Rich Mogull, reacting to our virtualization work:

[R]eading up on Nate and Tom’s work I can’t see any techniques for detecting an unapproved hypervisor in an already virtualized environment.

This is a misconception. Defenders will not have a hard time detecting unauthorized hypervisors, even when the defenders are already running VMware or Microsoft Virtual Server.

Here’s why: the defender is embedded in VMware or Microsoft Virtual Server.

Sound crazy? It isn’t. To detect kernel malware, you (typically) already need to be running in-kernel; in other words, you have to be part of the operating system. For the most part, to detect virtualization, you have to be in-kernel as well.

Both Blue Pill and Samsara need access to the hardware. The trick is, Samsara works even when Blue Pill is actively trying to “cheat” it, making it believe it’s talking to the hardware when it’s talking to a Blue Pill facade instead.

Joanna contests this argument. “Microsoft and VMware would never embed detection hacks into their hypervisors!” We agree. Microsoft and VMware are unlikely to ever need to. Hypervisor rootkits are not a major threat. But if they ever become one, hypervisor rootkit authors will find themselves a sitting duck for detectors. Joanna had the right idea, “chickening out” into the OS kernel to hide from Samsara.

15 Comments so far

  • rmogull

    August 27th, 2007 3:01 pm

    Tom, are we talking around each other?

    I was referring to detecting an unauthorized hypervisor that either replaces the expected one, layers on top of it (probably not possible, but I never assume anything’s impossible), or corrupts it. This isn’t about Blue Pill, think of it being more about a hijacked hypervisor.

    If I’m in the guest OS I can detect I’m running on a hypervisor, but that’s the “easy” part. How do I know there isn’t a malicious hypervisor running vs. the authorized one?

  • Thomas Ptacek

    August 27th, 2007 4:20 pm

    If you’re supposed to be virtualized, ask your hypervisor to check to see if it’s being virtualized.

    If you’re not supposed to be virtualized, check to see if you’re being virtualized.

    Repeat until the chain is exhausted, or you get an unexpected result.

  • rmogull

    August 27th, 2007 5:43 pm

    What about a corrupted hypervisor? Neither case seems to help with that.

    I’ll just assume you can have your hypervisor check it’s virtualization status, of course that probably relies on the hypervisor either have that capability programmed in, or you have a way to extend it.

    As you said, and I fully agree, hypervisor rootkits aren’t something to worry about. The only ones I worry about is if the trusted hypervisor is compromised directly.

  • Thomas Ptacek

    August 27th, 2007 6:40 pm

    A corrupted hypervisor can’t pretend to allow Samsara to run. The hypervisor is “stepping aside” to prove that it is in control of the hardware. Samsara’s job is to verify that, and then allow the system to be scanned, knowing that the scan can’t be foiled by a hypervisor.

  • rmogull

    August 27th, 2007 9:28 pm

    Got it, think I misunderstood.

    Samsara doesn’t just look to see if there’s virtualization- it can also scan the hypervisor to make sure it’s unmodified.

    ’nuff said, if I have it right.

  • Thomas Ptacek

    August 27th, 2007 9:35 pm

    It can’t, but it could. More generally (and accurately), Samsara describes techniques that could be used by malware detection tools working jointly with legitimately hypervisors. IF the hypervisor cooperates with the detector, THEN unauthorized virtualization can be detected, EVEN IF the malicious hypervisor tries to cheat.

  • Thomas Ptacek

    August 27th, 2007 9:35 pm

    (And IF the hypervisor doesn’t cooperate, BUT SHOULD BE EXPECTED TO, the Samsara techniques work too.)

  • Matt

    August 29th, 2007 11:36 am

    How do you deal with the case where the “illegal” VM runs inside of the “legitimate” VM, i.e., between VMWare and your software? Obviously you can’t run Samsara in your program, since it’s already virtualized. You can ask VMWare to run Samsara, but it won’t tell you anything. Seems you need a way for VMWare & your program to detect the intervening virtualization layer. Is this easily done?

  • Thomas Ptacek

    August 29th, 2007 1:43 pm

    If the “illegal” VM runs underneath a legitimate hypervisor, it does not have control of the hardware. The legitimate hypervisor can trivially detect it (for definitions of “trivial” equating to “as easily as Norton AV detects viruses”).

    The point of hypervisor malware is to get the hardware to intercept detection attempts for you. If you don’t control the hardware, you don’t get to do that.

    You could *infect* a hypervisor (nobody has published such an attack yet). But there’s little semantic difference between infecting VMWare and loading your own hypervisor above it. The point of Samsara is, even if your rootkit is resident in someone else’s hypervisor, we can still (a) prove that we have unimpeded access to the actual hardware and then (b) use that hardware to scan for a rootkit.

  • dragonfrog

    August 29th, 2007 2:59 pm

    Correct me if I’m wrong, but wouldn’t that pretty much mean breaking the hypervisor?

    Would it be possible for a hypervisor to give its guests unimpeded access to the hardware, to such an extent that they can scan for rootkits, but still keep enough control that one compromised guest can’t attack other guests or the hypervisor itself?

  • Thomas Ptacek

    August 29th, 2007 4:16 pm

    Sure, to the same extent that loading into the kernel to detect viruses and kernel malware pretty much breaks the kernel. We didn’t make malware detection easier than it was before; we’re just making sure it doesn’t get harder. =)

  • Peter Ferrie

    September 4th, 2007 12:36 pm

    A compromised hypervisor - not BluePill - is the future. Future hyervisors will support third-party plug-ins, and they will become the targets, just as third-party kernel-mode drivers are now.
    Once a hypervisor is compromised, we have the same limitations there that we have for kernel-mode rootkits now - if we don’t know where to look, we won’t be able to find them, but there will always be anomalies then, just as there are now.
    So it’s really the same problem, just one level removed. As Thomas said, it hasn’t gotten any harder.

  • Mitch Ashley

    September 4th, 2007 5:19 pm

    Why not just use safeaccess to detect the presence of a rootkit?

  • Nate

    September 5th, 2007 3:08 am

    Peter’s right. One thing I think I figured out from talking to Joanna is that she expects things to be different this time around. (I’m unsure why she has that viewpoint, given her own talk on how Vista’s approach fails to keep out bugs in third-party drivers or signing an intentionally buggy driver.)

    Remember how NT was a microkernel and everything was external services? Look at it today. Microsoft is trying to push back with Kernel Patch Protection (i.e. PatchGuard) but fundamentally, third-party code will always be able to run in ring 0.

    So why will the hypervisor be any different? Hypervisors have to implement at least a mini-OS, and nearly all of those are based on Linux or Windows. So your kernel rootkit will work just fine in the hypervisor, once you’ve found a way to load it. And if that becomes common, scanning for malware in the hypervisor will also appear, as Rich is suggesting.

    And so it goes…

  • jgunnoe

    September 25th, 2007 6:32 pm

    Maybe I’m missing something here… Can we not independently calculate the fingerprint of a given hypervisor in a “known good state” then check for a change in that value?

    • Leave a reply