Slashdot Mirror
VM-Based Rootkits Proved Easily Detectable
paleshadows writes "A year and a half has passed since SubVirt, the first VMM (virtual machine monitor) based rootkit, was introduced (PDF), covered in the tech press, and discussed here. Later Joanna Rutkowska made news by claiming she had a VMM-based attack on Vista that was undetectable — a claim that was roundly challenged. Now in this year's HotOS workshop, researchers from Stanford, CMU, VMware, and XenSource have published a paper titled Compatibility Is Not Transparency: VMM Detection Myths and Realities (PDF) showing that VMM-based rootkits are actually easily detectable."
I'm still convinced that it's possible to make a VM that appaears to software running within as real hardware.
The paper, however, takes a practical approach, examining how some industry standard VM-s operate, such as VMWare and Virtual PC.
Those VM-s take plenty of shortcuts to improve performance, and don't virtualize some instructions, rather remap them, or "shift rings" of execution etc. as much as possible so to take advantage of the hardware while remaining sandboxed. They don't virtualize the clock as well, so you could time the performance.
A rootkit isn't competing with other rootkits based on performance, it does so based on how undetectable it is. It's arguably a different problem. I think we're yet to witness what a full blown VM made to be a rootkit will act like, and whether it'll be detectable.
Unfortunately, this paper completely misses the point. This paper is not so much about detecting a VM based rootkit so much as it is about detecting VMs in general. The authors argue is that if you detect a VM when you aren't expecting to, you've found a rootkit. Joanna's argument is that in a few years, everything is going to be using VM technology and you won't be able to tell a "good" VM from a "bad" one.
See virtualization-detection-vs-blue-pill and her presentation on the subject here. No one ever said that detecting a virtual machine is impossible. They are saying discriminating between malicious and non-malicious VMs is impossible.
This is undetectable*!
That is undetectable*!
* Undetectability based on current technology and the fact that nothing about a given vector of attack has been defined or studied in depth yet. Claim subject to change once the phenomenon has been studied, quantified, and dissected in a rational, forensic manner.
Translation: You can't detect it because you aren't looking for it (yet).
Translation 2: This new attack can't be defeated because nobody's tried yet!
That's what so many of these "security researchers" and pretty much ALL of the tech-press forgets.
Like any other system security compromise, the amount of time these things remain "compromising" depends largely on how long it takes to define it.
Chas - The one, the only.
THANK GOD!!!
Virtual Machine Monitor and Hypervisor are synonyms. Hypervisor however generally implies a monitor running on the bare hardware (type 1 virtual machine) whereas VMM may also refer to a monitor running as a userspace process on a host kernel (type 2 virtual machine). Thus it is correct to call bluepill either a hypervisor or a VMM.
Generally the term VMM is much more common with implementors of these systems, however hypervisor is easier to say and sounds cooler so its common with users.
When Argumentum ad Hominem falls short, try Argumentum ad Matrem
Where exactly are you going to buy a complete system with a fully documented processor, BIOS (or equivalent firmware) and all component parts right the way down to the Verilog (or [insert chip design software here]) source files?
Bearing in mind that even then you need to prove that the chip you hold is the same one described by the source files, and the only way you can guarantee that is if you control the chip fab which produces the chip. Failing that, I suppose you could skim the top off one and examine it with an electron microscope, but the chip is going to be history afterwards so you need at least two chips - and then how do you prove that the one you leave alone is identical to the one you examined in your handy-dandy scanning electron microsocope?
Note: I'm well aware this is absurd. That's the point.
And what's Tommy the Tank Engine security?
:)
"I think it's safe! I think it's safe! I think it's safe!"
Look. Virtualization is not a security technology. I've gotten a VMWare engineer to admit this publicly, on stage, with only mild needling. Virtualization reduces hardware to a protocol that must be parsed, or (as is increasingly common) it allows direct passthrough to devices on buses that have no conception of host vs. guest (see: USB).
There was actually some really cool work recently done by Jeff Forristal, who pointed out that since all VM's are on the same LAN, all the old LAN-based attacks work really well cross-VM. Oops.
Now, regarding Joanna's attack, she's completely right that everyone's going to virtualization -- it's just so much more manageable. The consumer market will eventually embrace this.
Actually, when people are being aware of how they're mistreated, and protest it loudly (enough for others to notice), I don't think they qualify as being sheeple.
Well, maybe except those who still buy sony music.
I stopped buying music-cds altogether when one of them installed crap on my winbox.
Blah blah sig blah blah blah irony blah blah
Of course, this basic problem was described quite eloquently by Ken Thompson. He went after the compiler, but the problem of proving that the binary you have matches the source you have is a tricky one no matter what.
There actually are some very clever solutions to try to catch cheating compilers like this, but none of them are trivial. It's a cat and mouse game, and there are actually proofs that winning either side completely is impossible.
The current commercial vm's don't try to be undetectable. But if a vm was created with the purpose of being undetectable might be a different matter.
It might be possible to create a vm that only visualizes a specific part of a pc. Only hide some memory and disc space, and passing all other parts through to actual hardware. I don't know if it is feasible.
VMWare is virtualization software, not emulation software. It runs pretty close to native speed, depending on what you run on it. Comparing it to bochs is just stupid, that's a full blown emulator. A VM still uses your processor natively to decode the majority of instructions, it just catches the privileged ones, that otherwise would make your OS go boom. (Simply put)
A properly-created virtual machine ought to be absolutely undetectable from withinside. The simple fact is that all commercial offerings to date haven't tried to be undetectable.
..... but on the inside, you don't know it's slow, precisely because you've been fed misinformation about the time things are taking. And processors are getting faster. They used to think that chop-and-swap analogue TV encryption would never be trivially crackable in practice .....
If you lock a person in a windowless room where the only "access to the outside world" is a TV set where you control all the programmes, you essentially control everything they know about the outside world; and you then can make that person believe anything you want them to believe. You could even cause them to think night was day, if their only reference was the continuity announcer's time checks (and/or you could give them a special watch which displayed your manipulated version of the time). But if you accidentally or deliberately let, say, BBC1 get through unaltered, you aren't controlling everything they see; and by comparing the news on the real BBC1 with your altered news on the other stations, they could ascertain that something was amiss.
If your virtualised environment behaves absolutely "correctly" with respect to undocumented instructions and the like (i.e. they aren't trapped and made to do something specific to your virtualisation application), and all I/O channels are properly manipulated (to the point where even the scan line count on the graphics card is adjusted to account for the slowdown in the virtual environment), then it's undetectable from withinside. If, however, even one undocumented instruction does not behave exactly as the real processor, or even one I/O channel is left unmunged, then there is a potential way the virtual environment could be detected.
Of course, all that manipulation of stuff is bound to impose some kind of overhead, so a truly undetectable VM might end up being slow as hell
Je fume. Tu fumes. Nous fûmes!
Folks, this is the Halting Problem. If you have a foolproof method of detecting that you’re running in a VM, you can build a special-purpose VM that watches for that method specifically to defeat it.
Similarly, you can’t ever rule out the possibility that you yourself are living in a Matrix-style (etc.) simulated world. You might be able to detect that you are under certain circumstances, but any sufficiently advanced simulation is indistinguishable from reality. No, really!
Oh — and all this applies equally to any supposedly “omnipotent” deities you might care to propose. After all, if “God” could trap “The Devil” (to pick the current favorite pair of arch-rival gods) in a simulated world such that The Devil thought that he (The Devil) was the all-powerful creator of life, the universe, and everything ... then God has no way of knowing that The Devil hasn’t done the same to him. And if God doesn’t have any foolproof way of knowing whether or not The Devil has him trapped, and if he himself has no foolproof way of trapping The Devil, it hardly makes any kind of sense to describe God as “all-powerful,” now, does it?
Cheers,
b&
All but God can prove this sentence true.
On a native machine, we achieved about 55-70 transactions per second, after that, the CPU of the machine was maxed out. This was a quad Xeon with about 16 gigs of ram. The same exact machine, running ESX host, and one single VM, one, our Windows 2003 server, was able to achieve about 2-5 transactions per second before the host throwing in the towel. Now I am sure ESX 3 will be faster. This wasn't ESX 3, was 2.something.
What I noticed was that:
- VMWare has a lot of trouble with applications who do a lot of context switches. Basically, object pools with significant usage. If the CPU has to swap from thread to thread, it kills VMWare.
- We did a few network tests with bizarre results like VM network latency being 50% more. This is a killer with any system remotely trying to get a decent transactions per secon. We had to de-virtualize our SQL server and SNA gateway, it wasn't able to hold the load.
- For some odd reasons MOM, anti-viruses and SMS can choke a host without any problems. My hypothesis is that missed file cache is brutal for VMWare, especially if other VMs are doing some I/O intensive stuff.
I wouldn't recommend anyone putting a server with moderate to high load as a VM. However, VMWare is awesome for very low load server, we can pack 6-10 of these servers easily on the same dual dual core Xeon. And could probably more.
An example Virtual Machine Monitor without a Hypervisor is VMware Workstation: a small VMM is loaded to run the guest OS, but it is not complete enough to run the system - it has no task switcher, no memory manager, etc. The host OS acts as the hypervisor here - it is the source of highly-privileged operations unavailable to the guest. Another no-hypervisor VMM is KVM: KVM just runs a virtual machine, but depends on the rest of Linux to run more-privileged operations (and Linux itself becomes the hypervisor).
An example Hypervisor without a Virtual Machine Monitor is the partitioning software on high-end IBM, Sun, etc. machines, which allows you to physically partition the processors of the system into several actual machines - partitioned machiens with zero run-time interdependencies. Literally, a "hypervisor" is something which runs at a privilege level higher than the "supervisor" (the OS).
Hypervisors and virtual machine monitors have existed since the 1960s. Nobody confused the terms then. IBM started the confusion with a whitepaper"inventing" the type 1 / type 2 taxonomy to distinguish between 1960s-modern IBM mainframe architectures (low-end = hypervisor only, high-end = combination hypervisor/vmm) and the VMware Workstation architecture (host OS loads vmm; host OS acts as hypervisor). Note that VMware never claimed Workstation was a hypervisor! Certain communities (Wikipedia, the press) have accepted IBM's whitepaper as gospel truth, thus the prolifieration of "type 1" and "type 2" terms the past several years. (The same community has chosen to ignore academic research in the 1960s and 1996-2005 which used VMM and Hypervisor correctly.)
With apologies to many individuals who are legitimately using correct terminology, some poorly-informed folks are propagating the "type 2 hypervisor" meme to attempt to equate the abilities of a hypervisor/VMM with a VMM. This is not correct: a combination hypervisor/vmm ALWAYS can achieve better performance than separating the hypervisor and VMM - at the cost of creating a more complex hypervisor (ESX requires custom drivers; Xen requires a customized dom0). The fault for this confusion really rests with Intel: their VT extensions (and AMD's SVM response) have made it so easy to create a VMM that some folks are creating a VMM, then marketing it as a hypervisor in a misguided attempt to compete with existing hypervisors (ESX, Xen) instead of competing with other VMMs (VMware Workstation/Fusion, KVM, Parallels Desktop)
To understand what a VMM is, read this ACM article by Mendel Rosenblum. Academic research generally looks at VMMs (ways to run a virtual machine), not hypervisors (ways to run something with less privileges than the hypervisor). A rough gage of the quality of academic work is whether they manage say Hypervisor when they mean Virtual Machine Monitor. Anyone who thinks the two are the same is ignorant of the past ten years of academic research - and anyone ignorant of ten years of research is doing very poor-quality work. (Alas, Wikipedia chose to use the IBM whitepaper for defining terms instead of many years of published, peer-reviewed papers. Great "neutrality", folks!)
A witty [sig] proves nothing. --Voltaire
How did they install crap on your winbox (are you running a ssh server)? I suspect that you installed that crap, or that your OS' virus-support feature installed it for you as a "convenience." Software, no matter how bad, sitting on a CD doesn't just execute itself. Something or somebody (and it wasn't Sony, because they had not yet compromised your machine) decided, "Let's load and execute Sony's malware." Find out what that something or somebody is, and you've found your real problem. Avoiding Sony won't really help you.
Not that Sony has any excuse for offering malware with their music. But don't accuse them of installing it, because they didn't.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Now you've simply pushed the problem a level higher, into the assembler / linker. Yes, it helps, but there are other techniques as well.
The most elegant technique I've seen goes like this. Maintain trusted dead-simple non-optimizing compiler A (possibly on a different machine). You also have untrusted compiler B, and it's alleged source SB. Compile SB with B, resulting in B. Compile SB with A, resulting in B'. These binaries will be different, but should be functionally equivalent -- B' is probably larger and slower, thanks to having used non-optimizing compiler A to make it. Now, use B' to compile SB, resulting in B''. Since B' and B should produce equivalent output, B and B'' should be bitwise identical. If they're not, you have a problem.
At this point, you simply (heh) have to trust that your OS isn't playing games like showing you different binaries than its running and such. Again, there are similar techniques to deal with this, but the problem can't really be removed without establishing a trusted chain all the way back to the chip fab, through the assembler, linker, compiler, and OS. It's a tough problem.