Slashdot Mirror
Microsoft Research Warn About VM-Based Rootkits
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."
Original Paper
Abstract
Attackers and defenders of computer systems both strive to gain complete control over the system. To maximize their control, both attackers and defenders have migrated to low-level, operating system code. In this paper, we assume the perspective of the attacker, who is trying to run malicious software and avoid detection. By assuming this perspective, we hope to help defenders understand and defend against the threat posed by a new class of rootkits.
We evaluate a new type of malicious software that gains qualitatively more control over a system. This new type of malware, which we call a virtual-machine based rootkit (VMBR), installs a virtual-machine monitor underneath an existing operating system and hoists the original operating system into a virtual machine. Virtual-machine based rootkits are hard to detect and remove because their state cannot be accessed by software running in the target system. Further, VMBRs support general-purpose malicious services by allowing such services to run in a separate operating system that is protected from the target system. We evaluate this new threat by implementing two proof-of-concept VMBRs. We use our proof-of-concept VMBRs to subvert Windows XP and Linux target systems, and we implement four example malicious services using the VMBR platform. Last, we use what we learn from our proof-of-concept VMBRs to explore ways to defend against this new threat. We discuss possible ways to detect and prevent VMBRs, and we implement a defense strategy suitable for protecting systems against this threat.
Gan Family Homepage
Deserves to be modded Funny, yes. But I feel it neccesary to ask—
Surely re-flashed BIOSes (tampered firmware, that is) wouldn't be reset by simply taking out the battery? That just clears the settings, not the entire firmware. That's what puts the "firm" in "firmware".
The last motherboard I had was a gigabyte. It contained a Dual Bios system which could recover a user flashed bios back to factory defaults.
Complete and utter safety in case of a bad flash.
Heres a small THG article about it.
You are right about most machines however, it may not be enough unless you can replace the bios.
For the totally paranoid, take the suspect drive out and put it into a cleanroom machine.
liqbase
is to run under a virtualization manager from the beginning. Than, there will be no way for these VM-based rootkits to actually run on the real haardware. They'll think they are doing so, but the outermost vm will be able to detect them easily.
However, this virus dates back to the innocent days where a virus would just destroy your data or computer, rather than steal your information for profit or turn your PC into another node in some botnet collective.
The road to tyranny has always been paved with claims of necessity.
Here is how you detect any VMM on linux or Windows,no such thing as undetectable if you know how to find it. http://www.trapkit.de/research/vmm/scoopydoo/scoop y_doo.htm
Are the chips actually socketted though? Because with the price of things these days, it's actually cheaper to have two chips soldered onto the motherboard than one socket and two socketted chips. Sockets are not cheap, as far as the price of parts go.
Besides, swapping chips in a socket isn't a fun user experience, and these are probably high end boards where money isn't an object anyway.
That's fine if you don't like this, but don't lie about the technology and say that it doesn't help the user to trust the machine. It helps everyone trust the machine. That's why it's called Trusted Computing.
/me sips his Rye and cola....
Mmmmmm... KoolAid.
Dude, I trust a machine to do exactly as it's told. I do not trust humans to do the same. Trusted Computing is an aphorism for "Hey, you can trust $VENDOR, since your machine does, due to $TECHNOLOGY." Fuck that.
If you r00t a computer, you're after one thing - getting information _out_ of said machine. (THINK - Credit card #s or Spam - it all has to leave the machine somehow.) You need to do this via a network connection, USB key or some other means. There are ways of noticing that information has left a machine in some way, either through physical security or other means (It'll be a cold day in Hades before a vendor brings a cell phone into my data center. Those things have memory, after all.) since once outside the box it's no longer under the control of the r00tk1t. IOW, if someone r00ts one of my machines, it'll be either noticed or totally useless to them.
I, and I alone, establish trust of my systems. Any vendor who says they can do that for me is sadly mistaken, unless they are willing to allow me to completely vet thier Trust protocol and methods. Even then, I had better be able to fully audit that system at a whim, on my terms.
"Trusted Computing" is for those who don't want to learn or do thier job professionally, are just plain lazy or, they're willing to drink the KoolAid. As for users, they tend to trust people, like me, who fix thier broken systems, and take my advice to heart when I charge them $TEXAS for fixing thier broken assed PCs.
Soko
"Depression is merely anger without enthusiasm." - Anonymous