Faceoff: AMD vs. Joanna Rutkowska
|
AMD: A user's operating system must first be compromised at the kernel level in order for malware to leverage hardware virtualization features.
Rutkowska: That is obvious and I have never claimed anything else. The point is -- once the system is compromised, the hardware virtualization technology, such as AMD SVM or Intel VT-x, can be abused by an attacker and allow for creation of stealth malware characterized by *unprecedented* level of stealth.
AMD: And, virtualization-based malware attacks are entirely possible in machines that do not support hardware virtualization features.
Rutkowska: Even though software-virtualization-based malware for x86 architecture has indeed been demonstrated (SubVirt created by Microsoft Research), such malware is far easier to detect (and far less harmful) than hardware-virtualization-based malware, like, e.g., Blue Pill. There are many reasons for that, one of them being that it's trivial to detect [the] presence of the software-based hypervisors on x86 architecture due to its design "flaws" (see my 'redpill' proof-of-concept program).
Also, nobody demonstrated that such software-virtualization-based malware can be installed on the fly, i.e. without restarting the system. Finally, the creation of software-based hypervisors is a very complex task, as it requires implementation of binary translation (BT) or [an] other form of emulation of the kernel mode code execution. Thus the presented malware was based on commercial VMMs, like VMWare or Virtual PC, which made it
trivially detectable and of no practical use at all. On the other hand, the hardware-virtualization-based malware, like Blue Pill, does not suffer from any of the above-mentioned problems.
AMD: [Our] processors are no more vulnerable to malware than those of any other x86 processor vendor.
Rutkowska: Processors supporting hardware virtualization do allow for creation of completely new class of malware (after attacker gains access to the kernel, of course). Such malware can take control over the system without changing even a single byte inside system code or data and without introducing any OS-visible changes into processor registers (assuming that the OS doesn't implement its own hypervisor, which is true for all major operating systems today). This is a very important difference [when] comparing to the other malware, as, by definition, such malware can not be detected by any memory-based scanner (system integrity checker, forensic analysis of physical memory dump, etc.).
AMD: Once an operating system is compromised, any attack is possible, with the theoretical 'Blue Pill' being just one extremely complex example. We believe it is critical that users implement industry best practices in securing their operating systems, including the use of preventative malware detection tools, maintaining [the] latest security patches, and implementing the appropriate levels of firewall and other network isolation technologies.
Rutkowska: But, as life shows, those above-mentioned "industry best practices" have proved to be inefficient and have been bypassed many times in the past. We have observed a lot of attacks which allowed an attacker to get access to the target system's kernel. The point is -- once the attacker gets access to kernel, then he or she can abuse the hardware virtualization technology, so that we can have big troubles detecting that the incident even occurred. This is very disturbing in my opinion.

In response to my

Comments (27)
If what Joanna says is true, then the $64,000 followup question begs to be asked.
Can an attacker gain control of the kernal without being detected? If this is a widely successful practice in the 'hacker' world, then we could be in for a lot of pain.
Posted by duquane | November 14, 2006 2:04 PM
Nice job eWEEK, I'm sure your "Faceoff: AMD vs. Joanna Rutkowska" article has enlightened many people on the issue or non-issue of hardware based virtual rootkits. On second thought, maybe pitting a junior-level PR hack against a leading researcher was a waste of time. Seriously, what is the purpose of having Rutkowska respond to "virtualization-based malware attacks are entirely possible in machines that do not support hardware virtualization features" and "[Our] processors are no more vulnerable to malware than those of any other x86 processor vendor". Is your source at AMD even vaguely familiar with Rutkowska's research?
Posted by Anonymous | November 14, 2006 2:07 PM
Every time I read about this virtualization vulnerability, I find myself wondering 2 things:
1) Does Ms. Rutkowska have any suggestions for a solution which doesn't slam the door on hardware (i.e., higher-performance) virtualization?
2) Are similar exploits not possible on the newer Intel CPUs?
Posted by Bill Clardy | November 14, 2006 3:28 PM
I think what we should be looking at is not how to hang Ms. Rutkowska but more in depth at what she has presented. Setting up deniability seems to be the sure fire way to get away from bad PR however it also permanetly opens the expanse of vulnerability.
Posted by Tiger Tolles | November 14, 2006 4:04 PM
Not only is she smart, she's HOT!
Posted by dumb terminal | November 14, 2006 4:08 PM
Ok. Does Ms. Rutkowska have any suggestions to correct the problem???
Posted by stan | November 14, 2006 4:39 PM
In her response Ms. Rutkowska states, "Such malware can take control over the system without changing even a single byte inside system code or data and without introducing any OS-visible changes into processor registers (assuming that the OS doesn't implement its own hypervisor, which is true for all major operating systems today)." Doesn't this sort of imply that a possible approach is to have the OS "implement its own hypervisor", or am I missing something obvious? I'm not competent to even begin coding a hypervisor, but I would imagine that there are at least a few people out there who are capable of doing this. At least it seems that investigating the potential of such an approach would be more useful than trash mouthing someone who obviously is that capable.
Posted by Gary Lee | November 14, 2006 5:16 PM
Rutkowska's parenthetical approach to defeating blue pill (implementing a hypervisor to catch a hypervisor) is the exact approach taken by IBM in the late 1960's and early 1970's with regard to the VM/360 and VM/370 operating systems. The root hypervisor (just as blue pill would if it had a chance) virtualizes the hardware virtual machine, virtual memory, and I/O instruction sets. Once that has been performed, that virtual hypervisor is as invisible as Blue Pill could be, and can detect and defeat Blue Pill itself. Note that the hypervisor must be implemented as another operating system which always boots first, so that it can protect its disk image and hypervisorial command set.
While Rutkowska's method shows she's a good coder, and can spin a good story, the means to defeat blue pill has been known for nearly 40 years.
Posted by unclesmrgol | November 14, 2006 5:50 PM
Once again, by publicizing this, she has alerted potential hackers to the vulnerability potential.
I wish that the "White Hat" researchers would make it policy to report such findings more discreetly.
As to the possibility that such a vulnerability might have been noticed by the hacker community without this public disclosure, it may be comforting to think that the hacker community is lazy and not too inclined to do their own research, but I suspect there is a class of "Super-hackers" out there who have already determined that such an exploit might be possible.
In particular, foreign national intelligence agencies, political activist groups and some organized crime groups are always analyzing every public specification for possible vulnerablities.
While it may be true that no one had thought to attack this vector, it is only a matter of time before any new technology gets inspected by those looking to subvert it.
If there were a national software intelligence clearinghouse, these issues might be raised privately among those in charge of protecting the public interest. As the hardware/OS/Application landscape continues to evolve, more such scenarios will be created.
I urge all interested parties to raise these issues with national leaders, with the goal of actually empowering the National Infrastructure Protection Center and US-CERT (http://www.us-cert.gov/) by promoting the activities of these agencies and providing them sufficient funding.
Otherwise, we will likely all wake up some day to a virus/worm/rootkit exploit that trumps everything and no one's secrets will be secret anymore...
Posted by John Rosengarten | November 14, 2006 6:41 PM
After reading all of these comments, I glean the following worthwhile information:
IBM mainframe OS/es under the "hypervisor" of VMS and it's I/O channel architecture may have combined to provide such safety, however, back then, you had to hack into machine via dial-up, and one of the easy fixes to hackers was to have the modem dial back to connect.
Any lock can be picked, hence Ms. Rutkowska is right and wrong for making such a fuss since the difference between ethical hacking and what malware, virus, and worm writers are about is how discretely they find and get the problem fixed. No drum roll or fanfare required.
Discretion should always be used, and directed to those that need to fix the problem, not to the publications taht are read by every hacker worth their bytes in gold.
Perhaps AMD (and Intel) should reward Ms. Rutkowska when she brings a problem to theiir attention and shows them how. Of course if she can also fix the problem too, I am definitely for her being rewarded. And we never need to know about any of it. But since it is via the OS that hackers gain entry (most of the time) then it would seem only fair that Microsoft pony up some of that "reward" money also.
If all of these problems exsist, how does McAfee, Symantec, et al, stay in business and why are we still buying their products? Perhaps Ms. Rutkowska could start her own Anti-virus, Anti-Malware, Anti-Spyware product line.
If there is nothing we can do about it, then I'll start saving in the mattress instead of the bank. And drive 100 miles so I don't have to use a credit card online.
And finally I learned that Ms. Rutkowska is HOT. At my age, there are many more hot women than there were when I was half my age. Is that just population increase?
Posted by Fred M | November 14, 2006 9:41 PM
I remember when viruses used to attack the boot sector and hide themselves on IPL. I imagine all modern PCs contain BIOSes that, by default, write protect the boot sector. It is not possible for a virus to reprogram my BIOS, nor to interrupt it before it has write protected the boot sector (unless I needlessly cache my BIOS in RAM).
I expect that motherboards supporting CPUs with built-in virtualization support will take a similar approach and load a ROM-based, unalterable hypervisor that, in turn, loads a designated successor hypervisor whose replacement can only occur with high visibility (just as replacing the boot sector is something the user is not going to miss).
Posted by Bob White | November 14, 2006 10:10 PM
Hanging Ms.Joanna Rutkowska for sharing her research is akin to shooting the messenger. Those who engage in such practice deserve what comes to them.
AMD is definitely crapping their pants with this little PR circus. Even Microsoft would have responded in a less self-centric way to this genuine concern.
I'm very happy that she brought this issue right before HW virtualization becomes a commodity. Another researcher is also giving hell to RFID as used for people, for the same reckless disregard for security (and, in that case, privacy).
Like it or not, either these corporations give some serious thought to security, like Microsoft actually started doing in recent years, or they will end up assembling half a Trojan Horse into their solutions (the other half provided for free by hackers, thank you very much).
Atta girls!!!!
Posted by Alex | November 14, 2006 10:43 PM
"Rutkowska: That is obvious and I have never claimed anything else. The point is - once the system is compromised, the hardware virtualization technology, such as AMD SVM or Intel VT-x,..."
At LEAST she mentions Intel, I was having sentiments of her being hired by Intel for a while, since she was seemingly only slamming AMD's virtualization.
It is disturbing to the nth degree to have a machine compromised to a level where the kernal can be subverted.
The solution, as she has mentioned in other articles, is to have a hypervisor loaded already.
Now, we can only hope that such initiatives to implement a pre-emptive hypervisor are started, fully supported, continually refined and completed post haste!
Of course, all this and no performance hit, thanks!
Intentsly
Posted by intentsly | November 14, 2006 11:09 PM
Is virtualization useful for desktops running some spreadsheet program? Or should I avoid it? Which approach is safer, Intel or AMD?
Posted by Pragmatic Buyer | November 15, 2006 12:55 AM
So much posturing, so little help. There is an EASY SOLUTION. If you are not using Intel VT or AMD SVM because you are not using virtualization. Turn the damn feature off. It's a FREAKING BIOS setting. Yes, it's that easy. Once these features are disabled through the BIOS, they can't be re-enabled without rebooting the system.
Problem solved.
While I appreciate Mrs. Rutkowska pointing out this potential issue, I'm getting tired of reading that the sky is falling every few weeks from her when some new hack needs a sensationalistic headline.
Posted by Rob S. | November 15, 2006 1:52 AM
JUST DO IT!
Posted by Jeffrey M. Larson | November 15, 2006 2:14 AM
Redpill is still referenced in *this* article. Strange after I have published my brief research paper 10 days ago: "Redpill getting colorless?".
Especially since there are indicators that Ms. Rutkowska is aware of the facts stated in my paper (e.g. her SVV uses kernel mode to retrieve the IDTR contents).
http://blog.assarbad.net/20061105/redpill-getting-colorless/
Any comments from Ms. Rutkowska on that?!
// Oliver
Posted by Oliver | November 15, 2006 7:56 AM
Now let's comment some of the statements.
But, as life shows, those above mentioned "industry best practices" have proved to be inefficient and have been bypassed many times in the past.Targeted attacks by skilled attackers will most likely remain a problem until the inherently unsecure system architecture is replaced by a better one. Let's take Windows where many users run their system with admin privileges for obvious and understandable reasons (even debug privileges are questionable from the security perspective): the fact that admin has the right to elevate code into the TCB is enough alone to put the whole system at risk. There is not much anyone could do about except for rigid security policies (e.g. in companies).
We have observed a lot of attacks which allowed an attacker to get access to the target system's kernel.... which are either inherent to the system architecture or flaws. Since Ms. Rutkowska writes software herself she has to be aware of the fact that bugs are an inherent problem of every piece of software.
The point is - once the attacker gets access to kernel, then he or she can abuse the hardware virtualization technology, so that we can have big troubles detecting that the incident even occurred. This is very disturbing in my opinion.There is no 100% reliable method to detect "conventional" rootkits. And if there was it would not mean that it is usable for generic removal. So what *is* the point of Ms. Rutkowska here? If I was an attacker and I was not hired for a large sum of money I'd not go to such lengths as creating a bluepill-like rootkit if the "conventional" performs sufficiently well on most systems ...
But still, the problem has been recognized by the security industry and will be addressed in one way or another ...
// Oliver
Posted by Oliver | November 15, 2006 8:12 AM
Two key actions to defeat most malware:
(1) Data is data and can not be executed. The execute disable property on data regions must be employed 100% of the time. [Defeats buffer overflow and similar exploits]
(2) Code can not be changed. No, don't just set the write-disable property of the memory region, execute the code from a read-only source. (Whenever the source of the code is a rewriteable medium, someone can always find a way to change it).
Is (2) practical at this time? No
The Windows CE model, wherein code is upgraded through ROM changes will need to be adopted for kernel (Ring 0) and virtualization (Ring -1) functionality.
Flexibility in revision of code for patching and upgrading will be traded for predictability and confidence in behavior.
[Secure ROM creation and distribution would be a cottage industry. The Microsoft monthly patch cycle is incompatible with the ROM scheme.]
Posted by Bruce Maier | November 15, 2006 9:40 AM
Joanna Rutkowska should be taken very seriously, since she is not alone in performing this
type of research. But, the only countermeasure we
could possibly think of when dealing with the potential attacks this revelation suggest is isolating the sensitive from the not so sensitive information. Furthermore, creating counter power
failure to overt attacks and loss of information,
even when the computer (x86) has been compromised.
Posted by C. Henry & BIE | November 15, 2006 11:22 AM
Perhaps hardware virtualization is not quite ready for prime time yet? Obviously there are some safety nets that will need to be in place before large scale deployment of this technology. Without these safety measures, this is like handing bombs to the enemy and not expecting them to use them!
Posted by Anonymous | November 15, 2006 12:09 PM
Perhaps hardware virtualization is not quite ready for prime time yet? Obviously there are some safety nets that will need to be in place before large scale deployment of this technology. Without these safety measures, this is like handing bombs to the enemy and not expecting them to use them!
Posted by Anonymous | November 15, 2006 12:10 PM
Perhaps hardware virtualization is not quite ready for prime time yet? Obviously there are some safety nets that will need to be in place before large scale deployment of this technology. Without these safety measures, this is like handing bombs to the enemy and not expecting them to use them!
Posted by Anonymous | November 15, 2006 12:15 PM
The only secure computer is in a room with no doors and no power, and of no use to anyone.
I'm thankful for all Ms.Rutkowska's efforts. Without folks like herself, everything WOULD be on the hush hush and while Mr. Putin may feel quite comfortable with that, I certainly do not.
As to those who ask why Ms.Rutkowska is not proposing a solution instead of just pointing out the vulnerabilities... I look forward to reading their solutions, and ask them, given that Ms.Rutkowska has no vested interest in any of the firms enabling the vulnerabilities in the first place, why should she spend her time fixing their problems?
Posted by RobV | November 15, 2006 12:27 PM
Can this be detected... Yes - a performance monitoring application would detect that a benchmark was reporting slower execution.
It was proposed back in the Novell days when Netware was allowing multiple NLM's to run on a Multi-CPU server.
The monitor would report a simple check of the processes and how long the OS idle was running.
I know this method is used in Unix and MVS, VM and all other proprietary OSes. The software community should develop the body of work and build of the past works instead of cursing the darkeness.
IBM, CA, Intel, AMD, Oracle, Red Hat, Novell, Borland and Microsoft can easily comment on this and publish a coherent response for us to review on this as I just did. This is my quick list not exclusive nor extensive.
Posted by Chris Hamilton | November 15, 2006 1:31 PM
Why all the fuss? Nothing has changed. Cyber warfare continues as before. The never-ending race to stay one step ahead of the bad guys continues.
The advocates of hardware virtualization have made unrealistic claims. That is the only substance to this entire episode. But nothing has really changed.
Those saying it can't be cracked are not to be believed. Those saying the crack can't be detected and countered are also engaging in hyperbole. This is the song that never ends.
Posted by David Sadler | November 15, 2006 1:42 PM
Another hypervisor that is quite stable and well-supported is Xen, based on the Linux kernel. This also has the benefit of being Linux, and therefore (a) (arguably) more secure, (b) free, and (c) extremely flexible.
If Linux can fit into a 32MB phone, why not implement it as a minimal universal hypervisor? Then one could use any operating system as a domU (Unprivileged OS) while the dom0 (root OS) remains locked up VERY tightly. This has the added benefit of making the whole bootloader thing much simpler.
Posted by Alex Elsayed | November 28, 2006 7:39 AM