Matasano Chargen - Latest Comments in Detecting Virtualized Rootkits

Re: Detecting Virtualized Rootkits

chatsohbet — Tue, 30 Jun 2009 10:25:35 -0000

SESLI SOHBET
BURSA SOHBET
ISTANBUL CHAT
ISLAMI CHAT
IZMIR CHAT
ANKARA ARKADAS
ALMANYA CHAT
TURKEY CHAT
MYNET
SITENE EKLE
VIDEO KLIP IZLE
YEMEK TARIFLERI
VIDEO MUSIC

Re: Detecting Virtualized Rootkits

Mark — Thu, 15 May 2008 11:45:37 -0000

When will the Thomas Ptacek list of virtualization detection techniques be published

d86ded8e6f086cbc86bb07d854e58e1d60680958

and have you added any new ones

Re: Detecting Virtualized Rootkits

Sun, 08 Jul 2007 19:33:01 -0000

Joanna,

Remember what was discussed at Fed 06? When someone mentioned how close you are? That is still the case. Remember, it is about the data, not control of the machine. App layer, not Ring 0. Grid, not individual CPUs. Arrive/come in as a fully authorized process, via the EMSes. There is your control. Of everything.

That is what is worth making better, trust me.

Best, H

See you all in Sin City... I'll be the one questioning Tony as to his true intentions and 'goodness'.. just waiting to see what strangeness Dan comes up with THIS year... yeeesh....

Re: Detecting Virtualized Rootkits

Thomas Ptacek — Wed, 07 Feb 2007 09:41:20 -0000

In retrospect, no.

Let's use this:

d86ded8e6f086cbc86bb07d854e58e1d60680958

Re: Detecting Virtualized Rootkits

anon — Mon, 05 Feb 2007 18:29:50 -0000

erm,

are you sure that 95faf2cfb27b4e271a8943ad44f7d865 is sha-1?

/shrugs

Re: Detecting Virtualized Rootkits

Thomas Ptacek — Thu, 25 Jan 2007 13:34:30 -0000

The variances between a virtualized P4 and a "native" P4, which hypervisor malware needs to detect and mask, can be made data-dependent. The X86 ISA doesn't provide a direct way to query the state of the microarchitectural details we're playing with. In other words, without "detecting the detector" *and* analyzing its code, we think we can put the CPU into a setting where only the hypervisor detector knows what CPU state to expect after a VM-exit.

Re: Detecting Virtualized Rootkits

Matt — Thu, 25 Jan 2007 12:35:38 -0000

Nate:

I agree with most of your comment, but I'm not sure how the Halting Problem relates to what you're saying. There are certainly decidability issues in v12n detection, but they're usually discussed at a level of abstraction well above variations in CPUs.

Re: Detecting Virtualized Rootkits

Nate — Thu, 25 Jan 2007 01:04:07 -0000

There is a well-known problem of "code trying to understand code": the Halting Problem. If Tom comes up with a technique for detecting a hypervisor on CPU v1, Joanna can come up with a technique that avoids the detection (assume she can update the hardware for CPU v2).

But then Tom gets to run his old technique on all CPU v1's and try to find a new technique for CPU v2. And then the cycle can repeat with Joanna updating her approach for CPU v3.

Assuming both people are dedicated to playing this game forever, Tom wins percentage-wise because CPU v1 is not immediately retired and he's slowly building up a pool of CPUs with different characteristics. It doesn't matter that his codebase is growing because he only needs one trick per CPU version. But Joanna needs to support all CPU versions and all approaches to all CPU versions (n^m). To win, Joanna would have to force old CPUs to retire more quickly than Tom can update his detection logic.

But you're also forgetting that at some point, the CPU vendor is not incentivized to keep playing the game. If, for instance, cache timing variance became so sophisticated that the vendor had to consider flushing the cache completely, they'd probably stop there. CPU vendors have other goals (i.e. performance) that directly conflict with hiding virtualization.

You can see the kind of effort it takes to eliminate covert channels in rainbow book systems. That kind of cost is hard to justify in the commodity CPU world, and is only effective for some subset of all possible covert channels.

The way I like to say it, "Show me your undetectable hypervisor, and I'll show you a CPU that never had any errata." Take a look at the length of errata sheets for modern CPUs, then add in chipsets and peripherals. We're headed the opposite direction from Joanna.

