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?
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
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
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.
"Is this testing whether I'm a virtual machine or a lesbian, Mr. Dowd?"
There are no trails. There are no trees out here.
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."
No, the solution is to not give the malware the path to even be able to do this by using a capability-type system.
Please, for the good of Humanity, vote Obama.
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...
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
Can we use this to bypass the DRM included in Vista?
In Soviet Russia the insensitive clod is YOU!
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.
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.
I don't think they realised the 'small details' they would be impacting. For instance, before the 'upgrade' if the network went down, we could write some letters, work on some spreadsheets etc... Now with the new 'upgrade', if the network goes down, we can't do anything. Not even write a letter, send an email, none of that stuff....
:P
Yes, gone are the wonderful days of yore when one used to be able to pass the time while the network was down by "sending an email."
Uttering logically derived and empirically supported truths to the disciples of the orthodox establishment.
You just think you're booting off that DVD.
As always, all IMO. Insert "I think" everywhere grammatically possible.
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.
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.
...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).All those utilities people pay so much for are worthless! They only detect the known malware, but nobody knows about the undetected hacks.
One area of active reasearch in intrusion detection looks at detecting malware by examining the behavior of applications. The behavior patterns (network connections, system calls, file accesses, etc.) of a program can be compared against a list of known-bad actions. If a program acts like malware, it's malware, regardless of how what vulnerability (known or unknown) compromised it.
Also, it is possible for some programs to detect when a specific vulnerability is triggered and take preventative action. This will stop previously-unseen exploits from using an established vulnerability to compromise a system. Still, the vulnerability must be discovered first for this to work.
An technique called anomaly detection seeks to get around this limitation by building a profile of "normal" behavior for a program and flagging any deviant behavior. This still can't catch all malware, since the malware could have the infected application act within its normal boundaries, but it does severely limit what malware can do with a hijacked process. Hopefully, the malware is limited enough that it can't really harm the system.
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...
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.