Slashdot Mirror
Undetectable Rootkits Through Virtualization?
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."
fta:
Rutkowska stressed that the Blue Pill technology does not rely on any bug of the underlying operating system. "I have implemented a working prototype for Vista x64, but I see no reasons why it should not be possible to port it to other operating systems, like Linux or BSD which can be run on x64 platform," she added.
Implementing malware with virtual machines
Who runs anything *real* on a virtual server?
Can't you just take the hard drive out, mount it from another computer, and see all the malicious DLLs the rootkit was trying to hide from you?
Current virtualization doesn't virtualize anything but basic VGA graphics. That's certainly noticable.
Boss asks: are you playing games at work?!
Me: Just checking for rootkits boss!
Some, albeit high end, motherboards support a visual warning message that alerts the user to a program, or the OS trying to modify the boot sector on the hard disk. If you had this enabled it would stop this rootkit dead in its tracks. It's just a shame that more bioses / motherboards don't offer this support by default.
If you have this on your motherboard I highly recommend you turn it on, it isn't too often that you reinstall the OS and pressing F9 isn't that much of an inconvenience even if you did it once a day.
PS - All of the "My favorite OS is secure" posts below this are wrong if the Operating System supports some type of driver, or root program (running in the kernels memory space).
If your system suffered a successful intrusion, you wipe.
/dev/null.
Of course, there were LKM rootkits (pretty hard to detect) for a good while now, this is just taking it to an all new level.
I wish the spread of better hidden rootkits on Windows, because only that will further sane security policies and wipe the stupid idea of virus scanners out (when it's doing IDS not IPS). There ain't such thing as 'intrusion removal'. It's like putting on a condom after sex. Oh wait, it's slashdot. Let me rephrase. It is like trying to recover data from
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
Thats the reason of all that institucional "support"
From TFA:
I don't think this changes the situation much. Viruses have always tried to hide. This just requires different methods to detect them. Ultimately some viruses can only be reliably detected by booting off of readonly media. The same now as before. I think OS providers should provide a boot disk for routine scanning as a matter of standard procedure.
Perhaps there could be an OS that wouldn't allow malware to be injected through root-trust, signed applications, memory compartmentalization with read, write, execute permissions and 4 privilege levels (instead of 2). Of course, that wouldn't be Windows or Linux or BSD or any other generic OS.
So, just as you would expect, the future of having CPUs with hardware support for virtualization will be wonderful for preserving absolutely perfect security and cloaking for rootkits and their owners. In fact, thinking of why a certain class of non-blackhat beneficiaries would very much like such a possibility, this could be why both Intel and AMD are planning to ensure that all future CPUs, including even those in ordinary non-server desktop PCs, will have compulsory (permanently enabled) hardware support for virtualization. You know the routine - think of the children etc etc.
Technically it's not rooting an OS but actually is almost it's own OS (hypervisor actually) that is running the OS in a virtual machine. Couldn't you get the same effect by hacking BIOS?
--- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
Is this really a surprise? Given the layered design of software, if you have something that can sit between the hardware and the software (and monitor what passes between, and control said information), they why would it not have complete control? The question is how could this easily be placed on someone's machine? The next question is why can a level of virtualization be introduced between the operating system and the hardware during execution?
"your operating system swallows the Blue Pill and it awakes inside the Matrix controlled by the ultra thin Blue Pill hypervisor. This all happens on-the-fly (i.e. without restarting the system)"
- Kal`Goblez
The Matrix has you.
Did you ever notice that *nix doesn't even cover Linux?
Microsoft already working on one to address teh issue. I dont know if you have to pay additional money as MS hinted that ms antivirus will be a subscription service.
Running everything off a livecd is a good idea since most infected pc's are as slow as a 486 and could take hours to days to scan. In this case it would be ineffective.
I wonder if bios virii are next/? Its the only way to go above even booting off a pc and some malware and spyware makers are working on this. That way it can't be removed at all. Claria should be taken out to a field and shot.
http://saveie6.com/
This is not really different from running WinXP, then installing VMWare Workstation, then installing Win2K in a virtual machine.
The "host" OS is what gets infected. That would be WinXP. Of course nothing running in the "guest OS (Win2K) would be able to detect it. But
There are only three (3) ways for the "underlying operating system" to be infected.
#1. Worm
#2. Virus
#3. Trojan
If we aren't talking "nude pictures of celebrities", then it's either a worm or a virus and both of those are bugs in the OS.
If it's a trojan, then WTF are you doing installing unknown apps on the host OS?
Now, the only way this would be interesting would be if the worm / virus / trojan installed the virtualization software, moved the existing OS to a virtual machine and faked the names of all the interfaces (NIC, IDE controller, etc). If you can do that, VMWare really wants to talk to you.
I don't know about your company, but I work for a giant Fortune 100 multinational company, by far one of the largest and most profitable and recognizable ones in the world. I'm very familiar with our computing environment, and I can tell you with absolute certainty that running applications on virtual machines is not only common here, it's a very important part of our future.
Yes, real applications, the kind that are business critical.
Is it a smart move? Maybe yes, maybe no. If you want to argue about it, go for it. (I don't really care one way or another.) But is it happening? Hell yeah, it already has.
"Is this testing whether I'm a virtual machine or a lesbian, Mr. Dowd?"
There are no trails. There are no trees out here.
No, actually the piano was hit by the rootkit pretty badly. Tom says that he has nothing to do with it.
I've been telling people this for a while, mainly to blank stares; you cannot detect if you have a virus/keylogger/spyware on your system. All those utilities people pay so much for are worthless! They only detect the known malware, but nobody knows about the undetected hacks. The technology discussed in this article has been around for longer than the OS's have been!
You must assume in this day and age that if your computers will become infected with undetectable malware within a relatively short time of normal internet connectivity.
Accepting this then, the only truly safe way to compute today is to keep your boot/OS/application drive from being writable. Baring this, the next best step is to re-image your drive from non-writable media daily. Throw away the expensive antivirus scanners, they do nothing.
Are you staring blankly at me? Did you know that you can reimage your drive in 5 minutes and guarantee your computer is clean? Thats far less time than it takes a scanner to scan ineffectively your system files. The main trick is to boot from a DVD and to store the image on an external harddrive. And to use a certain discipline in creating incremental images that keep them malware free. This, along with a firewall, is the only reliable defense today.
I remember an article a couple of months ago where Microsoft employees had done something similiar, that is using virtualization to create a low level rootkit.
Because, y'know, the only way to protect yourself against attacks like these are with Trusted Platform Modules.
20 bucks Microsoft sponsored this research in some way.
I don't think that anyone is suprised by this. After all, it is common sense that the virtual OS's security is at the pleasure of the host, in much the same way that the security of a user-mode process is at the pleasure of the operating system. If there is anything between you and the actual naked hardware, then there is always the possiblity that that layer is doing something with your data that you don't lie.
...En að Besta Sem Guð Hefur Skapað Er Nýr Dagur
If you ran a VMWare image, and inside it ran a virus scanner, could you expect the scanner to detect viruses outside the image, in your hosting OS?
Since the VM is simulating all privileged instructions, the undetectability really isn't a surprise.
What's really impressive is that she has a way for a user mode program to reach between the OS and hardware and lift Vista onto a VM all without rebooting. Her Blackhat session will prove interesting.
This is regarding Linux rather than Windows but:
Host machine with Vserver kernel running Tripwire or Aide
with configuration adjustments to detect changes in client "machines"
Host machine well protected
client machines doing ftp or web services or email or.....
Although Vserver is particular to Linux: Other schemes doing
reasonably strong virtualization can also do the job in Linux,
Solaris (Zones), BSD (Containers), Windows, etc.
It should greatly decrease the ability of something as clever as
BluePill to do damage if it was infecting a well-partitioned virtual
machine rather than a regular machine.
Vserver: http://linux-vserver.org/
AIDE: http://www.securityfocus.com/infocus/1424
This is actually the good side to the Trusted Platform Module - you can set up your machine to refuse to boot, warn you, whatever if anything in the boot process changes. As it's implemented in BIOS with hashing of the boot process before it even loads it from disk, there's no real way around this short of having physical access to the machine and turning off the TPM.
The bad side of the TPM is when you lose control of it - then the machine isn't yours any more but the xxAA's.
Fear: When you see B8 00 4C CD 21 and know what it means
This idea has been discussed on slashdot before, and it seemed that the consensus was only DRM would be able to thwart this strategy.
Which is kind of interesting, since DRM otherwise sucks.
Your thoughts?
The trusted machine hardware, I have heard (from a src I believe), has a command to dump keys that are used. Unfortunately the designers were unable to think of anything better to do, so the key dump dumps them in the clear. Result is that hiding keys there is impossible also. So forget about that avenue saving things.
What could help would be a boot path that could be varied with many such paths on a machine. That at least might afford some way to get into a different OS and examine the underlying hardware from there now and then. Perhaps this should be taken as a reason virtualization in hardware should be made impossible. (It is easy to do that: any nonpriv'd instruction that changes privilege state for example will do that. A "go to user mode" that always works, for instance, would do.)
Can't the same trick be used to make a rootkit-safe environment? Launch a watchdog application and let that watchdog application launch the real OS in a virtualized environment, as soon as a rootkit wants to fiddle the watchdog application takes notice and there would be no way for the rootkit to either detect or by pass the watchdog. Or even more drastic, launch each (or most) process in a virtualized environment, would probally be a little slow, but should provide a extremly secure OS.
"A Slashdot article just went by, and then another one that looks just like it!"
"It's a glitch in the rootkit! It happens when it changes something!"
"No, I said a SLASHDOT article."
"Ah, you're probably fine then."
For clarity, I mean the technology behind DRM, namely trusted computing and signed executables.
There is only ONE RootKit! the original Geekboy band
And they need your votes to win google idol!
http://www.roootkitonline.com/
... it's not your machine anymore.
Your sig isn't scary, it just returns an error code of 0 (Success) to DOS. I'd be more worried about INT 13 calls...
From the wikipedia entry;
Hardware availability of VT
Intel calls its hardware assistance for emulation "VT" although it is often referred to by its codename "Vanderpool". It was officially launched at the Intel Developer Forum Spring 2005. It is available on all Pentium 4 6x2, Pentium D 9xx, Xeon 7xxx and Core Duo processors, though in the latter case it is sometimes disabled in the BIOS/EFI.
So does this mean that earlier pentium III processors are secure from this particular rootkit attack? And because it can be disabled in the Core Duo in bios, is their a low-level bios routine that might be used to detect such a rootkit for other processors? I know that there is work to boot directly into linux from the bios firmware.
A virtual machine can't tell anything about the state of the host it runs on other than what's exposed to it? Isn't this kinda like saying that if you use an oscilloscope to monitor bit flips on the bus, the OS can't detect it? How is this news?
Loading...
Launch a watchdog application and let that watchdog application launch the real OS in a virtualized environment, as soon as a rootkit wants to fiddle
;)
Or the watchdog could use a similar exploit to jump above the rootkit and look down to see what is running. If we're nested one level too deep then we've got a problem.
Assuming of course we can nest. If we can't, the failure to nest would show the problem.
Or you could always run something using heavy 3D, and if the CPU ignites then something's up.
Is there truly no way to detect that the current running OS is running on virtualized hardware?
I mean, sure the toplevel malware kernel can intercept attempts to read the current running kernel and other memory/system locations. And that all becomes a cat and mouse excercise. But thats how rootkit security has always been. Again, what I'm asking to someone knowledgable is- does the new wave of hardware supported virtualization make it truly impossible for a process in the virtualized host to detect that it's been virtualized?
I mean, couldn't you look at the reported processor, and run a suite of simple benchmark code, and detect that a parasite meta-host is sucking away cycles that you expect to be there (this assumes the benchmark/detection code is run as root/kernel, and can therefore stop/ignore all other processes for some inconsequential amount of time).
-jdog
What could the virus do? I doubt it could swap to disk to cover that. I guess it could try using compression on a small part of the guest OS.
Exactly the same thing was done using the ancient "cookie monster" program on Multics, long before Unix was even a gleam in T&R's eye.
The perpetrator created a user-ring instance of a user (a virtual-machine-like process), loaded in the cookie mosnter, then loaded the command interpreter and handed the result to an unsuspecting user, my boss.
He searchrd high and low, never suspecting the program that kept saying "Want cookie!" was down below the shell.
--dave
davecb@spamcop.net
I don't know about you, but when I start up VMWare in windows (or parrellels in OS X) I definatley notice a performance hit. I find it difficult to believe that somebody wouldn't notice the fact that larg(ish depending on how exactly this is implemented) chunks of RAM and disk space are suddenly in use by some rogue program.
Look out honey cause I'm usin' technology
Ain't got time to make no apologies
Can we use this to bypass the DRM included in Vista?
In Soviet Russia the insensitive clod is YOU!
Ok, I see how that's a great technical feat, but how is this any different? If I suspect a machine at work I wipe it. If it's a friend asking for help, and there are tons of settings I can't easily copy, I use a LiveCD and hope for the best. The illusion of real-time scanners and programs like AdAware passed a long time ago. Unless the virus flashes the BIOS (kudoz to the writer), the LiveCD should still be able to track it down, right? Provided the signature is known of course. I don't see how this changes anything?
The fundamental question of systems administration: once you have had a root compromise, what can you do to the machine to get it back up and running, in a known good configuration, with all chances of future compromise as a result of the initial compromise removed?
Answer: either compare the system (booted from known good media) to a known good set of files, or reinstall from known good media.
There's no other answer. Any tools you run on the compromised system are by definition suspect; they might be good, or they might be compromised. You have no way of knowing; anything they tell you is suspect. Even if you have tool binaries that you know are good, you don't know that the data they're gathering reflects reality or has been altered to give you a wrong impression.
So the fact that this software is undetectable doesn't really change anything; you're still finding out about the compromise through unusual activity, so that's 'status quo'. The only thing that's different is the layer that's compromised.
The interesting question is how the software gets in place in the first instance to compromise the system. The answer is that it was run as root (or administrator, or supervisor, or whatever the super-user is called). How did it get root privileges? Two possible answers: (1) a flaw in the OS (defined as the kernel, and any processes running with root privileges); or (2) the end user ran it somehow as root.
In the first case, it's the standard security problem. The OS is flawed; anything can get root. That's a bug. In the second case, it's end user stupidity. Nothing you run as an end user should require root privileges. (If the OS is designed in such a way that you do, again, that's a flaw in the OS. If the application expects it when it doesn't really need it, that's a bug in the application, and the vendor should be shot.)
So there's another layer the rootkit can hide in. Be still, my beating heart! This is, and remains, nothing fundamentally new.
You need to only use the hot water.
You need 12 bars of new, still in shrink-wrap, soap.
You need to rub 1 min under water per bar of soap.
.....wee bit paranoid?
You think that's soup you're eating?
Yes I understand that TPM module is redundant as saying ATM machines.
People have know this for YEARS.
TPM is designed to create a tamper-proof non-virtualizable.
You see it goes like this:
Microsoft says to the hardware manufacturers:
"I want you to create these extensions to your motherboards and cpu chips that will allow use to run a protected virtual machine environment for our 'Palladium' project."
They (MS, Intel, AMD, and friends) thought about it for a while and said:
"Being about to provide a 100% virtulized environment for x86 can cause problems. If it's 100% compatable then end users won't be able to tell if they are running in a VM or not. This can lead to security problems. Also we need a way to ensure that Palladium and the system kernel as well a potentionally other software can be proven to be unmodified for security reasons and to impliment more efficient DRM controls"
"TPM will be specificly be designed not be virtualized so that software can tell if it's running in a VM or not. Otherwise it's impossible to tell."
(Palledium was a sort of protect-mode operating system running seperate, but inside of Windows Longhorn for implimenting more efficeient security and DRM controls. They were going to use a virtual machine environment and x86 is difficult to virtualize with speed.. so Microsoft had vendors change how x86 works.)
A year or two later AMD and Intel say:
"Good day Microsoft! We have implimented what you told us to do to run the next generation software! Intel has done VT and AMD has it's Pacifica technology. WOOT!"
Microsoft says:
"Sorry folks. Longhorn has most of it's features on the chopping block and palladium didn't make it"
Xen + Linux VM people said:
"Holy shit! This VT and Pacificia stuff rocks, we want to use it to make our para-virtualization technic work without having to modify the kernels of the operating systems running in the VM!"
Intel + AMD:
"Fuck ya! Here is a bunch of money and documentation. We will help make Xen work efficiently and we have all these other ideas on how to furthur virtualize the I/O of PCI devices and other things and the Linux kernel is perfect for this sort of thing!"
Xen/Linux folks:
"Cool (linus quietly adds support for various TPM hardware into 2.6.12)"
Vmware folks:
"Hey we can use this shit too"
Microsoft:
"Oh-oh shaggy, maybe forcing the hardware makers to bend to our designs then abandoning them wasn't a good idea..."
"Hey! Folks! over hear! We have this virtual server thing, we will release it for free although since it's obviously inferior to Vmware various and usefull VM enterprise server products. No need to look over there, those hippy fucks don't know what they are doing and it's hard to use"
(this has been dramatized slightly for Slashdot-friendly appeal)
Isn't Pacifica the old pallidum. This might be a good thing if AMD gets their ass handed back to them.
The next version of WGA will be undetectable? Thanks, Microsoft! ;)
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
There were some motherboard BIOSes that had built in boot sector virus scanning, but they didn't know anything about Free operating systems. A BIOS watchdog wouldn't be any better, most likely. The other problem with virtualization is that it does cause a slight overhead for any protected mode instructions that need to be virtualized. It doesn't help that the x386 architecture has several unprivileged instructions that can easily tell an OS whether it's being emulated or not (see this paper). Timing privileged instructions will also allow a hosted operating system to detect virtualization unless the entire system is emulated, which is very slow.
Or boot from a bootCD and investigate from there. You'd have to have the machine down, but a downed machine to catch a rootkit is often better than an infected machine doing who knows what.
I don't think they're right. Look at page 3 where they have their diagram showing the VMM in direct contact with the hardware.
Here's a simple test to see if they're right.
Put in a NIC that your host OS does not have drivers for. Your host OS will not be able to connect to the network. Now, if the virtual machine in their example can access the network, then they're correct.
There's no end of hype for "threats" that never seem to materialize (or are vastly over-stated). If they can do what their diagrams indicate, then this would revolutionize the computer industry. I really mean that.
For example, you would NEVER again have any problem with wireless networking under Linux. Or sound. Or any peripheral. Or hardware accelerated video. No more nVidia drivers needed! The VMM handles it for you!
So, no, I don't believe that what they claim is actually what they can deliver.
This is old news. SubVirt by Peter Chen's group at UMich is the original system which proposed this idea. FYI.
It's called Tron. It's a security program itself, actually. Monitors all the contacts between our system and other systems... If it finds anything going on that's not scheduled, it shuts it down. I sent you a memo on it.
DILLINGER
Mmm. Part of the Master Control Program?
ALAN
No, it'll run independently. It can watchdog the MCP as well.
Don't put advice in your sig.
I remember somewhere reading that the founder of Ubuntu, MArk Shuttleworth, wanted to get linux to the point of being as easy as Firefox to install. What better way than to install linux, and still virtualize Windows on top of it? Not very practical at this point, I admit, but this could be quite an impressive way to switch over, not to mention quite easy for the end-user. You could even set it up so that you could easily switch between the two.
SubVirt is the training wheels version, check this:
/ 33600#33600
http://www.securityfocus.com/columnists/402
Want to Talk?
http://www.securityfocus.com/comments/columns/402
~hylas
The rootkit's code name is "The Matrix"?
...the virtual hardware drivers. The driver software which is part of the vm management software is by definition standardized and thus a prime target for attack. It also operates below most antivirus software so if an exploit can be found in the virtual hardware, it concievable could leap from the virtual machine into the host operating system. At least that's the way I understand the process.
The problem with quotes on the internet, is that nobody bothers to check their veracity. -- Abraham Lincoln
Grandparent seems to think that BluePill merely is a mal-VMM that sits between any guest OS and the host OS. So the guest OS won't know that he's being thwarted. What these folks are claiming is two-fold:
- They'll do what SubVirt did -- move the VMM which is usually operating as a process on a host OS below that host OS. So, not only are all the guest OSs not going to know a/b the the mal-VMM, but also the host OS itself effectively becomes another guest OS.
- Unlike SubVirt which required that the mal-VMM exploit a vulnerability in the *host OS* in order to do this swallowing-up of the host OS, these folks' claim is that there are generic mechanisms to inject code into the Vista kernel. And these generic mechanisms are sufficient for this subversion.
- Moreover, they're saying that this is the case, despite security mechanisms in Vista that prevent kernel-mode code from running if that code is not signed (by a trusted party).
Anyway these are some pretty tall claims (particularly, re: the ability to inject arbitrary code into the Vista kernel). I initially thought the same thing as the grandparent: that they were saying that you could create a mal-VMM so that any VM running on that mal-VMM would not be able to detect the badness of the VMM (which is pretty trivial, actually).Of course, this assumes your watchdog OS doesn't have vulnerabilities...
> Of course, this assumes your watchdog OS doesn't have vulnerabilities...
:)
Yes, it is entertaining how many people solve the problem that "this OS gets infected" by saying, aha, we'll write another OS to watch if this OS gets infected, and never wonder, what happens when the 'another' OS gets infected.
You can see they are all unfamiliar with Russell
Keep in mind that I am NOT a programmer. Merely speculation here. In my understanding of rootkits is that they install themselves as a part of the operating system (Kernel Level) instead of a rogue program (Subsystem or User Space) taking advantage of Software holes or Poor User Rights admin. That being said, I know that LSASS.exe's default NTFS permissions are FULL CONTROL for Admin, System; and Read/Execute for Power users. With Virtual technology there would be two instances of all required system processes. Further, in the Virtual OS, you have Virtual Access to the Hardware within a Seperate Memory block. Now as a Rootkit, I would have to determine what user rights are currently in place, and which instance of LSASS is the Host or Real Mode OS. I could then use the guest OS to emulate NTFS permissions and further re-write Registry keys undetected. The cryptographic services then has to be fooled on either OS depending on what the programmer hopes to accomplish. Essentially, a rootkit on a guest OS would be more like a Nightmare virus. It would also have the potetnial to do more damage to either OS. Some helpful resources may be: Security Config and Analsis MMC. This is helpful when using templates. http://www.microsoft.com/windows2000/en/advanced/h elp/default.asp?url=/windows2000/en/advanced/help/ sag_SCMwhatis.htm
MRT: Malicious SOftware Removal Tool
http://support.microsoft.com/kb/890830
Further Check out RootKit Revealer and Autoruns @
http://www.sysinternals.com/
These should all be helpful running in the proper OS. I know this isn't meant to be a support article, however, some out there may have no clue as to where they should search for help. there are a number of other sites that could be listed and probably should be, but I'm refraining from going further as to maintain the scope of this Article.
There were some motherboard BIOSes that had built in boot sector virus scanning, but they didn't know anything about Free operating systems.
All the ones I've seen didn't know anything about any operating systems. They just trapped all writes to the boot sectors. You were expected to turn it off while installing an operating system.
Launch a watchdog application and let that watchdog application launch the real OS in a virtualized environment, as soon as a rootkit wants to fiddle the watchdog application takes notice and there would be no way for the rootkit to either detect or by pass the watchdog.
Well, it's possible, but you're presupposing the existence of a function that can reliably tell whether or not a rootkit is present, assuming it has full access to look at anything it wants. That would be a very useful tool in its own right. Unfortunately it's very very hard to create.
Can't the same trick be used to make a rootkit-safe environment?
Yes, provided you know exactly what the rootkit looks like and does.
Unfortunately, you are committed to looking exactly for something specific, the rootkit writer knows what you are looking for, and should be able to get by your defenses with some ridiculously bad disguise.
Who is to say that Microsoft won't use a similar technique to enforce WGA in the future for it's Windows OS?? Better to know now what is possible and how to defeat it. I like this concept though, it is very interesting and innovative (the hypervisor rootkit, not WGA)
In Soviet Russia the rootkit runs you!
Now it's the invading code in the 'software' that's supposed to be hardware. Not even the BIOS is safe anymore.
don't let the door hit you on the way out!
You're making a major mistake here. You're thinking the only way to build a secure core is to define badness, that is to define what must be blocked. That's well known to be a dumb way of doing it because you end up in an arms race to define all possible badness in the world. Crazy.
Far better is to define goodness. That is to say, define exactly when you'll allow something to bypass your protections. For best effect, do this in a way that is user-specific so that the onus in the arms race is wholly on the rootkit author. Let the blackhats do work (or, more likely, pick a different softer target).
"Little does he know, but there is no 'I' in 'Idiot'!"
The fact of the matter is, everything described in the article is implementable right now with existing hardware. Any x86 machine can emulate an x86 machine. If you don't believe me, take a look at qemu, which can do so entirely in user-mode.
Rutkowska's approach to detecting whether code is run in a virtual machine is based on checking the address of the IDT. This approach fails to detect qemu. Below, furthermost is a qemu machine; evanescence is a "bare-metal" AMD K6-2:
The IDT address that qemu reports doesn't match the signature of a VM. I should imagine this address could be modified to return the same result as my K6-2 does.
The emulator has complete control over the guest environment. Complete. Control. Including completely spoofing the hardware of the real host system.
This shouldn't be shocking.
I'd also like you to qualify or expound on your allegations. It's not exactly clear; what does Intel or AMD stand to gain from undetectable rootkits?
Has anybody compared the responses here to that on Digg!!!
C reates_100_Undetectable_Malware
http://www.digg.com/security/Blue_Pill_Prototype_
Kids abound on that channel. Back to Slash for me.
And what if you tried the Red Pill?
When my Karma level reaches 0 I feel in piece with the Universe
Problem: Virus / Rootkits are now so good there's no way we can detect them anymore! Reaction: Somebody has to do something about this! We need to be able to make sure something like that doesn't get installed. Solution: Trusted Computing / "Palladium" / "Fritz Chip" -- what they wanted all along. It would surprise me not one bit if the hypervisor root kit was built for people who had exactly this kind of discussion in mind.
The goal of the Pacifica technology is to do the virtualization in the hardware to avoid the need to emulate devices. Microsoft's Virtual PC product is forced to emulate a particular network card (an old Intel 10mbit card, if memory serves) and then translate usage of that network card to calls to the NT device drivers for the real network card. Under Pacifica, the virtualized system talks directly to the real network card and the hypervisor software (which runs beneath the OS kernel) co-ordinates the different OS kernels in a similar sense to how the NT kernel co-ordinates multiple applications talking to the network card.
Since the hypervisor software is essentially "an OS to run OSes on top of", if you can find a way get some software running in there you can do whatever you want with the "real" OS completely oblivious.
Please don't let Sony hear...
The worst thing is that TPM would be very effective at preventing you from removing any malicious hypervisor that might be installed, like the rootkit being discussed here. Are any exploits possible for TPM? I heard that only executable code is verified, not data, at least on the "trusted" XBox 360, which would expose all sorts of vulnerabilities. And only one would be required...
This requires them to move the host OS to a VM. Getting someone to install a trojan is getting easier but something this disruptive would be obvious to even the dumbest lamer.
Having to work for a living is the root of all evil.
A key point about virtualization (even hardware virtualization) that people miss is that it does not guarentee that programs run as they normally if those programs are timing sensitive. This isn't a new revelation. If you go back to the Popek/Goldberg paper from the 70s, they make it quite clear.
So how do you exploit this to detect that you're in a VM? If you're an operating system, the easiest approach is to disable interrupts periodically and wait out a few time slices. You would then compare wallclock time and see if you're wait took longer than you expected it should. If it did, you're being pre-empted. With interrupts off, that's a sure sign that you're in a VM.
The above is a general solution to the problem. It's funny the author used SVM (a.k.a. Pacifica). SVM has a feature called dynamic attestation. This essentially introduces an unemulatable instruction that one can use precisely for the purpose of determining whether you're in a VM or not.
### Yes, it is entertaining how many people solve the problem that "this OS gets infected" by saying, aha, we'll write another OS to watch if this OS gets infected, and never wonder, what happens when the 'another' OS gets infected.
How should that watchdog OS get infected? Its not talking to the internet the whole day, but instead doesn't do anything other then watching files. Sure, there is still a tiny tiny chance that it might get infected by some good old buffer overflow, but that is really so extremly tiny compared to the chance that a normal OS gets infected these days, that it doesn't really matter.
### Unfortunately, you are committed to looking exactly for something specific, the rootkit writer knows what you are looking for, and should be able to get by your defenses with some ridiculously bad disguise.
No, its actually very easy, just use some cryptography and sign all 'good' binaries with a private key, let the watchdog OS have the public key and check all the binaries. A rootkit can't break that check unless it breaks the encryption, which is extremly hard, almost impossible. The trick is simply to not look for a rootkit, but just anything that differs from a clean OS.
I think most people don't realize the issue.
What if lower layer based software is running below the system.
It can simply fool the hosted OS that nothing has changed, it can give you the idea to your OS that it is direclty running everything while in reality there is a lower level of control.
When your machine becomes virtualized nothing will be different to you, because all attempts by the OS to detect the environment can be fooled by this. while any interaction hardware interupt can be interupted by the viral ware to simply break in. To detect something complex like this cannt be done for 100% sure by the infected client, only by external network monitoring, still a hard job.
... you infect a guest OS in a VM with blue pill?
IF every computer had a hardwired display of the CPU :P
:P
usage, like a car has a PRM meter this would easly be detectable.
taskman shows no CPU usage, but the "RPM" equivalent is
near the red zone
also a hub or switch would be handly: taskman and/or firewall
shows no activity for network but the LEDS on the switch are in
"christmas tree" mode
virtulisation is just that:: and good virtualisation won't let you
get out of it. OBVIOUS!
if u have rights to do so, you can install ANYTHING, obviously
also virtualisation.
So the scenario described in TFA is like this:
Hardware [ Operating System ]
C:\rootkit.exe
Hardware [ Rootkit [ Operating System ] ]
But if we go back a step...
Hardware [ Hypervisor [ Operating System ] ]
VirtualC:\rootkit.exe
Hardware [ Hypervisor [ Rootkit [ Operating System ] ] ]
Then the Hypervisor can, in theory, detect the rootkit. So the obvious defense against such shenanigans is to install your own hypervisor before the bad guys do it first.
All of this is meaningless, of course, because if a piece of malware has sufficient privileges to install a hypervisor, you're already boned. Fix the privilege hole and you're as safe as you ever were.
You're thinking the only way to build a secure core is to define badness, that is to define what must be blocked.
... You have a similar problem trying to define goodness.
Actually, no. (But I am phrasing things rather carefully and your reaction is totally correct if you didn't parse everything precisely)
BUT
Carefully define everyone/everything who/how/whatever will ever befriend you during your uncertain future.
However you try, you definition of friendly will have in it something fatal.
A simple checksum on binaries -- trivial to implement in a program loader. Probably tried a few times and abandoned.
As soon as you encounter a certain type of bug, you have just ensured that the bug is unfixable, unpatchable. There is a quick and easy fix but applying it makes the system permanently unusable. (Actually makes a very effective "logic bomb";)
Running a virtual os through a security "watchdog" application, talk about security. I think im hearing the future of software security suites. Instead of installing them on your os, Macafee or Norton could make little security distros of their software, allowing for any virtualization on top of that. Wow, that would be cool.
Klingon Software is not released, it escapes, inflicting terrible damage onto the enemy as it does
He doesn't seem to realize that worms existed before 1994 and they ran on UNIX, not Windows.