DISQUS

rmogull · 2 years ago

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 · 2 years ago

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 · 2 years ago

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 · 2 years ago

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 · 2 years ago

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 · 2 years ago

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 · 2 years ago

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

Matt · 2 years ago

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 · 2 years ago

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 · 2 years ago

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 · 2 years ago

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 · 2 years ago

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 · 2 years ago

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

Nate · 2 years ago

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 · 2 years ago

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?