Slashdot Log In
Microsoft Research Warn About VM-Based Rootkits
Posted by
Zonk
on Fri Mar 10, 2006 08:56 PM
from the why-would-you-prove-that-concept? dept.
from the why-would-you-prove-that-concept? 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."
Related Stories
[+]
Undetectable Rootkits Through Virtualization? 237 comments
techmuse writes "eWeek has an article about a prototype rootkit that is implemented using a virtual machine hypervisor running on top of AMD's Pacifica virtualization implementation. The idea is that the target OS, or software running on it, would not be able to detect the rootkit, because the OS would be running virtualized on top of the rootkit. The prototype is supposed to be demonstrated at the Syscan conference and the Black Hat Briefings over the next month."
[+]
VM-Based Rootkits Proved Easily Detectable 128 comments
paleshadows writes "A year and a half has passed since SubVirt, the first VMM (virtual machine monitor) based rootkit, was introduced (PDF), covered in the tech press, and discussed here. Later Joanna Rutkowska made news by claiming she had a VMM-based attack on Vista that was undetectable — a claim that was roundly challenged. Now in this year's HotOS workshop, researchers from Stanford, CMU, VMware, and XenSource have published a paper titled Compatibility Is Not Transparency: VMM Detection Myths and Realities (PDF) showing that VMM-based rootkits are actually easily detectable."
This discussion has been archived.
No new comments can be posted.
Microsoft Research Warn About VM-Based Rootkits
|
Log In/Create an Account
| Top
| 336 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
I say we take off... (Score:5, Funny)
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... (Score:5, Informative)
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... (Score:4, Insightful)
(http://www.bcgreen.com/~samuel | Last Journal: Saturday April 15 2006, @12:27PM)
Well, if you take a suspect disk, put it in a clean machine and then boot from the suspect disk then you're not just boned.... you're too stupid to be an investigator.
Re:I say we take off... (Score:4, Insightful)
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.
Automated BIOS flashing considered harmful. (Score:5, Interesting)
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:Automated BIOS flashing considered harmful. (Score:4, Informative)
Besides, swapping chips in a socket isn't a fun user experience, and these are probably high end boards where money isn't an object anyway.
Re:I say we take off... (Score:4, Interesting)
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.
Re:I say we take off... (Score:5, Funny)
(http://translate.goo...%7Ces&u=slashdot.org)
Re:I say we take off... (Score:5, Funny)
Just remind me when was Skynet supposed to become sentient again?
Re:I say we take off... (Score:5, Informative)
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 (Score:5, Insightful)
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.
Stephen R. Donaldson of all people. (Score:5, Interesting)
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.
Why is microsoft researching this? (Score:3, Insightful)
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? (Score:5, Insightful)
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? (Score:5, Insightful)
Ummmm
Re:Why is microsoft researching this? (Score:5, Insightful)
Re:Why is microsoft researching this? (Score:5, Interesting)
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..."
Re:Nice FUD (Score:5, Interesting)
(Last Journal: Wednesday October 24, @03:50AM)
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.The one thing I hate about Microsoft products... (Score:5, Funny)
(http://www.creimer.ws/ | Last Journal: Friday January 26 2007, @12:40PM)
Original Paper (i.e., karma whoring) (Score:5, Informative)
(http://www.ganfamily.com/)
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.
Re:Conclusion from Paper (Score:4, Insightful)
(Last Journal: Saturday February 25 2006, @11:02PM)
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.
rootkits? (Score:3, Interesting)
(http://www.gcnaddict.com/)
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?
Of Course (Score:3, Insightful)
(Last Journal: Saturday October 27, @10:19AM)
i was under the impression (Score:3, Insightful)
(http://www.p10link.net/plugwash/)
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 (Score:4, Interesting)
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_virtu
ROM Boot Keys (Score:5, Interesting)
(http://www.preinheimer.com/ | Last Journal: Friday August 22 2003, @10:32AM)
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.
translation (Score:5, Insightful)
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?
Link to research paper (Score:5, Interesting)
(http://saikat.guha.cc/)
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?
Re:Link to research paper (Score:5, Interesting)
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 (Score:5, Interesting)
The thing with emulating a "ring 0" environment is that there is a lot to emulate. Most everything that would not work in a true ring 0 environment would cause the CPU to raise an interrupt for the host OS to handle. Typically the OS handles it by smacking around the application for being bad and doing something it isn't supposed to do. But it is possible to instead do what it is trying to do, and make it look like nothing was amiss.
The trouble is there is a lot of different things to deal with. If you know your target OS, it's easier since you don't need to emulate every little thing the CPU does, just what the OS will be using. But even then there will always be telltale fingerprints that something is amiss. Theoretically you could get around some of them by scanning ahead the instructions to be executed, but at some point you seriously impact system performance, and that in itself will make people notice.
Off the top of my head, the simplest way to detect it takes advantage of the fact that emulating ring 0 operations involve a context switch and some execution. Context switches tend to be rather expensive operations compared to most everything else the CPU does. The CPU has something called a timestamp counter, which basically counts every clock cycle, always incrememting, no matter what process/thread is running. An instructions should take a deterministic number of clock cycles. So just check the timestamp counter, perform a priveleged instruction, then check the timestamp counter again. If it looks like it took too long, that means you are running under a virtual machine.
Of course detection doesn't help with removal, but it's a start.
Re:Link to research paper (Score:5, Insightful)
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 (Score:4, Informative)
(http://arstechnica.com/journals/linux.ars)
Mmmmmm... KoolAid.
Dude, I trust a machine to do exactly as it's told. I do not trust humans to do the same. Trusted Computing is an aphorism for "Hey, you can trust $VENDOR, since your machine does, due to $TECHNOLOGY." Fuck that.
If you r00t a computer, you're after one thing - getting information _out_ of said machine. (THINK - Credit card #s or Spam - it all has to leave the machine somehow.) You need to do this via a network connection, USB key or some other means. There are ways of noticing that information has left a machine in some way, either through physical security or other means (It'll be a cold day in Hades before a vendor brings a cell phone into my data center. Those things have memory, after all.) since once outside the box it's no longer under the control of the r00tk1t. IOW, if someone r00ts one of my machines, it'll be either noticed or totally useless to them.
I, and I alone, establish trust of my systems. Any vendor who says they can do that for me is sadly mistaken, unless they are willing to allow me to completely vet thier Trust protocol and methods. Even then, I had better be able to fully audit that system at a whim, on my terms.
"Trusted Computing" is for those who don't want to learn or do thier job professionally, are just plain lazy or, they're willing to drink the KoolAid. As for users, they tend to trust people, like me, who fix thier broken systems, and take my advice to heart when I charge them $TEXAS for fixing thier broken assed PCs.
Soko
Performance Degration (Score:4, Insightful)
(http://slashdot.org/~nurb432/ | Last Journal: Friday August 27 2004, @03:24PM)
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 (Score:4, Funny)
(http://circletimessquare.com/)
all you have to do is-END CARRIER-
Virtually. (Score:2, Insightful)
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.....
Not hard to detect (Score:2, Redundant)
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 (Score:5, Interesting)
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.
Am I the only one here who saw... (Score:5, Funny)
(http://www.codemonkeyramblings.com/)
VB VM attack confirmed (Score:1, Interesting)
Holy Crap! (Score:3, Insightful)
(http://www.rocketcat.info/)
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...
The solution (Score:3, Informative)
Big Fleas have Little Fleas upon thier backs (Score:3, Interesting)
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)
Which is why I like OpenBSD! (Score:1, Funny)
(http://ultima-inet.kicks-ass.org/~multima | Last Journal: Wednesday June 14 2006, @03:43PM)
Microsoft Techie #2: Nah, too complicated. Let's just wait until the next default security hole...
Just one problem: (Score:5, Insightful)
(http://www.valerieandevi.be/)
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 (Score:1, Flamebait)
(http://www.chriscanfield.net/)
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.
Microsoft start to support linux? (Score:2, Funny)
Man, that is how a friend should be.
known security flaws (Score:1)
(http://www.myside-yourside.net/)
VM Machine Rootkits (Score:4, Interesting)
(http://www.geocities.com/orion_blastar/contact/ | Last Journal: Tuesday April 03 2007, @07:19PM)
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 (Score:3, Interesting)
VMM's can be detected (Score:3, Informative)
Wow. (Score:2, 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.
The obvious solution is... Windows VISTA! (Score:3, Funny)
Heck the OS is so large any VMBR trying to "hoist" it is going to probably:
A.) Run out of space (memory or HDD).
B.) Take so long to hoist the OS, the user will probably reboot thinking their machine's locked up again.
C.) Cause CowboyNeal to acquire a hernia.
They (MS) are probably just looking for more selling points for their new BIG baby.
Making the case for DRM in the hardware... (Score:1)
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.
The technology is here. And it would be relatively easy to at least secure the root of your system (BIOS and OS kernel) from rootkits.
The Big Impact (Score:2)
(http://www.behti.com/ | Last Journal: Sunday June 04 2006, @10:58PM)
Heh (Score:2)
(http://autopr0n.com/ | Last Journal: Saturday August 06 2005, @01:30AM)
The Reason this is Bullshit (Score:1)
(http://www.wanfear.com/~mbrito)
Does this mean.. (Score:2)
(http://www.xdesignlabs.com/)
Which will be used by MS to block (Score:2)
microsoft "research" (Score:1)
So buy an iSeries machine (Score:1)
With each passing day... (Score:1)
(http://www.jamesoft.net/)
Ultimate? (Score:3, Interesting)
(http://portal2portal.com/ | Last Journal: Monday June 04, @08:46PM)
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?
TCPA (Score:1)
Virtualization of a processor. (Score:2)
(http://www.bitwizard.nl/)
Clarification (Score:1)
In slides from WinHEC they present whole protected video path route. Even bus transfers are encrypted to prevent that type of attack. Kernel, signed and verified by TCPA chip, loads only signed video card drivers (which also take care that decrypted video content isn's ripped from VRAM. Kernel also takes care that nothing can "debug" processes which handle unencrypted data (although it is possible that GPU itself does that). In case of DVI output, device must support HDCP (which in fact is the weakest link in chain). I can imagine how with VMM program one could tinkering with running kernel and, for example, get unsigned (hacked) video drivers to load.
I wonder if starforce folks are going to try to get in control of VMM on new CPUs if everything else fails against Daemon Tools 4.
hey, this could be a good thing (Score:2)
Tripwire (Score:2)
(http://www.dvstocklocker.com/ | Last Journal: Wednesday October 20 2004, @06:21PM)
I don't think you can move a running OS into a VM so there would have to be a reboot, at which point Tripwire would start screaming at you. Unless they find a way around the key based access that Tripwires dbase uses.
Tripwire is included in FC4s Extras [fedoraproject.org] repository BTW.
15736th time. (Score:1)
Problem solved (Score:1)
The Bootable ROM checks the new BIOS image for a digital signature. To avoid "Trusted Computing" the Bootable ROM allows you to choose if you want to install only a properly signed BIOS image, or a custom one (although that option risks rootkits).
Yes But: MAC (Score:2)
(http://linuxbox.com/)
It is helpful to reduce the vulnerability of systems to code execution flaws, and this can be done by running code in an already-restricted execution environment.
*sigh* Oh, sure.... (Score:3, Funny)
(Last Journal: Monday March 20 2006, @08:33PM)
yes, Microsoft warns about this... (Score:2)
Insight about this research (Score:1)
Re:Protect Boot sector? (Score:2)
(Last Journal: Friday February 10 2006, @02:51PM)
No, because it would only be preventing access to the virtual boot sector.
Re:Multiple Strains (Score:4, Funny)