×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Microsoft Research Warn About VM-Based Rootkits

Zonk posted more than 8 years ago | from the why-would-you-prove-that-concept? dept.

336

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

336 comments

I say we take off... (5, Funny)

LiquidCoooled (634315) | more than 8 years ago | (#14895974)

...and nuke the entire site from orbit.
It's the only way to be sure.

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

Keep a known secure boot CD.

Drain the battery and reset the bios then boot from that cd.
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.

Re:I say we take off... (3, Informative)

Rekolitus (899752) | more than 8 years ago | (#14896031)

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

Re:I say we take off... (5, Informative)

LiquidCoooled (634315) | more than 8 years ago | (#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.
Complete and utter safety in case of a bad flash.
Heres a small THG article [tomshardware.com] 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.

Re:I say we take off... (3, Insightful)

Beardo the Bearded (321478) | more than 8 years ago | (#14896056)

You don't have to drain the battery - you can disconnect it.

Your virtual machine could flash your BIOS without your consent. Then you're boned. A bootstrap doesn't require a lot of space.

Oh fuck me - the next step is a VM rootkit that flashes the bios to keep a VM rootkit.

Re:I say we take off... (2, Interesting)

Sigma 7 (266129) | more than 8 years ago | (#14896082)

Your virtual machine could flash your BIOS without your consent. Then you're boned.


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

Automated BIOS flashing considered harmful. (5, Interesting)

Anonymous Coward | more than 8 years ago | (#14896308)

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:I say we take off... (5, Funny)

Dunbal (464142) | more than 8 years ago | (#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?

Re:I say we take off... (2, Insightful)

Courageous (228506) | more than 8 years ago | (#14896223)

Oh fuck me - the next step is a VM rootkit that flashes the bios to keep a VM rootkit.

Flashes your bios, writes your boot blocks, patches your microcode, wash, rinse, repeat, all that's left to do is nuke it from orbit, as the other guy said....

C//

Re:I say we take off... (1)

RyuuzakiTetsuya (195424) | more than 8 years ago | (#14896331)

There's always investing in a ROM burner and keeping a fresh copy of your BIOS ROM handy in case that becomes a problem.

Of course, if this super VM based virus takes over the firmware on your optical drive too...

Re:I say we take off... (4, Informative)

Bacon Bits (926911) | more than 8 years ago | (#14896215)

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.
The payload for the Chernobyl virus [wikipedia.org] wrote zeros to sector 0 of your hard drive (which generally contians partition table information) and also tried to write garbage to any present Flash BIOS. You had to have a manual EEPROM reprogram to recover a so damaged BIOS.

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.

This will blow you off your chair (4, Insightful)

this great guy (922511) | more than 8 years ago | (#14896242)

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

This may very well astonish you, but such sophisticated infection mechanisms already exist and have already been demonstrated. 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.

Why is microsoft researching this? (3, Insightful)

Saven Marek (739395) | more than 8 years ago | (#14895990)

Why is microsoft researching this kind of thing? And with Linux too? It makes me wonder if the next time you go to install Windows on a partition somewhere with the same machine as you also dual boot into Linux whether your linux boot will not then be "taken over" by Windows, and MS can insert any little hooks, DRM, inspection code or other things running underneath the linux system you have.

Then they can force linux to perform worse than Windows and nobody will be none the wiser.

Except when you boot into linux and then you get a blue screen it will give it away lol.

Re:Why is microsoft researching this? (5, Insightful)

TheWanderingHermit (513872) | more than 8 years ago | (#14896038)

That was my first thought: why is MS researching this? Pure research like this and MS just do not go together.

Honestly, this sounds like the kind of thing they'll think of so they can use it as a reason that all computers should have DRM build into the chipset, which plays right into MS being able to justify why all systems should follow their boot rules that allow only Vista to run. It's just laying the groundwork to force the exclusion of anything but Vista being able to be booted on future systems.

This is also the kind of thing that I don't think many black hats would have come up with on their own due to the amount of research. MS continaully says it is irresponsible for people to publish info on exploits in Winodws before they can patch them, yet they've just gone and published what could be one of the nastiest exploits of any OS to date. If they're doing this, it's for a reason, and experience tells us MS's reasons are good for them and bad for everyone else.

Re:Why is microsoft researching this? (0)

Anonymous Coward | more than 8 years ago | (#14896263)

What planet are you from? MS spends more on research in one year than Apple has spent in its entire existence.

Re:Why is microsoft researching this? (2, Insightful)

Spy der Mann (805235) | more than 8 years ago | (#14896297)

That was my first thought: why is MS researching this?

"Genuine Advantage for Vista" seems one possible application. So, what were we saying about the "Signs of the end times"?

Re:Why is microsoft researching this? (3, Insightful)

Anonymous Coward | more than 8 years ago | (#14896044)

They are researching it so they can scare people into thinking that Trusted Computing is required for their own protection. If the rootkit loads before the OS, that just leaves the BIOS to do your security checks, right?

Re:Why is microsoft researching this? (1)

aussie_a (778472) | more than 8 years ago | (#14896045)

I'd definitely say that yes, they do want to have that technology mastered for if they ever do decide to implement it. But I'd say in the nearer future, it's to try to create detection methods or methods to stop it getting installed in the first place. With company's like Sony and Microsoft, they're willing to do anything, if they can get away with it. So VM-based rootkits is definitely something they want to have mastered, so when they can get away with it, they are capable of doing it.

Re:Why is microsoft researching this? (1)

pimpsoftcom (877143) | more than 8 years ago | (#14896119)

Trust me, MSR has better things to do then 0wn your boxen.

Besides, you should know how to audit your init scripts and copy your boot sector to a file you can check the md5 of at boot. If you dont know how, its your fault. They may have researched it thinking of a possible attack on there product, and thus there main source of income. Any company has that right, it be Apple, Sun, or yes even Microsoft.

Re:Why is microsoft researching this? (1, Insightful)

Saven Marek (739395) | more than 8 years ago | (#14896155)

Mabey they also have better things to do than write tripe accusing the open source community of being part of these malware authors by saying things like "Virtual-machine monitors are available from both the open-source community..." specifically listing open source as part of the problem.

They might have better things to do than that, but it doesn't mean it will stop them doing it. No windows nearmy boxen thank you.

> Besides, you should know how to audit your init scripts and copy your boot sector to a file you can check the md5 of at
> boot. If you dont know how, its your fault.

Always blame the user. mabey you will have someone break into your house and then they use the excuse "You should know how to stop me getting into your house. If you don't know how its your fault". So blame the victim and let MS off scott free? That's the attitude that let them off with no monopoly punishment. Just remember not to call the police next time.

Re:Why is microsoft researching this? (2, Insightful)

0racle (667029) | more than 8 years ago | (#14896133)

Why? Because everyone knows virtualization is going to become very common place almost everywhere you have a datacenter. They also know that every time you change something you open the possibility of exploits. By knowing how exploits could be introduced into systems using virtualization they can begin to look at how to combat it. Why look at Linux as well? I seem to remember MS buying some virtualization software that supports Linux guests. They also know about VMWare on Linux hosts running Windows guests, which is a supported configuration.

Not everything is a conspiracy. In fact, very few things are.

The one thing I hate about Microsoft products... (5, Funny)

creimer (824291) | more than 8 years ago | (#14895991)

You never sure if this is a feature or a bug. Either way, they will probably charge a subbscription fee to get the feature or get rid of the bug.

Re:The one thing I hate about Microsoft products.. (1)

Tim C (15259) | more than 8 years ago | (#14896083)

Yes, just like all the other subscription fees they're charging at the moment...

Original Paper (i.e., karma whoring) (4, Informative)

perlionex (703104) | more than 8 years ago | (#14895993)

Original Paper [umich.edu]

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.

Conclusion from Paper (2, Informative)

perlionex (703104) | more than 8 years ago | (#14896014)

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!

Re:Conclusion from Paper (2, Interesting)

Saven Marek (739395) | more than 8 years ago | (#14896029)

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.

Re:Conclusion from Paper (3, Insightful)

TubeSteak (669689) | more than 8 years ago | (#14896198)

> 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,
How is that a disadvantage?

If the bastards already have enough access to be downloading and executing code on your machine, it is trivial for them to crash your box and make you reboot... assuming they can't just reboot your box out of hand.

Notice how one of their solutions is secure hardware?
I think we know why MS is funding this.

Conclusion: Secure Hardware (1)

dch24 (904899) | more than 8 years ago | (#14896284)

Just like the *AA are saying that we must have tighter and tighter Digital Restrictions Management, enforce the DMCA ever more stringently, and chase down those pirates, now Microsoft is jumping on the bandwagon. "Our systems will never be secure enough until we have full TPM hardware support. This will be released as part of Windows Vista SP2 in our effort to improve security." Yep, we've found a killer way to make an awesome virus. Is the cure worse than the disease?

Re:Original Paper (i.e., karma whoring) (0)

Anonymous Coward | more than 8 years ago | (#14896277)

I don't know a TON about this admittedly, but what if one of these VMBRs was installed, but not for a mallicious purpose, but to monitor the system for any other intruding VMBRs? Is that even possible? Would they be able to detect each other?

rootkits? (2, Interesting)

gcnaddict (841664) | more than 8 years ago | (#14895997)

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?

Re:rootkits? (1)

TheWanderingHermit (513872) | more than 8 years ago | (#14896062)

Can anyone say dual boot?

That's what I was thinking. If I didn't see my familiar grub screen come up, I'd worry.

But then I guess the idea would be to have even grub come up on the VM.

Under those conditions, couldn't one just have a program that creates a checksum of the bootblock on install and checks it regularly? Then you can do an md5 on that program from time to time to make sure it's okay.

So either there is something terribly wrong with that idea, or it's too damned simple for MS -- but maybe they don't want a simple solution. Maybe they'd prefer making everyone believe this is good cause for built in DRM chips that will allow only Windows to boot.

Re:rootkits? (2, Insightful)

Dionysus (12737) | more than 8 years ago | (#14896107)

Under those conditions, couldn't one just have a program that creates a checksum of the bootblock on install and checks it regularly? Then you can do an md5 on that program from time to time to make sure it's okay.

Where do you put the checksum? On an external hd? On the system? What's preventing the rootkit from replacing the checksum? A checksum of the checksum? If you don't allow the checksum to be replaced, how do you upgrade?

Re:rootkits? (1)

tekiegreg (674773) | more than 8 years ago | (#14896184)

For the truly paranoid, you could create the checksum and burn to CD. Every time you alter your boot, you'd have to burn a new CD but it might work. However the malware in question could in theory intercept the CD and attempt to burn a new checksum. I suppose then you could attempt to store it online someplace safe as well...dunno, the game of cat and mouse between virus writers and anti-virus writers continues yet again...

Re:rootkits? (1)

TheWanderingHermit (513872) | more than 8 years ago | (#14896201)

You could pick your own filename. Yes, there's a lot of people who would only want an automated checker and would end up as victims, but for those that are interested in their own security, there are a lot of simple steps. The checksum could be on a floppy, or a boot block could be stored on a CD, with the checksum checking program(s) on it.

The rootkit can't replace the checksum if it doesn't know what filename to look for. It wouldn't be hard to create a program, that, when installed, can be given different names and could somehow morph so it doesn't always look the same.

I also forgot to mention a program like this could check the BIOS checksum as well.

Re:rootkits? (0)

Anonymous Coward | more than 8 years ago | (#14896110)

couldn't one just have a program that creates a checksum of the bootblock on install

Sure, and when the rootkit installs itself it will just make sure that the drive the virtual machine sees looks exactly like the drive before it was installed.

Re:rootkits? (1)

TheWanderingHermit (513872) | more than 8 years ago | (#14896218)

It can't do that but so much, due to storage limitations.

It can't hide all files, that would be a clue that something is wrong. There are also way too many files on the drive that have to change regularly so making a drive always look the same would be a problem. As I mentioned in another post, the check program could be designed so when it is installed, it could have a different name on each system and could morph so it wouldn't be easily recognized from system to system.

There's also the live CD option. When the OS is installed, it burns a simple live CD that would have ways of verifying that when it boots, it is itself (it wouldn't change at all and a rootkit can't memorize every CD ever inserted) and can do checksums on the BIOS and boot block. Both of these are updated rarely enough there isn't a frequent need to make new CDs.

I'm just pointing out a simple solution. By responding to your concern, I'm also pointing out that there are ways around some of the issues. I'm not trying to lay out an entire process here. You and I both know that there's the constant "one upmanship" that is part of the security game, and there are many factors that need to be taken into account. I'm not trying to take them all into account, but just point out that while MS makes this sound like a dire threat, there are much easier solutions to it than some major DRM thing.

Of Course (2, Insightful)

Alien54 (180860) | more than 8 years ago | (#14895998)

while I can appreciate the logic of the research, I imagine this only gives creedance to the theories that companies deliberately design viruses so that they can sell more of their latest security product. or system/OS upgrade

Re:Of Course (1)

aussie_a (778472) | more than 8 years ago | (#14896058)

I don't think that's the case here. I think they're investigating this under the guise of looking for future virus methods so that they can in truth investigate it so they can implement it in a future Windows version/upgrade.

selling Trusted Computing / TPM (1)

SuperBanana (662181) | more than 8 years ago | (#14896145)

while I can appreciate the logic of the research, I imagine this only gives creedance to the theories that companies deliberately design viruses so that they can sell more of their latest security product. or system/OS upgrade

You mean like those trying to sell TPM / Trusted Computing?

Seems like a solution (TPM/TC) in search of a problem consumers/end-users can identify with ("VIRUSES VIRUSES VIRUSES!"), because "protecting our intellectual property" wasn't really ringing with end-users.

It's still an interesting idea, and good to start thinking about how to defeat it...but I suspect this is a back-handed way of selling TPM crap.

Re:selling Trusted Computing / TPM (1)

Alien54 (180860) | more than 8 years ago | (#14896211)

because "protecting our intellectual property" wasn't really ringing with end-users.

yeh, most consumers have this crazy idea that they own something just because they paid money for something.

i was under the impression (2, Insightful)

petermgreen (876956) | more than 8 years ago | (#14896000)

that virtualising i386 was hard and carried quite some overhead.

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.

Re:i was under the impression (1)

jsight (8987) | more than 8 years ago | (#14896050)

In the past that was mostly true. It's going to become a lot less true with the next generation of x86_64 CPUs, though.

Re:i was under the impression (4, Interesting)

tbigby (902188) | more than 8 years ago | (#14896073)

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

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

Re:i was under the impression (2, Interesting)

Abcd1234 (188840) | more than 8 years ago | (#14896294)

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.

Re:i was under the impression (1)

dknj (441802) | more than 8 years ago | (#14896092)

spin it around. if you boot into a virtualising os, how do you know you are virtualized. sounds like a matrix plot, but its plausable. i think we have some time before we have to worry about similar exploits, but lets not forget that a simple fix is to network boot a virus scanner, scan for a virtualizing rootkit and remove it. this is moreso a problem for the many ma and pa computers out there directly connected to the internet.

Re:i was under the impression (2, Insightful)

diablomonic (754193) | more than 8 years ago | (#14896176)

how will a networked virus scanner help? its still getting the system info from the OS on the compromised system, and the OS on the compromised system does not know its compromised because the VM is UNDERNEATH it, and therefore tries to act for all intents and purposes as if it's not there!!!.

With a perfect bug free VM, neglecting slight performance differences that may or may not be detectable, you pretty much have to scan the compromised hard drive by pluggin it into another pc (as unbootable of course) running a clean os to detect it (or at least thats my understanding which could be wrong :) )

Re:i was under the impression (1)

diablomonic (754193) | more than 8 years ago | (#14896186)

hey I just had an idea, what if you deliberately virtualised your machine in a hidden manner, so a vm rootkit trying to virtualise your os would actually be virtualising between the good VM and the OS, and the godd VM could detect and report on the bad VM :) (long way to go about it).

ROM Boot Keys (4, Interesting)

PktLoss (647983) | more than 8 years ago | (#14896004)

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.

Re:ROM Boot Keys (1)

imemyself (757318) | more than 8 years ago | (#14896324)

That sounds waaaay to close to TPM for my liking. I tend to go along with the thought process that the hardware is along for the ride and shouldn't give a fuck about what's running on it.

translation (5, Insightful)

Anonymous Coward | more than 8 years ago | (#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..

Kind of a sneaky advertisement, isn't it? Instill terror to sell vendor lockin hardware and operating systems. Maybe even get a law or three passed. They sort of gloss over the "get the rootkit there in the first place" part, don't they?

Re:translation (1)

Dunbal (464142) | more than 8 years ago | (#14896116)

Instill terror to sell vendor lockin hardware and operating systems.

      Isn't that what anti-virus companies and (dare I say it?) politicians have been doing for many years...

Re:translation (0)

Anonymous Coward | more than 8 years ago | (#14896120)

They sort of gloss over the "get the rootkit there in the first place" part, don't they?


Well yeah, they're admitting that getting rooted on Windows is as hard as breathing

And as for the Linux test, they're MS researchers. You expected them to not completely lie their ass off about it?!

Link to research paper (4, Interesting)

saikatguha266 (688325) | more than 8 years ago | (#14896030)

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

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 (1)

ptelligence (685287) | more than 8 years ago | (#14896069)

Take the security software off of the hard drive. Put it on a bootable Knoppix CD.

Re:Link to research paper (1)

tepples (727027) | more than 8 years ago | (#14896131)

Take the security software off of the hard drive. Put it on a bootable Knoppix CD.

And when the rootkit is inserted into BIOS, then what?

Re:Link to research paper (0)

Anonymous Coward | more than 8 years ago | (#14896233)

hmmmm, perhaps you might like to explain how you could put a rootkit in BIOS and still keep the system even reaching POST... seems like if you flashed your own code to most BIOS's that you have 2 choices 1. put your own ~1 meg of code and not probe any (or much) hardware or 2. try to cram a few more bytes into the bios, not to metion the fact that MOST BIOS only accept images from floppies (a few will take usb keys). so.....yeah, next time someone offers me a free BIOS upgrade and its not the pheonix website or my mobo manufacturer's website.... lemme get a floppy >;-) NOT!!!

Re:Link to research paper (1)

saikatguha266 (688325) | more than 8 years ago | (#14896257)

Do you trust that computer that you are using to burn that bootable CD? What if that computer is already rooted, and you don't know? What if the rootkit is hiding in the CDBurder firmware, or can intercept the burn request being sent out of the VM you are (unknowingly) running inside of?

The rootkit can ensure it gets onto that bootable CD in any number of ways.

Re:Link to research paper (1)

BitwizeGHC (145393) | more than 8 years ago | (#14896070)

Some sort of open BIOS, like LinuxBIOS, would be a good way to go too; but this is Microsoft Research we're talking about here, and Microsoft wants control over your hardware just as bad, if not worse, than any skript kiddie.

Re:Link to research paper (4, Interesting)

Jon Luckey (7563) | more than 8 years ago | (#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.

Re:Link to research paper (1)

saikatguha266 (688325) | more than 8 years ago | (#14896226)

You are thinking x86; there are other fully virtualizable architectures.

But fundamentally, can software attest to software state? Can software prove that it is correct (i.e. not under the influence of other software)? I suspect there may be a way to show that software cannot prove its own correctness along the lines of Gõdel's incompleteness theorem. That leaves only hardware that can attest to software state.

What sort of primitives would the hardware then need to provide to help the software convince itself that it is running in a safe environment? Would a simple am-I-running-in-ring-0 hardware command suffice? Presumably the software doesn't mind running inside a VM -- it just doesn't want to run inside a VM under malicious control. So a simple ring-0-or-not solves the rootkit problem by essentially curtailing the very functionality provided by VMs in the first place. Back to what primitives are needed from the hardware; the TCPA approach suddenly starts to make sense. It says the hardware will compute a secure hash of the runtime memory image and sign it. Software can then see what it is running inside of (whether the hash matches good VM controllers', or not).

Re:Link to research paper (1)

marcosdumay (620877) | more than 8 years ago | (#14896306)

Just remember:
TCPA that gives the keys to YOU - GOOD
TCPA that gives the keys to people SPYING you - BAD

Anyway, running it from a read only memory is a way to avoid rootkits with hardware while not using TCPA.

Re:Link to research paper (4, Insightful)

radtea (464814) | more than 8 years ago | (#14896238)

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

Almost trivially.

The whole point of TCPA is that "trust" is built in to the machine in a fundamentally inaccessbile (to the user) way.

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.

Re:Link to research paper (1)

saikatguha266 (688325) | more than 8 years ago | (#14896292)

> hook a logic analyzer up to the BIOS. Look at the nice bits go by. See if they match expectations.

Precisely. You need your hardware to verify that the software is in known-good state.

To make this approach feasibly, incorporate your logic analyzer into the CPU itself. Make the verification a hash function. And voila, you have just reinvented TCPA. Congrats.

The problem with TCPA is not that it is "inaccessbile (to the user)". The problem is that is does exactly what it is intended to do, and what you intend it to do. To stop code from running that is not trusted.

How you define what code is "trusted" depends on the application. Your nice application (bootloader in this case) may ask the user -- is this code trusted? That is a good use of TCPA. Microsoft's bootloader would not ask the user, and that is a bad use of TCPA.

Quick! Is a gun good or bad? TCPA is a gun. You can shoot the bad guys with it, or others can shoot you with it.

But my question stands -- can you win against rootkits without TCPA? (reinventing TCPA and calling it logic-analyzer-verifier doesn't count)

Re:Link to research paper (1)

SiliconEntity (448450) | more than 8 years ago | (#14896321)

The whole point of TCPA is that "trust" is built in to the machine in a fundamentally inaccessbile (to the user) way.

You don't know anything about TCPA. The whole point is to do a "trusted boot" so that the state of the machine can be known and reported in an unforgeable way. This allows both users and remote parties to know that the machine is running a certain configuration, with no rootkits or malware installed. This process protects the user against attacks contrary to your statement above.

It also allows the user to prove to remote systems what his configuration is, which allows them to trust what his software will do. This is what you don't like, you don't want to be able to make convincing attestations about your software configuration, because then remote systems might refuse to talk to you unless you are running a configuration they approve of.

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.

Performance Degration (3, Insightful)

nurb432 (527695) | more than 8 years ago | (#14896037)

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.

There might also be driver issues that could tip you off something isnt right. May not know what, but it should be apparent something is amis. It would have to emuate all the hardware that you had installed at the time of infection, unlike something like VMWare which presents a 'standard' ( but different ) set of hardware devices. Thats a prety tall order to pull off.

i've found a way to defeat this (3, Funny)

circletimessquare (444983) | more than 8 years ago | (#14896053)

i've been working on a compromised system to poke for holes in the concept and i hit upon a novel idea. in fact, it's really simple

all you have to do is-END CARRIER-

Re:i've found a way to defeat this (0)

Anonymous Coward | more than 8 years ago | (#14896228)

It's called NO CARRIER, moron.

Sheesh, kids these days.

Multiple Strains (0)

Anonymous Coward | more than 8 years ago | (#14896066)

What would prevent another virtual machine virus from going underneath the first one? The sandwiched in virtual machines would be even more undetectible. The only solution I can think of: replace the physical CPU with a harware CPU emulator, and run anti-virus software on the real CPU. This shouldn't effect performance, and would be undectible to any layer of the virtual machine fuck-fest.

Virtually. (2, Insightful)

Roskolnikov (68772) | more than 8 years ago | (#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.
examples:

I bought 4 GB of ram and a 400 GB drive, now I have 1 GB and 150 GB drive (with 250 GB overhead for mail and porn).
My Ultra-Monkey quad SLI Nvidia 9999 video card with 1 GB of ram now shows up as a 16 MB S3 Virge card, WTF?
My Comcastic experience is now more like my old netcom dial up account but the cable modems lights are busy.

Its really good to see Microsoft concerned about security, but I hope they will stop looking at how elaborate the hacks could be and focus more on why this crap
can be done in the first place.....

Re:Virtually. (1)

woolio (927141) | more than 8 years ago | (#14896113)

Couldn't malware just work at the driver level, similar to the Sony "rootkit" that got in-between the apps and the cdrom?

This would be almost invisible to the user, but really really bad things could be done. (Like bypassing firewalls, avoiding packet-capture programs, hiding files, etc).

Not hard to detect (1, Redundant)

LLuthor (909583) | more than 8 years ago | (#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.

Gaming performance would take a serious hit, as would anything that would normally require privileged hardware access.

No virtual machine can work as fast as the host system or with as much RAM.

Re:Not hard to detect (1)

Helios1182 (629010) | more than 8 years ago | (#14896207)

It can be very very close though. We are not talking about emulation (running ppc code on x86 or similar) here, it is virtulization. The instructions are still native, just being passed through another transparent layer.

Re:Not hard to detect (4, Interesting)

LLuthor (909583) | more than 8 years ago | (#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.

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

Re:Not hard to detect (1)

Helios1182 (629010) | more than 8 years ago | (#14896311)

Thanks for pointing that out. Still, most people aren't gamers. Most use only a tiny fraction of the available power they have. The difference between using 5% and 15% of the CPU will be undetectable to them. The casual computer user is also more apt to be affected by rootkits & viruses as well, making the problem worse.

I should probably do more research on systems stuff in the future, it really isn't my focus.

Re:Not hard to detect (1)

marcosdumay (620877) | more than 8 years ago | (#14896320)

The VM can reinterpret the software and run it, with no emulation. It doesn't need to drasticaly change the computer's speed. There are already VMs that do this, they are not that usefull, but can hide a rootkit.

Am I the only one here who saw... (4, Funny)

MikeRT (947531) | more than 8 years ago | (#14896085)

an image of an idiot user taking their computer to a repair shop and the repair person uncovering 500 instances of VMWare running with 1 instance of spyware in each one?

VB VM attack confirmed (1, Interesting)

Anonymous Coward | more than 8 years ago | (#14896109)

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.

Holy Crap! (2, Insightful)

PhunkySchtuff (208108) | more than 8 years ago | (#14896115)

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

Re:Holy Crap! (1)

AvitarX (172628) | more than 8 years ago | (#14896253)

Please re-read the summary.

Also, there is huge money in malware, recently a /. article mentioned some high-school drop out making 6000 a month. though not extraordinarly large amounts of money, it is a hell of a lot. And if you are a slacker it is hard to get that much money out of college tax free (even if you arn't a slacker it is).

Re:Holy Crap! (0)

Anonymous Coward | more than 8 years ago | (#14896304)

What if they are being payed well, by a large multinational convicted monopolist with a vested interest in seeing a trusted computing platform gain widespread use and acceptance.

Imagine how rootkits manufactured by said company could be used as evidence that the consumer has something to gain through additional DRM, and trusted computing hardware.

Oh Great... (0, Troll)

threedognit3 (854836) | more than 8 years ago | (#14896135)

Within five years we'll have a college graduate who worked on this project but in the end barely passed. Not being able to find a decent job they'll resort to plying their knowledge in the neitherworld. I'm stickin' with Atari.

The solution (3, Informative)

aachrisg (899192) | more than 8 years ago | (#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.

Re:The solution (1)

poopdeville (841677) | more than 8 years ago | (#14896227)

Actually, the real solution is to keep booting information on a flash chip with a physical switch to change it from read only to read/write. Putting up more layers of abstraction is just going to hurt performance while prolonging this game of cat and mouse, as each layer will have vulnerabilities of its own.

Summary Reduction (0)

Anonymous Coward | more than 8 years ago | (#14896142)

Here is the summary reduction: humans are crafty and creative.

Big Fleas have Little Fleas upon thier backs (2, Interesting)

Jon Luckey (7563) | more than 8 years ago | (#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.

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)

Re:Big Fleas have Little Fleas upon thier backs (0)

Anonymous Coward | more than 8 years ago | (#14896175)

Trusted computing is honestly, in my opinion, the best solution. The problem isn't the nature of hardware-level controls over the software; the problem is who controls those controls. They should be open and owned by the user, and should not restrict vendors or enable any secret DRM. In most civilized countries this kind of behaviour is considered invasion of privacy, fraud, unfair business practices, etc. Call it capitalism as long as you want, but I'll be dancing on your graves. ;)

Which is why I like OpenBSD! (1, Funny)

martinultima (832468) | more than 8 years ago | (#14896171)

Microsoft Techie #1: How are we going to get this to work?? Hmm, maybe we can stick this virtual machine monitor here, and then we can trick the highly technical, security-conscious guys who would use the system into giving us root access so we could put it before kernel secure mode is initiated?

Microsoft Techie #2: Nah, too complicated. Let's just wait until the next default security hole...

Just one problem: (5, Insightful)

guruevi (827432) | more than 8 years ago | (#14896181)

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.

And as soon as you notice your box could be r00t3d, you take it out anyway and don't trust it. And if you don't notice one of your boxes is generating extra traffic or doing things it shouldn't, you shouldn't have to have admin privileges anyway.

Please Stop (0, Flamebait)

cgenman (325138) | more than 8 years ago | (#14896183)

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.

Please Stop. Find a good, solid fix... or find code in the wild, then post about it.

--This post intentionally left inflamatory. Please let me know where I'm wrong.

Protect Boot sector? (0)

Anonymous Coward | more than 8 years ago | (#14896203)

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?

I'm starting to wonder if I am better off just writing a general immune
system for my computer. The _effects_ of spyware, viruses, worms, rootkits
(or rather rootkit installers), etc are
the issue. Does it really make sense to keep fighting against them specifically?

Re:Protect Boot sector? (1)

amliebsch (724858) | more than 8 years ago | (#14896245)

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?

No, because it would only be preventing access to the virtual boot sector.

Microsoft start to support linux? (2, Funny)

sql_noob (855995) | more than 8 years ago | (#14896219)

Microsoft start to SUPPORT linux? And start off with a rootkit prototype?

Man, that is how a friend should be.

Get Your Facts Right /.! (0)

Anonymous Coward | more than 8 years ago | (#14896282)

The root kits run on linux/vm ware not linux! Which means they essentially take advantage of higher level operations in linux, this in turn means that they are easily detectable by any linux OS (once the signature is known) because they are only running above run level 5. However on a true Windows OS they will be almost undetectable to everything unless there were intelligent software in the bios to detect them then report the finding to the OS.

The advent of these low level root kits could bring Norton (Symantec) new business..but it will not effect Linux developers in the least. The article did not state that root kits of this nature will compromise linux in anyway. Compromising an ad hoc system like VM ware running Windows on linux is a bonus, not a problem.

VM Machine Rootkits (3, Interesting)

Orion Blastar (457579) | more than 8 years ago | (#14896300)

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.

Secure installation (2, Interesting)

Anne Honime (828246) | more than 8 years ago | (#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.

Wow. (2, Interesting)

mindstrm (20013) | more than 8 years ago | (#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.

First one to publish a detector for this gets good press.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...