[cap-talk] Virtual Machine Based Rootkits
Jed at Webstart
donnelley1 at webstart.com
Thu Aug 3 21:29:41 EDT 2006
At 09:31 AM 8/3/2006, Karp, Alan H wrote:
>Joanna Rutkowska is the name I've seen associated with this attack,
>which is frequently called Blue Pill, from the Matrix. She has
>demonstrated a running version on Vista x64 and is presenting at Black
>Hat today. According to reports, she was able to install the rootkit on
>a running system, no reboot required.
>http://www.eweek.com/article2/0,1895,1983037,00.asp is a news article on
<still going on with the VMBR discussion not focused on capabilities.
Other lists or suggestions to move or stay gratefully accepted>
I should have mentioned in my initial message that I've seen some of
the Blue Pill discussion. I'm a bit uncomfortable with what I've seen about
it so far, e.g. (from the article you mentioned Alan):
"Blue Pill is being developed exclusively for COSEINC Research and will
not be available for download. However, Rutkowska said the company is
planning to organize trainings about Blue Pill and other technologies
where the source code would be made available."
There seems to me to be a bit too much notoriety and profit motive in
what I've seen about this work so far. I'll take it more seriously when it
gets "out there" and generally worked over in the academic and
general open source software communities.
>The key point is that you're both right. You are safer if you use a
>virtual machine to run Windows.
Or any other guest OS. Certainly true.
>However, if your base system gets
>infected, virtualizability assures that there is no mechanism by which
>the OS can detect the attack.
I think the above is an overstatement. Even if there was no way for an OS to
detect that it's running under a VMM (which there is - no VMM is completely
undetectable), there are other detection mechanisms. For example one can
power cycle the system, come up on clean media (e.g. a CD) and run an
analysis on the hard drive(s) - e.g. as discussed in the SubVirt paper. This
assumes that the BIOS hasn't been corrupted - which gets into another set
of issues independent of VMMs. You seem to be referring to detection
mechanisms in the guest OS. Even in the guest OS there are possibilities
(e.g. see the King paper), but that is where the purity of the VM comes
At 10:11 AM 8/3/2006, David Hopwood wrote:
>It is true to say that a guest OS cannot reliably detect a VMM in a
>way that is useful to prevent this kind of rootkit attack, in general.
>After all, we don't want guest OSes to refuse to run under any VMM;
>that would be more counterproductive than helpful.
I think this is what I was agreeing to above. However, regarding:
>Also, such a
>detection mechanism could be circumvented, if the attacker writes
>his/her code after the defender (and I believe this to be more practical
>than Jed does).
I don't recall saying anything about the above (the relative timing of
the attacker and defender writing code) and thinking about it just now
I don't have an opinion on it. Is there something I wrote that leads you
to think my view on this differs from yours? Are you referring to this:
I think there are a couple of points in the paper where the authors
got a bit enamored with their technology and seemed to suggest that it
could do things that I believe are difficult to impossible. For example,
when they were referring to efforts to detect a VMBR they said:
"...even if the target system did see something amiss, the VMBR could
tamper with the execution of the detector and force it to report incorrect
While I agree this is theoretically possible, I think in practice
it's very unlikely to ever be achieved.
? That is, a situation where the VMBR detects the execution of
rootkit detection software running in the guest OS and modifies
it's behavior in such a was as to render it ineffective in detecting
the VMBR or in reporting it's detection? If so then when you
consider the attacker writing their code after the defender you
must certainly consider the usual case that the "defender" code
will be regularly updated to detect new attackers. You might then
believe that this would be some sort of horse race, with the attacker
trying to keep updating the VMBR (presumably over the network -
which can of course be detected off the box, but never mind that) in
order to keep falsifying results for the defender. I believe even this
underestimates the difficulty for the attacker. It doesn't suffice for
the attacker to simply maintain the functioning of the virtual machine
and to reach into the guest OS's VM to modify the behavior of the
defender so as to appear invisible, it must also either:
1. not be detectable to the defender. This is a little like
stealth technology - where shared resources must be
used invisibly. I don't believe it's possible. Just for example,
the guest OS can assume it's running on the bare metal.
It can run randomized loops (e.g. with interrupts disabled)
where it should know exactly the number of cycles used and
be able to make counts of repeatable behavior. If the
behavior changes, it detects the VMBR.
2. even if the defender detects the VMBR, the VMBR will
reach into the guest OS and modify the detectors behavior
in such a way as to make it appear that the VMBR wasn't
detected and more generally no problem was detected. I
believe this would be quite difficult to accomplish. One thing
to keep in mind is that the detection software has the user
on it's side. It can set up some simple user interaction
that will help assure that it is operating unhindered.
The VMBR can't, for example, simply stop the detection
software from running and output what seems to it to be
nominally reassuring output.
I generally just feel that this is a situation that favors
the defense. I also don't think it's much impacted by
the effectiveness of the VM assist features in the hardware.
I know it's fashionable to be macho on the side of the
attacker in situations like this. I think there is ample
opportunity for a bit of macho on the side of the defender
in this situation.
Hey, I wonder if this is one of those sorts of situations where
a concrete enough bet could be set up to be meaningful?
For example, I could bet that the majority of commodity
processors sold in the year, say, 2011, will be virtualizable.
That is, all privileged operations will trap in user mode,
as with the current Intel VT and AMD Pacifica, so VMMs
can be run for unmodified OSs. Given the current state of
the art that seems a rather brash and, from my perspective,
hopeful position to take, but it might be fun to have a bet out
there to keep an eye on. Anybody have any thoughts on
such a bet, e.g. how to tighten it up or whether it seems a
reasonable bet? Certainly if virtualizability comes to be seen
as a negative feature because it makes systems more subject
to being invisibly rooted, then one would expect virtualizability
to die out or at least be compromised in some way.
>At 03:13 PM 8/3/2006, Karp, Alan H wrote:
>David Hopwood wrote:
> > That's not quite accurate; most VMMs are detectable, and
> > AFAIK all VMMs
> > that run on x86 hardware (VT, Pacifica or otherwise) are detectable.
>That's because x86 is not fully virtualizable. Rutkowska is working on
>architectures that are.
Huh? I thought the VT and Pacifica versions of "x86" are fully
virtualizable. Is that not true? My understanding is that all it
takes to be "fully virtualizable" is to have all privileged operations
trap in "user" mode. Perhaps I misread this, but I thought
Rutkowska was working with Pacifica. Not?
More information about the cap-talk