Slashdot Log In
VM-Based Rootkits Proved Easily Detectable
Posted by
kdawson
on Tue Oct 02, 2007 01:35 AM
from the take-one-blue-pill-and-call-me-in-the-morning dept.
from the take-one-blue-pill-and-call-me-in-the-morning dept.
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."
Related Stories
[+]
Microsoft Research Warn About VM-Based Rootkits 336 comments
Tenacious Hack writes "According to a story on eWeek, lab rats at Microsoft Research and the University of Michigan have teamed up to create prototypes for virtual machine-based rootkits that significantly push the envelope for hiding malware and maintaining control of a target OS. The proof-of-concept rootkit, called SubVirt, exploits known security flaws and drops a VMM (virtual machine monitor) underneath a Windows or Linux installation. Once the target operating system is hoisted into a virtual machine, the rootkit becomes impossible to detect because its state cannot be accessed by security software running in the target system."
[+]
Technology: Blue Pill Myth Debunked 128 comments
njyoder writes "As previously posted about, Joanna Rutkowska claimed to have discovered an allegedly undetectable vulnerability in Vista that takes advantage of AMD cpu's virtualization capabilities. a virtualization professional (Anthony Liguori of the Xen project) has now voiced his opinion to state this is bunkum.
There are two parts two this — the ability to take over the machine and seamlessly drop the OS into a VM (which is very difficult, but possible) and the ability to have windows run in the VM undetectably (which is impossible). In fact, Rutkowska's prototype is VERY detectable.
This is unfortunate mistake that people make when they jump to conclusions based on what is unfounded speculation and that includes the assumption that this would somehow be Vista specific, if it worked (noting that Vista doesn't run with administrator privileges by default)."
[+]
Hacker Defeats Hardware-based Rootkit Detection 126 comments
Manequintet writes "Joanna Rutkowska's latest bit of rootkit-related research shatters the myth that hardware-based (PCI cards or FireWire bus) RAM acquisition is the most reliable and secure way to do forensics. At this year's Black Hat Federal conference, she demonstrated three different attacks against AMD64 based systems, showing how the image of volatile memory (RAM) can be made different from the real contents of the physical memory as seen by the CPU. The overall problem, Rutkowska explained, is the design of the system that makes it impossible to reliably read memory from computers. "Maybe we should rethink the design of our computer systems so they they are somehow verifiable," she said."
[+]
Rutkowska Faces 'Blue Pill' Rootkit Challenge 223 comments
Controll3r writes "Three high-profile security researchers — Thomas Ptacek of Matasano Security, Nate Lawson of Root Labs and Symantec's Peter Ferrie — have issued a challenge to Joanna Rutkowska to prove that her 'Blue Pill' technology can create "100 percent undetectable" malware. The Black Hat 2007 challenge will feature two untouched laptops of the make/model of Rutkowska's choosing for her to plant Blue Pill on one. From the article: 'She picks one in secret, installs her kit, sets them up however she wants,' Lawson explained in an interview. 'We get to install our software on both and run it, [and] we point out which machine [Blue Pill] is on. If we're wrong, she keeps the laptop.' No word on whether Rutkowska will accept the challenge."
[+]
Hiding a Rootkit In System Management Mode 119 comments
Sniper223 notes a PC World article on a new kind of rootkit recently developed by researchers, which will be demoed at Black Hat in August. The rootkit runs in System Management Mode, a longtime feature of x86 architecture that allows for code to run in a locked part of memory. It is said to be harder to detect, potentially, than VM-based rootkits. The article notes that the technique is unlikely to lead to widespread expoitation: "Being divorced from the operating system makes the SMM rootkit stealthy, but it also means that hackers have to write this driver code expressly for the system they are attacking."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
I may be mistaken... (Score:2)
Re: (Score:3, Informative)
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.
Re:I may be mistaken... (Score:4, Informative)
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 [ibm.com]"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 [acmqueue.com] 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!)
Parent
I also may be mistaken... (Score:2)
Or are the sheeple waving their "Never forget" banners loudly?
Re: (Score:3, Insightful)
Well, maybe except those who still buy sony music.
I stopped buying music-cds altogether when one of them installed crap on my winbox.
why I like open arch/code (Score:2)
Re: (Score:3, Insightful)
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
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.
Parent
Re: (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
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.
Parent
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.
Parent
Re: (Score:3, Insightful)
1. Do you really wish to manipulate the clock for every non-privileged instruction, which will result in a horrible VM performance?
2. 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)
What I was trying to say was that it takes a painful amount of performance over
Re: (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 c
Re: (Score:2)
That's simply not how it works. This isn't DOS, and there isn't a simple BIOS call the OS uses to retrieve the current time. Start here: the X86 has a 64 bit timebase register, the TSC, which reports cycle-count time in about 150 cycles directly from the hardware. Joanna tried to virtualize the TSC and found that she couldn't do it reliably under AMD SVM. She had to resort to dynamic code translation, VMware-style, to detect and modify code that probed the TSC. The problem with that approach is left as an e
Re: (Score:2)
Re: (Score:2)
Trivial for who. How often do you scan and compare your list of hardware devices in normal operation. How often does your mom.
Remember: trojan makers aren't interested in hacking hardened hacker's computer. They're interested in the mythical mom.
If my antivirus will detect hardware changes then it'll whine on actual hardware changes too. We arrive at the fact that Joanna discovered: it'll be god da
Re: (Score:2)
Re: (Score:2)
But it is also a problem if you are trying to hide a virtual machine, because the complexity of operation creates a sort of "timing fingerprint" that is unique to
Re: (Score:2)
"Undetectable to grandad"? Asinine.
The threat model facing rootkits is not end-user computer savvy. It's conventional anti-malware software. The question isn't whether the person sitting at the computer is smart enough to notice a 60% slowdown. It's whether the impact the rootkit has on the system is reliably measurable, either directly or through a side-channel, in a way that can be harnessed by Norton Antivirus. If it is, you lose; your "undetectable rootkit" is now literally a bullet point on the packag
Re: (Score:2)
Full vm (Score:3, Insightful)
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.
Re:I read the paper [no you didn't] (Score:2)
You clearly didn't read the paper, because it doesn't simply describe how "industry standard VMs operate". Garfinkel and Ferrie are talking about fundamental X86 architectural issues that make intercepting hardware accesses and emulating them in software perceptable to code running on the same machine. The Blue Pill VMM rootkit doesn't leave important instructions "unvirtualized", but it has to operate within the X86 memory hierarchy, and so remains detectable.
For example, the fact that a transition in and
Re: (Score:2)
You mean like the Bochs Pentium Emulator [sf.net]? Because - that is pretty much what they do. They emulate the entire computer, processor included. There was one branch that used a Linux module to use real hardware to speed things up (x86 only), but it otherwise fully emulates the computer including all instructions of the emulated processor and the system timer.
They've done a great job with it. However
Missing the point (Score:5, Insightful)
See virtualization-detection-vs-blue-pill [blogspot.com] and her presentation on the subject here [bluepillproject.org]. No one ever said that detecting a virtual machine is impossible. They are saying discriminating between malicious and non-malicious VMs is impossible.
Re: (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: (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 ha
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Because the software that "average users" run, tends to be written very quickly instead of carefully. You explicitly mentioned MS Word! You just mentioned email and web browsing too, where th most popular applications have repeated histories of bugs that allow them to treat supposedly-harmless data as executable code. Hell yes those should be sandboxed to contain destruction. Maybe VMs aren't the b
Re: (Score:2)
Re: (Score:2)
Be fair: the only researcher saying that "hypervisors can be detected, but rootkits can't" is Joanna. The rest of us, from what I can see, agree: you might not be able to detect Blue Pill by name, but you can detect unauthorized virtualization, even if you're already legitimately virtualized. Currently, the only source of unauthorized virtualization? Blue Pill.
Re: (Score:2)
Ah. Reactive security culture. (Score:5, Insightful)
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.
VM Detectors will break on new hardware (Score:2)
Transmeta transcodes source instructions into its native code
New versions of Intel and AMD processors and motherboards most probably will not have the same instruction timings or emulate undocumented aspects of current hardware and software
New hardware-based virtualization techniques may not change CPU performance much and can allow guest OS direct access to selected hardware
The bottom line is that VM detectors can only reliably fingerprint hardwa
Re: (Score:2)
Homeland security? (Score:2)
Another concern is that this study is presented by those companies that have a stake in spreading positive news about it. And tadaa: the news
Re: (Score:2)
It seems I caught a nice rightwing coward that has to satisfy his righteous feelings everytime he encounters something that he thinks does not toe the party line. Anonymity + Audience => gibbering fucktard. There are other countries in the world, you know, where critical thinking is encouraged. Sadly you can't see the good points in that. But you would prefer armed citizens that can't think for themselves, don't you?
Now again: why does the DHS
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.
Detecting Virtual Machines (Score:3, Insightful)
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
Re: (Score:2)
Malware hosting doesn't have to be perfect and hide its presence in every possible way. It just has to hide in the ways that the market-leading malware detectors use. A malware author can just set up a test system and each time the detector finds a hit, track it down and emulate around it. As you sugges
Re: (Score:2)
Thank you, Mr. Turing. May I have another? (Score:4, Insightful)
Folks, this is the Halting Problem [wikipedia.org]. 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&
We are in a virtual world (Score:2)
Are You Living In a Computer Simulation? http://www.simulation-argument.com/ [simulation-argument.com]
Re: (Score:2)
An Anonymous Coward wrote:
Your gods are mere pebbles beneath the Hooves of the Invisible Pink Unicorn (MPBUHHH).
And that’s the whole point, really
No Security Implications (& nothing re: rootki (Score:2)
It looks like they're just talking about detecting if you're virtualized or not. So perhaps some of these techniques could be used by user-hostile software publishers (i.e. you're not allowed to run our server in a VM without getting a special (i.e. more expensive) license, or you're not allowed to run our media player unless we know it is directly accessing the display hardare) but I don't see how this gives any rootkit-detection advantages.
And don't ever forget: from a security standpoint, detecting mal
Re:Does this mean that The Matrix was a load of bu (Score:2)
Re:First to say... (Score:5, Insightful)
Parent
Virtual Virtualization (Score:2)
For that reason I fully expect in the not too distant future that we will have virtual machines running inside virtual machines. That is there will be
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.
Parent