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."

Comments

ROM Boot Keys

[PktLoss]

It may not be feasible for home environments, but for workplaces. What about booting off either dedicated ROM boot keys, or USB memory keys with a some sort of physical read only/read&write switch. Put the key into your machine to boot (for bonus points, the key tells the machine who you are and begins to load your roaming profile), when it comes time for a new image the IT guys either give you a brand new ROM key, or update your USB key by toggling the switch.

My worry with keeping things inside the machine (the article indicates that AMD and Intel have ideas) is that it's just going to be a perpetual arms race. Since we can't rely on the user to know when it is and is not apropriate to allow your OS to modify your boot sector, evenually virus/malware authors will just trick people into accepting the updates.

Link to research paper

[saikatguha266]

Here is a link to the actual paper the article references:
    http://www.eecs.umich.edu/virtual/papers/king06.pd f

The authors make an interesting point -- users and rootkits are about control. Whichever one controls the outer layer wins. If the user is in a protected environment, a rootkit running as root can win. If the user is root, then the rootkit must be a kernel-level root-kit and run in the kernel. If the user can control the kernel, the rootkit must control the machine, in this case, put the user kernel in a VM.

My take is: in this game of cat and mouse, you'll stop only at the hardware -- it is hard for a rootkit to control the hardware short of the rootkit script kidde being able to get physical control. So yes, the user can win this game, if he controls the hardware that controls the software. How does the hardware control software? You guessed it: trusted computing ala TCPA ala Palladium etc etc.

Can you think of a way to win against rootkits without TCPA?

Re:Link to research paper

[Jon Luckey]

Can you think of a way to win against rootkits without TCPA?

A rootkit can really only win if its undetectable. If you are playing a game of who has control of ring-zero resources, the victim, if running in a VM should be able to do various things that would cause an exception when it tried to do ring-0 only hardware accesses. If the exceptions are not what is expected, then the victim would be able to detect that its not in true control.

It might be possible to make a VM that tried to emulate ring-0 hardware access in user mode. Been a while since I looked at that area of cpu's. But if so, I'd expect it to be much more complex than a normal VM.

But suppose it is possible to test for true ring-0 hardware access. Then the root-kit has to fall back to classical root-kit techniques. It has to subvert the detection software. That task can be made difficult by classic defenses, like trip-wire, or running software from read-only sources, etc.

Re:Link to research paper

[Tyger]

Speaking just of the x86 architecture...

The thing with emulating a "ring 0" environment is that there is a lot to emulate. Most everything that would not work in a true ring 0 environment would cause the CPU to raise an interrupt for the host OS to handle. Typically the OS handles it by smacking around the application for being bad and doing something it isn't supposed to do. But it is possible to instead do what it is trying to do, and make it look like nothing was amiss.

The trouble is there is a lot of different things to deal with. If you know your target OS, it's easier since you don't need to emulate every little thing the CPU does, just what the OS will be using. But even then there will always be telltale fingerprints that something is amiss. Theoretically you could get around some of them by scanning ahead the instructions to be executed, but at some point you seriously impact system performance, and that in itself will make people notice.

Off the top of my head, the simplest way to detect it takes advantage of the fact that emulating ring 0 operations involve a context switch and some execution. Context switches tend to be rather expensive operations compared to most everything else the CPU does. The CPU has something called a timestamp counter, which basically counts every clock cycle, always incrememting, no matter what process/thread is running. An instructions should take a deterministic number of clock cycles. So just check the timestamp counter, perform a priveleged instruction, then check the timestamp counter again. If it looks like it took too long, that means you are running under a virtual machine.

Of course detection doesn't help with removal, but it's a start.

Re:i was under the impression

[tbigby]

that virtualising i386 was hard and carried quite some overhead.

Not in the slightest. When you emulate a different architecture, sure, that takes a significant overhead having to translate the machine instructions. But virtualisation runs the existing machine instructions more directly on the hardware, which can run at near-native speeds.

