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
Traditional malicious software is limited because it has no clear advantage over intrusion detection systems running within a target system's OS. In this paper, we demonstrated how attackers can gain a clear advantage over intrusion detection systems running in a target OS. We explored the design and implementation of VMBRs, which use VMMs to provide attackers with qualitatively more control over compromised systems. We showed how attackers can leverage this advantage to implement malicious services that are completely hidden from the target system and to enable easy development of general-purpose malicious services. We evaluated this new malware threat by implementing two proof-of-concept VMBRs. We used our proof-ofconcept VMBRs to subvert Windows XP and Linux target systems and implemented four example malicious services.
In addition to evaluating the VMBR threat, we also explored techniques for detecting a VMBR. The best way to detect a VMBR is to control a layer beneath the VMBR, such as through bootable CD-ROMs, secure VMMs, or secure hardware. It might also be possible to detect a VMBR from software running above the VMM, but the high level of control VMBRs have over software running above turns this style of detection into an arms race where the VMBR has the fundamental advantage.
However, VMBRs have a number of disadvantages compared to traditional forms of malware. When compared to traditional forms of malware, VMBRs tend to have more state, be more difficult to install, require a reboot before they can run, and have more of an impact on the overall system. Although VMBRs do offer greater control over the compromised system, the cost of this higher level of control may not be justified for all malicious applications.
Despite these shortcomings, we believe that VMBRs are a viable and likely threat. Virtual-machine monitors are available from both the open-source community and commercial vendors. We built VMBRs based on two available virtual-machine monitors, including one for which source code was unavailable. On today's x86 systems, VMBRs are capable of running a target OS with few visual differences or performance effects that would alert the user to the presence of a VMBR. In fact, one of the authors accidentally used a machine which had been infected by our proof-ofconcept VMBR without realizing that he was using a compromised system!
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.
They even have a public research website
This issue is a bit more complicated than you think.
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
Close but not quite...
The rootkit IS the virtual machine, AND the host OS. It is what loads when the computer boots up. Then it sets up it's own virtual machine (Like vmware, et al., but it's own implementation) and boots the computer into that virtual machine. The OS can't detect this rootkit through normal means because the methods it would use to detect it could be emulated by the virtual machine to look correct. There is no "host OS" to detect the rootkit or not, because the rootkit IS the host OS.
Of course, there are plenty of ways to detect if you are running within a virtual machine.
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
I think you're thinking of Reflections on Trusting Trust by Ken Thompson.
There are a lot of ways to implement it, but my personal preference runs like this:
1) The initial boot code that checksums the main BIOS is on an OTP device.
2) The OTP device has sole control of its own write enable pin. No other device on the motherboard has a connection to this pin.
3) Similiarly, the OTP device also has sole control of its own chip enable pin.
Here's the theory of operation: When a hard power-on occurs, the OTP device is the memory from which the CPU boots. Thus the OTP is always the first to get control, even before the normal BIOS. The OTP runs a checksum on the regular BIOS, and compares it to a checksum it has recorded. If the checksums are different, it throws up the warning message.
If the user presses "Yes, save updates" the OTP device (which is still in complete control of the machine from a hard power up) briefly enables its own write enable pin, which no other device but itself has access to, and writes the new BIOS checksum into itself. After writing the new checksum, the OTP device disables its own write enable pin, so no software can write to it.
Then the OTP instructs the CPU to jump to the first instruction of the normal BIOS, and simultaniously turns itself off by means of its own chip enable pin. The chip enable signal will go from enabled to disabled faster than the CPU can execute the first instruction in the BIOS. So by the time the first BIOS instruction begins executing, the OTP device is dead to the world and cannot be reached by anyone or anything. All of its pins are disabled, and it is as if it never existed. It can even turn off its own power if a little outside logic (a D flip-flop with its output tied back into the clock input) is employed.
The only way to get the OTP back in communication with the outside world is to remove power and reapply it, e.g. do a hard reset. Yanking on the CPU's reset line won't work, because the OTP neither knows nor cares about the reset line. Since the OTPs chip enable line is disabled, nothing but a power-off and then power-on will bring it back. And when the power comes back on, the OTP will be the first and sole controller of the CPU again.
There are many more clever ways to implement this kind of thing. You can have the BIOS checking routines built into a truly non-programmable mask ROM, and only the checksums in an OTP memory. The OTP's read and write enable lines could again be controlled soley in hardware so that only while the mask ROM was executing could the OTP be read or written.
Of course, birthday attacks (rewriting the BIOS in such a way that the old and new versions have the same checksum) are still possible. However, this can be reasonably mitigated by using a good secure cryptographic hash (SHA-512?) and perhaps even post-encrypting the hash value with a key known only to the mask ROM.
There are lots of games you can play when you have control of the hardware. None of them will prevent a smart guy with an oscilloscope from hacking your computer, but software-only attacks they can prevent. Don't you think the guys who proposed Palladium and other hardware DRM systems have already considered all this?
How else would you research security ? How are you going to defend an OS against sophisticated attacks unless you know how to perform the attack in the first place ? How else you going to test the security of an OS without attacking it? If I were running Microsoft I have a team dedicated to hacking the OS (at any level), and pitch them against the team dedicated to securing the OS.
Close, The story hinges on the use of a "zone implant", a mind control device. I'm sure the perversions (sex and torture) are a reasonable facsimile of how people would behave given absolute control over someone else, and no peers to intervene. It is not over a day or so, though, more like years.
If conspiracy theorists could be beaten with facts they would be. The facts, however, are in favor of the conspiracy theorists.
Conspiracy theories bloom in the absence of fact; if there were facts to deal with, the theories could be either proved or disproved.
To control someone, all you needed was, IIRC, a combination of making them submissive and pleasure, and just the tiniest bit of pain, and they'd follow you around like a puppy, hoping for another burst of pleasure.
Donaldson really thought out all the tech aspects of those books.
If corporations are people, aren't stockholders guilty of slavery?