VM-Based Rootkits Proved Easily Detectable 128
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 read the paper (Score:5, Interesting)
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.
Re:I read the paper (Score:4, Interesting)
Instead, what I think is it's not *impossible* to detect, but it's *difficult* to detect, because the VM detector is going to need a very very very long checklist to determine whether it is running on a VM or not. To be sure, it must check every possible privilegd instruction's timing, check the system memory's contents using various workarounds (such as DMA), and etc. etc.
Re:I read the paper (Score:4, Interesting)
Two things:
1. You assume the clock isn't manipulated, hence fast commands should be slowed down to match virtualized instructions. Instead the direct instructions may be left running, and the virtualized to skew the clock subtly enough to be undetectable to the naked eye, and match well with the hardware performance to a detector running within.
2. We're soon about to get plenty of cores on desktop machines, where most of the tasks are serial. If a VM would make use of the extra cores to simulate a single core in around 50-60% its native speed, it may prove undetectable to granda who just browses the net and uses Excel.
Re:Missing the point (Score:3, Interesting)
I fail to see what purpose the average user has for VM technology. Sure, it's great for server systems, and as a developer I find it extremely handy, but if all you do with your computer is read e-mail, browse the web and run MS Word, why would you want a VM?
Re:I read the paper (Score:3, Interesting)
The huge majority of time the computer is running "userspace" commands. Do the math.
Yes, your grandpa won't notice a 50% slowdown, but your anti-virus software will easily notice. It's either your grandpa doesn't notice and your anti-virus does, or your anti-virus doesn't and your grandpa does (assuming the anti-virus software does a extensive amount of checking)
The anti-virus can't detect jack since the the rootkit can report any clockrate to it. Remember: the hardware configuration the software sees is what the rootkit opts to report.
Tommy The Tank Engine Security (Score:3, Interesting)
"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.
Re:why I like open arch/code (Score:4, Interesting)
Of course, this basic problem [bell-labs.com] 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.
Re:Missing the point (Score:3, Interesting)
Lots of reasons: fault isolation (e.g. jail() on steroids); compatibility isolation (e.g. while most of my system runs the newest version, I keep my old apps running in a VM with an older kernel); hardware interoperability isolation (e.g. this bit of hardware is only supported in Windows, but I stick an API translator on top so I can use it from Linux with a stripped down Windows installation); virtual appliances - so that I boot my laptop only to play my DVD or check my email [without a large kernel to support it], but I want to be able to use the same application when I'm in full OS mode, so I run the app in a VM; Reliable suspension of desktop OS and associated (virtualised) peripherals. A lot of these things can be done without virtualisation - but since its now a CPU supported system, why not use a hypervisor?
Virtualisation is a useful technology in many ways - it's just deployed in different ways from use case to use case.
--Ng
Re:First to say... (Score:4, Interesting)
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.
Re:I also may be mistaken... (Score:2, Interesting)
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.
Re:why I like open arch/code (Score:3, Interesting)
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.