Some of the latest hardware from Intel (the Vanderpool technology : http://en.wikipedia.org/wiki/Vanderpool) is even able to do virtualisation at the hardware level directly.

We are looking very seriously at replacing several servers with this virtualisation technology using VMWare ESX and VMotion. It should prove to save on hardware costs and running costs in terms of power and air conditioning, not to mention the flexibility you have! I'm sure other folks who have used this technology will be able to tell more about that.

Also, you can check out the Wikipedia comparison of virtual machine technology (http://en.wikipedia.org/wiki/Comparison_of_virtua l_machines) - it is amazing how many of those technologies run guest OSs at native or near native speeds!

Re:Not hard to detect

[LLuthor]

Some functions cant be passed through, they need to be emulated, even on the same architecture, redirecting memory, storage and I/O requests, interrupt handlers and such. All these things suck performance, and in the case of games, where LOTS of memory and low-level calls to the graphics hardware are being made, performance sucks BADLY.

Any gamer will notice a loss of 15 FPS or more in their favourite game. Developers will notice it too, when their profilers output does not match their codes timing.

You can't play with the time, even if you are in a VM. People will notice this - even if the software wont.

Automated BIOS flashing considered harmful.

[Anonymous Coward]

My roommate runs a PC repair biz. I've noticed those dual-BIOS mobos. Always felt weird to me. If they want to make sure you have a good BIOS at all times, isn't it cheaper to install ONE bios socket, and send you two chips? Then you'll only swap if you really need to. And the "clean" chip is guaranteed clean because it can't be tampered with when it's not in the computer.

In any event, programs being able to flash your BIOS without telling you about it is A Very Bad Thing(TM). Disabling BIOS writes except when booted from a floppy would be a start. But at a very bare *minimum*, when the BIOS is modified by anyone or anything, the next time you boot the machine, the BIOS boot routine should throw a warning up on the screen:

"Your BIOS has been modified since last reboot. If you have not intentionally changed your BIOS, or added new hardware, you should discard these changes. Discard changes? (Y/n)"

And the code that performs this check, and throws up the error message, should be in a ROM or OTP chip where software can't tamper with it.

Re:Nice FUD

[ozmanjusri]

the worst part is 90% of the people who read this site will believe it.

No, the worst part is that they're right and we have a strong possibility of losing the freedom to use our own property in the ways we wish to. This research is a direct response to this TPM (formerly Palladium) initiative, and is intended to force TPM into future hardware;

Our first delivery on the vision is a hardware based security feature in Longhorn called Secure Startup. Secure Startup utilizes a Trusted Platform Module (TPM 1.2) to improve PC security http://www.microsoft.com/resources/ngscb/default.m spx

There is a lot of potential value in something like TPM, but since some of the earliest applications (although abandoned in Vista) included remote attestation of installed software, the most likely purpose would be to force computer users into a rental model for software use.

Stephen R. Donaldson of all people.

[frogstar_robot]

Stephen R. Donaldson wrote the "Gap Series". At one part of the story, the "Data First" of a pirate vessel put a virus in the firmware of one of the pieces of hardware controlling the ship. Even if the ship's computer was reloaded from known good stores, the virus would re-infect the computer. The virus was rigged to totally wipe the ship's computers if a password wasn't entered at specified intervals. Since you couldn't navigate or operate equipment without the computers, this was effective extortion. Billions of miles from home, there was simply no getting back without functional computers.

The cure was to install known good hardware (itself tricky considering the circumstances) and to reload the ship's computer. The story also featured a kind of WORM device called a "datacore" that every ship had to carry by law. It was a combination flight-recorder and criminal evidence accumulator. Come to think of it, many IT issues were dealt with pretty well in this series. It's worth checking out. The IT issues are essential in certain parts of the story but they aren't the main point.

Re:Why is microsoft researching this?

[martyros]

You only think that because you only know the "big bad" part of Microsoft. A pure research lab is a luxury generally only affordable by a monopoly, and Microsoft is one of the few ones of those around. They've been hiring academics for Microsoft Research for years now, and they have "lablets" near universities around the world.

As to why this research is done, there are two reasons. The "official" justification is that if it's possible, eventually somebody will do it, and it's a lot better if the "good guys" (yes, in this case that includes Microsoft) figures it out first and has a way to deal with it, than if some black hat figures it out and we discover 5 years down the road when everyone's computers are 0wn3d already and we're all caught with our pants down, so to speak.

The other reason was, it's just cool. I know the guy who did this work, and he's a brilliant "hack the system together and make it work" kind of guy. He had this crazy idea for an undetectable virus, and wanted to try it out just to see if it could be done. So he went to Microsoft for a summer internship, and got the prototype working with VirtualPC and a little internal help in 6 weeks or so, and spent the rest of the time analyzing defenses against it. Quite a productive summer for him.

It actually took some doing for this paper to see the light of day, as the higher-level managers had the same reactions you guys do. They could see the headlines: "Microsoft research inevents un-detectable virus", and thought, "Great, that's just what we need..."