Story continued from Page 1
Nate Lawson: Just to note, the actual implementation of one method from each of those 3 categories took about 2 weeks total of Tom and my spare time. Our key finding is that it will always be easier to detect a (hypervisor) rootkit than it is to write perfect cloaking code for one.
When you have a choice, it's always better to be on the side where software bugs benefit your goals. Our code is minimal and is less than 1000 LoC while New Blue Pill is about 7000 LoC. Adding support for hiding from our particular set of checks would increase the size of NBP even more. More code would mean more of a target for us to look for in the future. That's why we were confident in issuing the challenge.
Is there anything that hardware (not only cpus) manufacturers could do to improve security, or at least reduce the impact of virtualized malware?
Thomas Ptacek: I don't think virtualized malware is a hardware problem, any more than I think kernel malware is a hardware problem with protected memory. So far, the real-world impact of virtualized malware has been nil.
What about virtualization features included in modern cpus?
Thomas Ptacek: The reason so much attention is being paid to on-chip virtualization in X86 CPUs is that it's novel, and so it's fun to talk about. But the only reason it's a viable target for rootkit authors is that nobody is using it yet. Five years from now, everyone's desktop operating system will be virtualized by default; rootkits won't have any opportunity to load themselves into hypervisors directly, because there will already be a hypervisor present, and it won't want to share.
What's funny is, you could have made the same argument about protected memory, the chip feature that allows us to safely run a web server and a web browser on the same machine at the same time. If your operating system didn't configure and use the CPU's protected memory features, attackers would do it instead. But of course, no mainstream OS ignores protected memory, and soon no mainstream OS will ignore virtualization.
From a security standpoint, do you see any difference between AMD and Intel cpus virtualization features?
Thomas Ptacek: There are differences between AMD and Intel hardware, and those differences affect the way rootkit authors and rootkit detectors have to write their code. You can also make the argument that some versions of AMD's hardware are faster at virtualization today than other versions of Intel; tomorrow, the opposite will be true. But none of this matters to the debate; as Joanna demonstrated in her talk, with a little tweaking, the ideas our team came up with work just as well on AMD as on Intel.
Do you see a different scenario on other architectures that support virtualization?
Thomas Ptacek: Virtualization on exotic processors is much more closely tied to the hardware vendor's own software offerings (for instance, the PowerPC's virtualization was designed for the LPAR functionality in mainframe operating systems). People don't buy Sun SPARC hardware to run Linux on it; they buy it to run Solaris. These systems often already have hypervisor code running, and aren't good targets for virtualized malware.
What is your opinion on the security of software virtualization solutions (VMWare, Xen, VirtualPC, ...)?
Thomas Ptacek: I can't speak for the three of us on this: if you asked us individually I think you'd get three different answers. What I can say is that interesting research is being done into this; one of the best recent papers is from Tavis Ormandy at Google [PDF].
Tavis found a variety of ways that code running inside of a "guest" virtual machine could potentially disrupt or even hijack the host operating system.
Since ISPs are selling so-called VPS (virtual private servers) running on different types of virtualization software, I was wondering if you had any advice about choosing one.
Thomas Ptacek: While new vulnerabilities will always continue to be revealed in virtualization software, I'm confident and optimistic about virtualization. If you're in the market for a "virtual server", you are better off with a Xen or VMWare virtual machine than you are with a classical virtual host, where you share a single running operating system with many other customers.
I don't have any recommendation to make between VMWare and Xen; both are high-quality offerings. As both mature, they look more and more like each other, despite Xen's original distinction of using "paravirtualization".
Two things I would keep in mind if I was running sensitive applications on a virtual server:
- Researchers will continue to find "guest hopping" vulnerabilities that allow code in one guest machine to hijack other guests, or the hypervisor itself. So far, these findings have been rare, but they do happen. If your hosting provider is vulnerable to one of these attacks, an attacker can buy a cheap account with them and hijack your server.
- Many of the techniques we used to detect Blue Pill were inspired by techniques that cryptanalysts use to steal cryptographic secrets. On a virtual server, attackers can use these techniques not only to figure out what kind of hypervisor is running, but also potentially to steal cryptographic keys. Be cautious about deploying cryptographic software on virtual hosts.
I think readers might be interested in possible or future use of virtualization for defensive aims, such as using "blue pill" for invisible intrusion detection or antivirus processes.
Thomas Ptacek: Secure virtual machines are a key part of Intel's security strategy. Right now, security software has to trust the running operating system. If something goes wrong with the Windows kernel, security software isn't protected. In the future, as Intel sees it, security software will run above the operating system; even if you lose the kernel, your security code is still protected by a virtual machine boundary.
I think everyone would object to calling those "Blue Pills"; secure virtual machines predate Blue Pill, and are not themselves rootkits.