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."
Can anyone say dual boot?
And another question: I can understand the risk that this may pose for enterprise servers (Virtual Server systems, just to name one), but does this hold any implications for client VMs?
Viable Slashdot alternatives: https://pipedot.org/ and http://soylentnews.org/
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.
paul reinheimer
Virtual-machine monitors are available from both the open-source community and commercial vendors.
grrrr this is what pisses me off about microsoft. They listed the open source community based software first in order to put a bigger emphasis on it. Like they're saying open source people are going to be the most likely to write these hackjobs programs to send spam, porn dial and install maleware on computers. Why stand for this when the whole article comes down to a fud statement? This is the kind of thing Microsoft is famous for and still we're reporting on it and saying things like "threat" and "open source" and "infected" in the same paragraph. It's playing right into their game.
And I don't like the way that smells.
Here is a link to the actual paper the article references:d f
http://www.eecs.umich.edu/virtual/papers/king06.p
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?
that virtualising i386 was hard and carried quite some overhead.
a l_machines) - it is amazing how many of those technologies run guest OSs at native or near native speeds!
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_virtu
There's two ways around that.
- Flash the Bios chip. Pull the existing one out, put it in a programming unit, flash the chip, and push it into the Mainboard.
- Use a mainboard that supports a "dual-bios" option (e.g. Some Gigabyte models).
No virus has can penetrate further without physically damaging the hardware (and that would be difficult with the most modern computers.)
A few days ago, I saw VB6 jump instructions being sent to the wrong destinations, both in runtime and IDE. The malkit survived an XXClone backup so it was hiding in a file. I now have it isolated awaiting the gendarmes.
TFA seems to propose a model where the host OS is running a Root kit that runs a VM that runs a copy of the host OS that the user works within, which hides the root kit.
But in that model, the host OS is still running.
It mighr be possible to detect a rootkit by putting a honeypot of some sort in the true kernel. The when the root kit tried to do something, like say change the firewall, the true kernel could detect that and quarentine itself.
Of course a root kit running with ring-zero permissions would try to lobotomize that code, so the honeypot itself can't be too easy to find and alter. You'd probably need other kernel level tripwire type code to look for lobotomization.
Maybe a card with boot time code that the OS could call to verify itself. Not pure trusted computing as any user could add such a card (assuming a free slot)
-- 3 events that reshaped the world in the 20th century: WW1, WW2, and WWW
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.
LL
Not in the slightest.
Uhh, actually, the original poster was right. The x86 is actually quite difficult to virtualize effectively. This is because the x86 CPU has certain classes of instructions that make is exceedingly difficult to virtualize effectively, as the x86 doesn't allow you to trap and emulate them correctly. In fact, I would contend that simulating an x86 CPU is probably as easy, or perhaps easier, technically speaking, than actually virtualizing the x86. After all, while emulators like bochs exist, there still does not exist a true, effective open source x86 virtualizer (AFAIK, plex86 is dead). And, no, Xen doesn't count. In order to get around these limitations in the x86 processor, Xen actually requires the OS to be modified such that it doesn't execute these difficult-to-virtualize instructions.
Now, granted, all this will change with new x86_64 processors, but for a rootkit like this to be really interesting, you probably want to install it on as many machines as possible, meaning you'd have to build for the lowest common denominator.
Incidentally, I should point out that, as hard as it is, virtualization of the x86 is, as you say, much faster, performance wise, than emulation. However, that doesn't make the task any less difficult.
So basically what it is, is a rootkit designed to run in a virtual machine (like VMWare, VirtualPC, Bochs, QEMU, etc) that takes root control of the virtual machine, but the host OS is unable to detect the malware because it runs under a virtual machine and not on the host OS itself.
Microsoft had tested code under VMWARE for Linux, and VirtualPC for Windows that allowed them to gain root access to the host OS from the virtual machine, and run the rootkit malware under the virtual machine.
Yet what they are not telling you, is that the virtual machine has to run on the host OS, and that can be detected, even if the malware cannot. If you are really paranoid, just don't run a VMWARE or Virtual PC virtual machine or any other virtual machine, and if you find one on your OS, remove it. The problem with that is that malware scanners will be looking for virtual machine files and suspect them of being malware and warn the user. Besides any virtual machine has to be installed on Linux with root access anyway, and VMWARE Server apparently when I installed it on my Linux box had to compile a part of itself to match my kernel, and asked me to download a few libraries before it would continue. I doubt someone can use VMWARE to install as a regular user on Linux without someone with root access allowing it. Still, Xen is a virtual machine and is becoming popular with Linux, I wonder if it is vulnerable as well?
The whole VM rootkit fails, unless the malware author finds a way to install a VM on a host OS without being detected, and without Root or Administrator access. The only way I can see that happening on Linux and Unix systems is if they use a trojan horse method of making it part of a program the user or administrator wants to install and they use root or administrator access to install it. On Windows it would just use an exploit to get Administrator access.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
I've done it with linux, I suppose it's possible to achieve with windows : have a two disk install, and make sure that there is a read only strap on one. Just put whatever binaries you have (/boot, /, /usr...) on that disk, then move the strap to ro ; on the other disk, put /var and /home. If you're paranoid about it, have syslogd hard print everything on an old line printer. Done. It doesn't prevent a break-in, but the attacker is stuck an can't damage the files, so when you reboot (because you notice the security log printing strange things) the evidences are easy to find.
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.
That's actually interesting.
One would think you could detect the change in system hardware in some way.. it's unlikely that the VMM implementation is 100% identlcal when compared to the pre-VMM rootkit system. Something has to be differnet, somewhere.
First one to publish a detector for this gets good press.
But then again, maybe not. I'll play my own "devil's advocate" for a bit here to contradict my previous comments. A full blown VM, probably detectable. But what about something like a changeroot (essentially, for non-'nix users, a subdirectory which for all intents and purposes appears as the drive root).
We have boxes at work which run chrooted... and the SSH server also runs in the changeroot. When you SSH in, you can't tell whether or not you're in the chroot except that we tend to have it labelled. If you were to apply the same trick to the console, but have the overlying layer outside of the changeroot, and some masks to hide various processes, how would you know if you're "in the box" or outside of it?
was just a VM rootkit for human brains, no?
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;
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."I've got more toys than Teruhisa Kitahara."
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.
It's really a moot point for the reasons you point out about getting the user to reboot...
But I don't see why it shouldn't be possible to demote a host OS running on the hardware into a guest OS running in a VM in a live system. It would probably be more trouble than it's worth considering the ease of the alternatives, but theoretically all the VM has to do is get ring 0 priveleges (Easy to do if you have root/administrator level access) then hijack the thread of execution away from the OS. Then it just has to initialize the virtual machine and start it executing right where it left off. Since it doesn't have to mess with any hardware but the CPU, the state of everything else is left unmolested and doesn't realize anything changed.
That might be an interesting challenge, actually... Write something to take over ring 0 then let the OS resume as a demoted guest.
Anyone immediately think of "Jane" from Ender's Game?
The concept doesn't seem too different, especially when the technology is available. All you need now is an intelligent AI that will install rootkits and move around the Internet looking up, using, and modifying information as it wants in order to become better at survival.
Sounds errilly similiar to a crawler, enhanced and autonomous. Where's Google on this?
I recall there was a proof of concept modification of GCC that would add itself to any GCC complied with it, a Compiler Virus...
How about a program that specifically attacks chip design software, and adds malware to any chips that are layed out for production. With the millions of transistors on a modern chip, who would notice a few more? and who would know that multiplying 563473563 by 756481984 turns off all memory access interupts, allowing the following instructions to read/write anything they want?
You can usually tell by running the cache prefech algorithm at http://www.x86.org/secrets/prefetchqueue.htm. If modified to use some privliged instruction, reinterpreters will either (1) crash, (2) give a prefix size of 1, (3) give a rediculous size, or (4) run way too slow as it has to recompile the code because it is self-modifying in the inner loop.
I think it would be a lot more sensible to have a physical switch or jumper that would have to be set to enable bios flashing. 100% gaurantee that it can't be circumvented with software, and equally sure to be immune from socially engineering the less literate... "When you see the WARNING DANGER DANGER YOU ARE ABOUT TO PERMANTLY CHANGE YOUR HARDWARE WINDOW... just click 'continue anyways'." Don't worry about why, trust us...
Failing that a setting in the bios itself that determines whether or not its flashable. I've seen a lot of bioses with that, and I like the feature; the default is no, you have to boot into bios to change the setting, and the flashing process resets the setting back to no.
I'm not sure how strictly secure it is, but assuming that setting can't simply be ignored by a custom flashing utility it seems pretty good.
Aside from your point, I thought the Gap series was amazing for how little it focused on the tech side of the story.
The stories are built almost entirely around human interactions. It's just people in rooms, but it is fascinating. Someone here said "perverted", yes, very.
It's been a while since I read them, but I think the entire series takes place in a really short period of time, like a day or so.
Researcher 1: How's the experiment going? ... ... er it... can't tell what the machines are up to. ...
Researcher 2: Welll look at this post it made on slashdot.
R1: slashdot?
R2: It's some kind of primitive attempt at a HiveMind.
R1: But you said it was human.
R2: Yes.
R1: But humans never had a HiveMind. That's why peaceful coexistance with them was impossible. That's what I learnt at the temple.
R2: No, but they had something called the Internet and Websites. They were a very simple invention that allowed you to see posts from all over the world, but only from people who completely shared your prejudices. But I was joking, it's nothing at all like the HiveMind. Far inferior obviously.
R1: Wait, but in the post how does it know about our computer. I thought it only knew about stuff in the simulation.
R2: No _it's_ computer. In the simulation.
R1: So it's worried that the simulated computer might be misleading it somehow?
R2: Of course, look at what it wrote about "CDs and Bioses". It thinks it can trust them because they can only be written once.
R2: The simulation is running in the early 21st century. It drives to work in automobile, powered by gasoline bought from other humans the Middle East, where he actually tells machines what to do.
R1: Wow, and he
R2: No, it just thinks they are unreliable, and other humans are interfering with them. Just like real, living humans did at that time. Even stranger, they think the vast amount of communications from the embryonic HiveMind is due to things called 'spam' and 'p2p' sent by other humans. He thinks Bill Gates is a human trying to make money, too. They all do.
R1: In some ways, it's a shame we don't have any real humans to check the simulation against. It's hard to believe none of them guessed what was really happening.
R2:
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Why is microsoft researching this kind of thing?
;-)
Let's put it this way... Vista won't support booting from EFI based machines until they can figure out how to do the same thing there too.
--Phillip
Can you say BIRTH TAX
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..."
TCP: Why the Internet is full of SYN.