from the dept. 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."

Everything I know about rootkits tells me that you cannot detect one from within the running system, you have to be objective (I consider the current fingerprint detection to be working because of bugs in the rootkit implimentation, these will be "fixed" over time).

If theres anything sophisticated enough to bypass this level of paranoia then it can damn well have my credit card number and I'll gladly send spam for them.

[ Reply to This ] Re:I say we take off... by Rekolitus (Score:3) Friday March 10, @09:10PM (Score:4, Interesting) by LiquidCoooled (634315) on Friday March 10, @09:20PM (#14896075 ) 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.

For the totally paranoid, take the suspect drive out and put it into a cleanroom machine. [ Reply to This Parent ] Re:I say we take off... by xWastedMindx (Score:1) Friday March 10, @11:03PM Re:I say we take off... by LiquidCoooled (Score:1) Saturday March 11, @03:56AM Re:I say we take off... by Beardo the Bearded (Score:3) Friday March 10, @09:16PM Re:I say we take off... by Sigma 7 (Score:2) Friday March 10, @09:22PM Automated BIOS flashing considered harmful. by Anonymous Coward (Score:3) Friday March 10, @10:27PM Re:Automated BIOS flashing considered harmful. by Tyger (Score:3) Friday March 10, @11:06PM Re:Automated BIOS flashing considered harmful. by Tolookah (Score:1) Friday March 10, @11:19PM Re:Automated BIOS flashing considered harmful. by Columcille (Score:1) Saturday March 11, @02:08AM Re:Automated BIOS flashing considered harmful. by lintux (Score:2) Saturday March 11, @03:08AM Re:I say we take off... by vux984 (Score:3) Saturday March 11, @02:25AM (Score:5, Funny) by Dunbal (464142) on Friday March 10, @09:34PM (#14896128 ) Oh fuck me - the next step is a VM rootkit that flashes the bios to keep a VM rootkit.

Just remind me when was Skynet supposed to become sentient again? [ Reply to This Parent ] The Matrix... by chiao (Score:1) Friday March 10, @11:00PM Re:I say we take off... by Courageous (Score:2) Friday March 10, @10:00PM Re:I say we take off... by RyuuzakiTetsuya (Score:2) Friday March 10, @10:37PM Re:I say we take off... by wormeyman (Score:2) Friday March 10, @09:25PM Re:I say we take off... by ElBorba (Score:1) Saturday March 11, @01:10AM Re:I say we take off... by Bacon Bits (Score:3) Friday March 10, @09:58PM (Score:5, Insightful) by this great guy (922511) on Friday March 10, @10:06PM (#14896242 ) . See this rootkit concept overwriting your BIOS [ngssoftware.com] to create a permanent backdoor.

Note: removing the CMOS battery will not destroy this rootkit because the CMOS battery erases the NVRAM, not the BIOS flash chip. The only known way to recover from a BIOS rootkit is to reflash your BIOS... but what if the rootkit is intelligent and tries to re-corrupt the new image being flashed ? This is a possibility. In this case your only option is to physically change the flash chip with a known good one. And don't forget that a modern computer has a lot of flash chips that can theoretically be infected: hard disk firmware, video card BIOS, DVD drive firmware, etc.

[ Reply to This ] Re:Why is microsoft researching this? by TheWanderingHermit (Score:3) Friday March 10, @09:12PM Re:Why is microsoft researching this? by Spy der Mann (Score:3) Friday March 10, @10:22PM (Score:5, Insightful) by arrrrg (902404) on Friday March 10, @11:35PM (#14896522 ) Pure research like this and MS just do not go together.

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.

i'd imagine the vm would have quite different performance patterns for some operations than the real machine. it would also pretty much by definition have to have slightly less ram. [ Reply to This ] Re:i was under the impression by jsight (Score:2) Friday March 10, @09:15PM (Score:4, Interesting) by tbigby (902188) on Friday March 10, @09:20PM (#14896073 ) that virtualising i386 was hard and carried quite some overhead.

Not in the slightest. When you 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 [wikipedia.org]) 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.

(http://www.preinheimer.com/ Last Journal: Friday August 22, @10:32AM ) 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. [ Reply to This ] Re:ROM Boot Keys by imemyself (Score:2) Friday March 10, @10:35PM license chip by ScottCooperDotNet (Score:2) Saturday March 11, @01:13AM (Score:4, Interesting) by Anonymous Coward on Friday March 10, @09:09PM (#14896026 ) You can only be secure if your run hardware with treacherous computing modules installed on the motherboard and in the "approved" CPUs and BIOS chips, and that only works with treacherous computing software, sort of expensive hand in designer glove..

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? [ Reply to This ] Re:Link to research paper by ptelligence (Score:1) Friday March 10, @09:18PM Re:Link to research paper by tepples (Score:1) Friday March 10, @09:36PM Re:Link to research paper by Omaze (Score:2) Friday March 10, @11:01PM Re:Link to research paper by NormalVisual (Score:2) Friday March 10, @11:37PM Re:Link to research paper by saikatguha266 (Score:2) Friday March 10, @10:09PM Re:Link to research paper by ptelligence (Score:1) Friday March 10, @10:42PM Re:Link to research paper by BitwizeGHC (Score:2) Friday March 10, @09:18PM (Score:5, Interesting) by Jon Luckey (7563) on Friday March 10, @09:25PM (#14896093 ) 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.

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. [ Reply to This Parent ] Re:Link to research paper by NormalVisual (Score:2) Friday March 10, @11:57PM Re:Link to research paper by Tyger (Score:2) Saturday March 11, @12:05AM (Score:5, Insightful) by radtea (464814) on Friday March 10, @10:04PM (#14896238 ) Can you think of a way to win against rootkits without TCPA?

What is needed to defeat rootkits is to allow the user to trust the hardware. This is totally different from application vendors trusting the hardware.

Here's an extreme example: hook a logic analyzer up to the BIOS. Look at the nice bits go by. See if they match expectations. If not, you've been rooted and had your BIOS flashed. "Expectations" are stored in a separate device.

The issue here is strictly one of treating a computer as a fully self-contained block of hardware and software that no one is allowed or able to look inside without going through the terribly civilized interfaces. The solution is to say, "Fuck the fucking interfaces, I'm going to fucking look at what is on the fucking bus." Not civilized at all.

I've debugged embedded code this way, by hooking a logic analyzer up to the hardware and watching the bits go by. It's educational. It would be simple to build this kind of exposure of hardware internals in to the motherboard, to make it easy to plug in an external integrity checker to ensure that the basic state of the machine is as expected.

"Trusted" computing is all about hiding the hardware state from the user. Beating VM-based rootkits is all about exposing hardware state to the user. The two are diametrically opposed.

(http://www.arstechnica.com/etc/linux/index.html ) 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.

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. /me sips his Rye and cola....

(http://slashdot.org/~nurb432/ Last Journal: Friday August 27, @03:24PM ) On a normal machine, if you try to virtualize it you would notice right away that something was wrong as it would slow quite a bit.

[ Reply to This ] (Score:2, Insightful) by Roskolnikov (68772) on Friday March 10, @09:18PM (#14896071 ) My experience with Windows and VM scenarios is that it runs better in VM then in real life; mom and pop might not notice this but I should hope those that are savvy enough to understand what Microsoft is proposing as a 'threat' would also be savvy enough to notice the little things that make VM still a pain.

[ Reply to This ] Re:Virtually. by woolio (Score:2) Friday March 10, @09:30PM Re:Virtually. by sqlrob (Score:2) Friday March 10, @10:48PM (Score:2, Redundant) by LLuthor (909583) on Friday March 10, @09:19PM (#14896072 ) For someone like me, who games on his PC a lot as well as working, it would be immediately obvious that there is something wrong.

No virtual machine can work as fast as the host system or with as much RAM. [ Reply to This ] Re:Not hard to detect by Helios1182 (Score:2) Friday March 10, @09:54PM (Score:5, Interesting) by LLuthor (909583) on Friday March 10, @10:03PM (#14896234 ) 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.

(http://www.rocketcat.info/ ) Why on earth is someone writing this software for the purposes of malware - why aren't they gainfully employed earning decent money.

Seriously, whipping up your own VM that will run $HOST_OS is nowhere near in the same league as, say, hacking together a VBS macro in MS Word or similar... [ Reply to This ] Re:Holy Crap! by AvitarX (Score:1) Friday March 10, @10:08PM Re:Holy Crap! by typical (Score:2) Saturday March 11, @03:00AM (Score:2, Insightful) by aachrisg (899192) on Friday March 10, @09:38PM (#14896139 ) 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. [ Reply to This ] Re:The solution by poopdeville (Score:1) Friday March 10, @10:01PM (Score:3, Interesting) by Jon Luckey (7563) on Friday March 10, @09:41PM (#14896148 ) 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.

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.

(http://www.valerieandevi.be/ ) How do you install the rootkit? Yes, you guessed it, through an insecure operating system. This article is imho just another promotion FUD campaign for TCPA.

If your current operating system and security measures are good enough, such rootkits-with-virtual-machines are not even going to be able to be installed, heck as long as you don't have to login as administrator to print out a document or surf the web, you're pretty safe.

(http://www.chriscanfield.net/ ) I definitely agree that security minded individuals should find ways of attacking systems in order to find defences against them. Nearly all software holes are found this way, and are patched within weeks of discovery.

But this seems excessive. We're just starting to hear about real Windows based rootkits in the wild, and a front page Slashdot article gives everyone and their mother an exploit route that is both nasty, nearly impossible to protect against, and hasn't been seen in the wild.

--This post intentionally left inflamatory. Please let me know where I'm wrong. [ Reply to This ] Re:Please Stop by _Sprocket_ (Score:2) Saturday March 11, @12:12AM Re:Please Stop by stinky wizzleteats (Score:2) Saturday March 11, @12:25AM (Score:2, Funny) by sql_noob (855995) on Friday March 10, @09:59PM (#14896219 ) Microsoft start to SUPPORT linux? And start off with a rootkit prototype?

(http://www.geocities.com/orion_blastar/contact/ Last Journal: Monday August 29, @07:55PM ) 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. [ Reply to This ] Re:VM Machine Rootkits by Tyger (Score:2) Friday March 10, @11:04PM Re:VM Machine Rootkits by jofi (Score:1) Friday March 10, @11:11PM Re:VM Machine Rootkits by Tyger (Score:2) Friday March 10, @11:36PM Re:VM Machine Rootkits by rcpitt (Score:2) Saturday March 11, @12:32AM Re:VM Machine Rootkits by Antony T Curtis (Score:1) Saturday March 11, @02:20AM (Score:3, Interesting) by Anne Honime (828246) on Friday March 10, @10:25PM (#14896305 ) 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. [ Reply to This ] Re:Secure installation by b0s0z0ku (Score:2) Saturday March 11, @03:40AM (Score:3, Informative) by mombodog (920359) on Friday March 10, @10:29PM (#14896313 ) 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 [trapkit.de] [ Reply to This ] (Score:2, Interesting) by mindstrm (20013) on Friday March 10, @10:36PM (#14896326 ) 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.

They (MS) are probably just looking for more selling points for their new BIG baby. [ Reply to This ] (Score:1) by droopycom (470921) on Friday March 10, @10:44PM (#14896356 ) .. or Palladium or Trusted Secure Computing Platform or whatever it is called this day.

The only way to defeat an advanced rootkit today is to require strong crypto all the way down in the hardware. This means pratically everything down to the BIOS should be signed. There should be a chain of trust, and untrusted software should not be able to do permanent damage. The updates to the permanent storage should also be signed.

(http://www.wanfear.com/~mbrito ) The First Operating System booted must issue an instruction to the processor to create one of these "VM"'s. All you do is control this instruction.

[ Reply to This ] (Score:2) by Jerry (6400) on Friday March 10, @11:57PM (#14896611 ) Linux installs. [ Reply to This ] Re:Which will be used by MS to block by sl4shd0rk (Score:2) Saturday March 11, @12:06AM (Score:1) by NynexNinja (379583) on Saturday March 11, @12:04AM (#14896639 ) Come on lets be real here. The only reason Microsoft is paying its developers to write VM-based rootkits is because they intent to deploy these exploits against their competition, foes, etc. I think its a load of bullshit that this is done as "proof-of-concept". [ Reply to This ] Re:microsoft "research" by Forbman (Score:2) Saturday March 11, @12:27AM Re:microsoft "research" by pembo13 (Score:1) Saturday March 11, @01:26AM (Score:1) by A Numinous Cohort (872515) on Saturday March 11, @12:14AM (#14896671 ) the iSeries (aka AS/400) OS runs on top of a layer of microcode in which security functions are implemented, so they are immune from this type of malware [ Reply to This ] (Score:1) by jrmiller84 (927224) on Saturday March 11, @12:20AM (#14896686 ) Everyday I read something new that further justifies me switching to Linux. I haven't made the switch yet and it almost scares me to think I haven't after reading things like this. Anyone know where to find some good resources for making a first time switch? Perhaps some better reading will push me over the edge and there's no better place to ask that Slashdot. [ Reply to This ] Re:With each passing day... by jofi (Score:1) Saturday March 11, @12:32AM Re:With each passing day... by jrmiller84 (Score:1) Saturday March 11, @12:46AM Re:With each passing day... by jofi (Score:1) Saturday March 11, @01:00AM (Score:2) by Kaenneth (82978) on Saturday March 11, @01:06AM (#14896805 ) I recall there was a proof of concept modification of GCC that would add itself to any GCC complied with it, a Compiler Virus...

(Last Journal: Friday February 10, @02:51PM ) So if I write a program that keeps any other program from writing to the boot sector without confirmation, does this keep this in check?

This is cache, read story here