Before It Bytes!

Interview with Joanna Rutkowska!

Several of our recent episodes have focused on crimeware and banking trojans.

In SecuraBit Episode 54 – Lions and Tigers and Banking Trojans, OH MY! we had Panda Security’s Sean-Paul Correll discussing Panda’s annual security report that disclosed the fact that 66% of all malware being released attempts to commit financial crime. In SecuraBit Episode 52: To catch a Mule with Krebs on Security! investigative reporter Brian Krebs (@briankrebs) discussed the Zeus banking trojan and the use of money mules to steal money. According to Shawn Henry, Assistant Director in the FBI’s Cyber Division, “More money is stolen electronically or in data breaches than through bank robberies.”

On April 7th, security researcher Joanna Rutkowska announced the development of a new high-security operating system, Qubes, that is a promising approach to addressing this problem. Joanna is well known in the security community through her presentations at security conferences around the world. Joanna was recently listed by NetworkWorld as one of the 12 “White Hat” hackers you should know. Joanna was kind enough to agree to an interview discussing Qubes.

BH: How did you get your start in security?
JR: It’s been so long ago, that I don’t remember anymore 😉
BH: After working so long with rootkits and VM compromises, why did you decide to design an OS?
JR: Well, indeed, we have done lots of offensive research over the past years, in the areas ranging from kernel rootkits, through virtualization security, and on the chipset and CPU security ending. During this time we have gathered lots of experience regarding how system software should and should *not* be built. And finally we became ready to build a system with a satisfactory level of security, I think. Also, the last year was somehow a break-through in terms of availability of some advanced hardware technologies for ordinary customers. One cannot really design and build a secure system  without a IOMMU and some trusted boot technology. Intel VT-d and Intel TXT technologies implement those two important technologies, and they have just entered shops in 2009.
BH: How long have you been working on Qubes?
JR: Over 6 months now. The first 2-3 months were mostly spend on designing the architecture, the rest on coding.
BH: How did you come up with the name Qubes?
JR: Oh, I though it was pretty obvious. “Qubes” is just a fancy way of writing “Cubes”, and each “cube” is supped to symbolize a Virtual Machine (VM). When we think about a Virtual Machine in security, we think about some kind of a cage, or a cube, something that is capable of containing and jailing whatever is inside (e.g. a malicious program).
BH: Can you briefly describe the goals of Qubes?
JR: To provide strong security for desktop computing by implementing “Security by Isolation” principle in an effective and easy-to-use way. My goal with Qubes is to make it useable not only by Linux geeks, but also by people like lawyers, doctors, businesspeople, and anybody who is concerned about potential compromise of their data.
BH: You mentioned using “security by isolation” as being superior to “security by obsecurity” or “security by correctness”    Can these approaches be combined?
JR: Actually, we always need “Security by Correctness” — there are always some elements in any system that must be flawless in order to manage and secure the rest of the system. But an attempt to apply the “Security by Correctness” approach to the whole system, including Web browsers, PDF readers, etc, is simply not reasonable. We won’t be able to find and patch all the bugs in all our applications anytime in foreseeable future. It is simply naive thinking. So, instead, we designed Qubes to minimize the number of elements in the system that we need to trust, i.e. those where we need “Security by Correctness”. The potential attack surface in Qubes is orders of magnitude smaller than in a typical mainstream OS like Windows, Linux or Mac OS X.
BH: What functionality has been the most difficutlt to design?
JR: That would be the GUI virtualization. In Qubes we wanted to provide seamless integration of all the user’s applications on one desktop, just like if all the applications were executing natively. But, of course, they all run in different VMs. The obvious solution would be to let all the applications to connect to one common X server so it could present them all on one desktop. But that would be a very bad security decision, because the X protocol is very complex, and I bet there are dozens of ways to exploit it. So, we had to create a special GUI daemon and a protocol to extract the application’s, so called, composition buffers from each VM’s private X server, and bring them all and display on the common desktop in Dom0. The protocol we implemented for this is extremely simple — just a few messages, compared to hundreds or thousands of complex messages in case of a regular X protocol. At the same time our GUI implementation turned out to be very efficient, so that it’s perfectly possible to e.g. watch fullscreen movies running in AppVMs. The GUI daemon is one of those few elements of the system that we must absolutely trust and that we hope are flawless (the GUI daemon itself counts some 2,000 Lines of Code). If an attacker found an exploitable bug in our GUI daemon, then they would be able to compromise the whole system.
BH: Several leading regulatory agencies have suggested using Live CD’s for conducting high-risk  financial transactions. Do you think Qubes could be used in this way, or is it an alternative approach?
JR: And how often are they advised to reboot the system? Every day? Every 1 hour? Or perhaps every 5 minutes? 😉 Still, they cannot prevent more advanced attacks, e.g. persistent BIOS infections [our team has recently showed it was possible to infect one of the most secure BIOS: the Intel vPro BIOS — see this link The whole idea behind Qubes is that you would not need to use such childish and annoying tricks.
BH: Is there a limit to how many ApplicationVM’s can be created?
JR: Yes, it is dictated by the amount of RAM your machine has. With 4GB RAM you should be able to run 7-10 VMs, depending on how much memory you assign to each VM (e.g. AppVMs for less demanding tasks might be assigned only 100 or 200 MB, while those used for Web browsing, running office apps, etc, would need some 400 MB; you also need to leave some 700 MB for your Dom0). We’re definitely planning to look into optimizing per-VM memory memory footprint in future versions, although if you have 4GB of RAM that’s pretty much enough for most usage cases even with current implementation. Please note that Qubes already optimizes disk usage for AppVMs — thanks to smart filesystem sharing, each AppVM takes only as much disk space, as needed for string its private data (e.g. user files). One side effect of this efficient filesystem sharing is the ability to automatically update software (e.g. Web browsers) in all the AppVMs all at once, which is extremely useful in practice.
BH: Do you plan to use content based page sharing to reduce memory footprint?
JR: This is currently a subject for further research.
BH: Do you plan to have application white listing within the ApplicationVMs?
JR: That’s certainly possible.
BH: In your architecture document you mention Firewalling ports in/out per VM. Do you think the complexity of doing this will restrict the acceptance of the OS?
JR: First, this is just an optional feature for the more demanding users. Also, we plan to provide pre-configured setups in the future, and perhaps also some management tools that would make more advanced setups much easier for non-technical users.
BH: You mention that the network stack is untrusted since you are using end-to-end encryption from within the ApplicationVM. Would protocol attacks such as certificate attacks or DNS poisoning be problematic?
JR: When we consider attacks on network protocols, then there is no difference if the attacker runs the exploits over WiFi, sitting in the adjacent hotel room or in the same lounge at the airport vs. if the attacker has compromised the NetVM. The opportunities are equal. If SSL or SSH is broken, you do have troubles, no matter if the NetVM is compromised or not.
BH: When do you expect Qubes to leave Alpha?
JR: Most likely at the end of summer holidays.
BH: What types of commercial extensions do you envision?
JR: One example would be support for running Windows-based AppVMs. Another example would be, as previously mentioned, various tools that would help to configure and setup Qubes deployments, especially in corporate environments.
BH: What can the community do to help?
JR: We have wiki with many information about the project, including how people can contribute:
BH: Thank you for taking the time for this interview. We look forward to watching the progress of this new operating system.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.