Re: Detecting Virtualized Rootkits

Thomas Ptacek — Wed, 24 Jan 2007 22:30:46 -0000

My guess, not counting LWIP, is about 1500 lines of code.

Re: Detecting Virtualized Rootkits

one.miguel — Wed, 24 Jan 2007 22:24:17 -0000

I wonder how large Bluepill must be in order to do all those cool things...

Re: Detecting Virtualized Rootkits

Thomas Ptacek — Wed, 24 Jan 2007 21:21:28 -0000

Nobody can reliably predict the future, but we can use our experience and knowledge to guess where the trends are heading.

I predict that, because "detect unexpected virtualization" is a simpler goal than "detect any modification to the OS runtime", virtualized rootkits will remain easier to detect than kernel rootkits.

Re: Detecting Virtualized Rootkits

Steo — Wed, 24 Jan 2007 20:16:42 -0000

Thomas,
someone somewhere will always find someway of detecting a virtualized rootkit without an external clock as you said. When it becomes apparent that that it has been done someone will find a way to find it.

Until the situation is put to us we will not be able to really explore it.

Nice debate,
regards
Steo

Re: Detecting Virtualized Rootkits

Thomas Ptacek — Wed, 24 Jan 2007 18:51:49 -0000

This is pretty much the same thing the IDS vendors said, when we pointed out that overlapping fragments confused their TCP reassembly engines. "Of course there are bugs in our code. But we'll just fix them!". Yes, but there will always be more bugs.

The IOMMU point is well taken. I gather you haven't used it yet, just like we don't use LeGrande and the MPT in Vitriol. It's worth mentioning that some of these detection techniques also present vectors for guest-hopping attacks.

The ASID tagging, TLB-preserving functionality is another point well taken. But that's just one of the attacks. How do you turn off the branch predictor? Remember that these attacks have been tuned to pull keys out of SSL processes running in different CPU threads; hypervisor timers get to run right next to your VM exit.

I don't have any proof about the detectability of BluePill, because you haven't released BluePill or allowed anyone to test it. Would you like to do that? I think we're up to the challenge!

Failing that, we're always going to be talking in the hypothetical. But I'm curious: why do you think we can imagine reliable kernel rootkit detectors, but not reliable hypervisor detectors? Hypervisors are more disruptive than kernel threads.

Re: Detecting Virtualized Rootkits

joanna — Wed, 24 Jan 2007 18:45:29 -0000

I guess I could point out some issues in Ptacek's and Ferrie's papers, like e.g. that they seem to ignore the fact that SVM implements so called ASIDs - a mechanism which is *designed* to actually prevent guest's TLB flushes during VMEXITs, or I could mention the (not-yet-released) IOMMU feature, which should make it possible for something like Blue Pill Level 2 to not to worry about GART (BTW, BPL1 doesn't need to worry about GART by definition), etc...

But that's not the right direction for this discussion IMO. It's more then 6 months now since I presented Blue Pill for the first time and yet we still don't have any reliable, systematic, documented way to approach type III malware detection (and AFAIK, in case of AMD systems we also don't have any way to prevent it - at least this applies to machines myself and my colleges have)...

Some people work hard to find some "hacks" to prove that I was wrong saying the this technology could be used to build "100% undetectable" malware. Well, I'm pretty sure that they will find flaws in many particular implementations - in fact even we, in COSEINC, have found some already. But what does that proof? Only that the particular implementation, of either malware or the underlying virtualization technology, is buggy.

How do you guys imagine future commercial A/V products? Will they be based on many such hacks or maybe it would be better if they used some more reliable, documented and systematic approach? But there is no such solution - and there will not be any, if CPU vendors didn't introduce some changes, like e.g. adding special 'CHECK' instruction, which I discussed during my BH presentation.

So, that's how I see this: we have quite good, systematic methods to find type I malware, we don't have any good ones for the type II malware, but we can imagine to have them in the future, but as far as type III malware is concerned, I don't believe we can do anything *useful* without the help of the CPU vendors...

Although, I might be wrong and the real answer could be: 95faf2cfb27b4e271a8943ad44f7d865... ;)