Keith Adams of VMware has a blog where he writes about his experiences virtualizing x86. In a well-written post, he discusses resource utilization techniques for detecting a hypervisor rootkit, including the TLB method described in his recent HotOS paper (alternate link).
We better find a way to derail Keith before he brainstorms any more of our techniques, although we have a reasonable claim that a co-author has published on TLB usage first. :-) Good thing side channels in an environment as complex as the x86 hardware interface are limitless!
7 thoughts on “Hypervisor rootkit detection strategies”
That’s why I always turn off the TLB and disable all caches!
If you want to get technical, I told Joanna at Defcon 2006 that Bluepill could be detected via the TLB; specifically I gave the case that I’ve run against while working inside of VMWare, where due to the 4-way set associativity of the DTLB (on the processor I was using), a forced entry (making a supervisor-marked page in userland address space user-marked temporarily followed by a DTLB load) would be replaced in the DTLB due to code executed by VMWare, resulting in a reproducible looping page fault at the instruction trying to access the page referenced by the replaced DTLB entry. She admitted that this would detect Bluepill on current hardware and proceeded to turn around and tell a MS security engineer about the method — while I was still standing there. So much for sharing information ;) As further verification, I mentioned the same thing to Joe Stewart after his OllyBone presentation (and emailed him about it prior to Defcon).
Anyways, don’t argue over who is first, as I’m sure guys at VMWare have known about this for much longer, and I know that the PaX team has known about it since implementing PAGEEXEC for x86 in 2000. (That’s 7 years ago, compared to that Sept 06 article you linked to)
I must confess that I am completely ignorant when it comes to these things. The only reason I am here is I bumped into a link to your site from a completely unrelated discussion. But you got yourself an RSS subscriber from it. :)
This challenge caught my attention so I read your last three blog entries — but to detect any kind of rootkit, all you’d need to do would be make a call to some system function (check how much long it costs), and then do the same with a function that is likely (!) masked — or you need to trust. Rince and repeat a couple of million times and if the difference of the two calls in cost does not match up to a verified clean environment… Then we have a rootkit?
(to give you an example of just HOW ignorant I am: What the heck is a TLB. I’m not really asking as I could look it up, but it’s a decent example) :)
Anyway, maybe that is exactly what this blogpost is talking about (so I post anonymously as to not make a fool out of myself). I’m intrigued. :)
Yes, my main point is not who thought of it first. Note the smiley. We may be the first with working code unless Joanna has implemented this attack since there are only two known VT rootkits.
What’s next? Removing power supply?
Longpoke, Tim was joking. He doesn’t do any of that.
what’s about the possibility to intercept the INVD, INVLPG etc. commands by the VM?
Could you provide at least the TLB test (showed in the BlackHat-Trainings) as source in this forum – thanx
Now I’m really, really worrying about the “super” VM feature of all new processors.
Comments are closed.