Qubes 2 Beta 1 with initial Windows support has been released!

It's my pleasure to announce the first Beta for Qubes Release 2 is now available for download.

This release introduces generic support for fully virtualized AppVMs (called HVMs in Xen parlance), and specifically initial support for Windows-based AppVMs integration. It's been quite a challenge to add support for secure HVMs to Qubes without breaking its security architecture, and I already wrote about it in the past.

Generic support for HVMs means you can now install many different OSes as Qubes VMs, such as various Linux distros, BSD systems, and, of course, Windows. Essentially all you need is an installation ISO and the whole process is similar to creating a VM in a program like Virtual Box or VMWare Workstation (although we believe the underlying architecture for this is more secure in Qubes).

Additionally we provide a set of tools for Windows-based AppVMs (Windows 7 specifically) which allow for tight integration with the rest of the Qubes system. This currently includes support for secure (and policy controllable) clipboard and file exchanges between the Windows-based AppVMs and other AppVMs, integration with Qubes advanced networking infrastructure, and PV drivers for faster operation. As of now there is still no seamless app integration for Windows applications, so Windows VMs are presented as full-desktop-within-a-window, but we're aiming to add support for this in the next Betas.

Unlike the rest of Qubes, which is distributed under a GPL v2 license, the Qubes Windows Support Tools are not open sourced and are distributed as binaries only, under a proprietary license. They are free to use for any Qubes 2 user. The tools are not part of the Qubes 2 installation ISO (which is GPL), and are down loadable on demand.

More information about creating and using HVM domains, including Windows-based AppVMs, can be found in the wiki here.

To summary, here's a quick list of some of the exciting new features that toady's release brings in:

• Support for generic fully virtualized VMs (without qemu in the TCB!)
• Support for Windows-based AppVMs integration (clipboard, file exchange, qrexec, pv drivers)
• Secure audio input to select AppVMs (Hello Skype users!)
• Clipboard is now also controlled by central policies, unified with other qrexec policies.
• Out of the box TorVM support
• Experimental support for PVUSB
• Updated Xorg packages in Dom0 to support new GPUs
• DisposableVM customization support
• ... and, as usual, various fixes and other improvements :)

Existing users of Qubes R1 can upgrade without needing to reinstall – the upgrade procedure is described here. Standard installation is described here.

Enjoy!

PS. Please send all the technical questions to the qubes-devel mailing list, instead posting them as comments to this blog. Keep the comments here for more generic discussions.

PS2. As usual, I would like to remind that we have little control over the servers that are used for Qubes ISO distributions and that the downloads should be verified according to the procedure described here. We always assume that even our own servers (git, wiki, yum) could be compromised, and yet this should not affect Qubes security in any way, because of the extensive use of digital signatures everywhere in the development and distribution process.

How is Qubes OS different from...

Many people ask how does Qubes OS differ from other approaches to desktop security. Today I'm trying to answer the most popular questions.

• Why bother with Qubes OS, if any Linux/BSD already allows to setup different user accounts, or some form of light-weight containers or sandboxes, such as chroot, LXC, SELinux?

First, if you use Xorg or similar X-based server as your GUI server, and this is what nearly all Linux, and most of the other non-Windows OSes use, then you don't have any form of GUI-level isolation, which is essential for a desktop system. I wrote more about this surprising problem some time ago. Proper GUI-level isolation was one of the main goals for Qubes.

Second, all mainstream desktop OSes, such as Windows, Linux, BSD, even OSX, are all based on a monolithic kernels, which present a significant security problem. This is because a typical monolithic kernel of a contemporary desktop OS contains tens of millions of lines of code, and to make it worse, most of this code is reachable from (untrusted) applications via all sorts of APIs, making the attack surface on the kernel huge. And it requires just one successful kernel exploit to own the whole system, bypassing any security mechanisms that might have been built on top of it, such as SELinux, LXC, etc.

Additionally, all the various drivers, networking and USB stacks, are also hosted in the kernel, making attacks via buggy networking (e.g. via buggy 802.11 stacks or buggy firmware) or USB stacks a practical possibility. And there is essentially nothing one can do about it, when using an OS based on a monolithic kernel.

In Qubes, on the other hand, we use Xen hypervisor to provide security isolation between domains, and Xen is just a few hundred of thousands lines of code. It also doesn't need to provide all sorts of APIs to applications, because the Xen hypervisor is essentially only interested in CPU scheduling, memory management and power management, and very few things beyond that. Most notably, the Xen hypervisor knows nothing about networking, disk storage, filesystems, USB stacks, etc, as all those tasks are delegated to (often untrusted) service VMs.

• How is Qubes better than just running a bunch of VMs in VMWare or Virtual Box?

First, products such as VMWare Workstation or Fusion, or Virtual Box, are all examples of type II hypervisors (sometimes called “hosted VMMs”), which means that they run inside a normal OS, such as Windows, as ordinary processes and/or kernel modules. This means that they use the OS-provided services for all sorts of things, from networking, USB stacks, to graphics output and keyboard and mouse input, which in turn implies they can be only as secure as the hosting OS is. If the hosting OS got compromised, perhaps via a bug in its DHCP client, or USB driver, then it is a game over, also for all your VMs.

Second, those popular consumer type II VMM systems have not been designed with security as a primary goal. Instead, their main focus has been on easy of use, performance, and providing seamless integration of the guest OS(es) with the host OS. Especially the latter, which involves lack of good method to identify which domain a given application belongs to (so, lack of trusted Window Manager), support for shared clipboards which every other VM can steal, insecure file sharing methods, and others, all make it not a very desirable solution when strong domain isolation is important. (This is not to imply that Qubes doesn't support clipboard or file sharing between domains, it does – it's just that we do it in a secure way, at least so we believe). On the other hand, there are many usability improvements in Qubes that are specific to multi-domain system, and which you won't find in the above mentioned products, such as trusted Window Manager that, while maintaining great seamless integration of all the applications onto a common desktop, still allows the user to always know which domain owns which window, support for advanced networking setups, per-domain policies, the just mentioned secure mechanisms for clipboard and filesystem sharing, and many other. Qubes also focuses on making the VMs light-weight so that it was possible to run really a lot of them at the same time, and also on mechanism to allow for secure filesystem sharing between domains (templates).

Finally, the commercial hosted VMMs are really bloated pieces of code. They support everything and the kitchen sink (e.g. Open GL exposed to VMs, and various additional interfaces to allow e.g. drag and drop of files to/from the VM), and so, the attack surface on such a VMM system is orders of magnitude bigger than in case of Qubes OS.

• How does Qubes compare to [your favourite academic microkernel]? 

While the Xen hypervisor can indeed be considered a microkernel if you're not a strict terminology freak, Qubes itself is much more than just the hypervisor. Qubes is everything that is needed to build a reasonably secure desktop OS on top of a baremetal hypervisor (or microkernel). Theoretically, with just a few cosmetic changes (at least architecture-wise), Qubes could perhaps swap the Xen hypervisor for some other hypervisor or microkernel, such as perhaps Hyper-V, KVM, or some more exotic one. Thus, it makes little sense to compare Qubes with a hypervisor or microkernel project. What makes sense is to compare the Xen hypervisor, as used in Qubes, with some other hypervisor or microkernel.

Ok, so how does Xen compare with other hypervisors or microkernels out there? We think Xen is unique because it combines an elegant architecture (type I, baremetal, hypervisor) with a number of practical features, such as power management, support for Intel VT-d and driver domains, support for both para-virtualizaed, and fully-virtualized VMs, and many more, not found in e.g. academic microkernels/hypervisor projects, that otherwise seem attractive from the architecture point of view.

• How is Qubes better than Google Chrome OS?

 First, Chrome OS is not a general purpose OS. Second, it's based on Linux with all its security limitation that are a result of using a monolithic kernel described above (e.g. all the networking and USB stacks in the kernel without a possibility to deprivilige them). Not being a traditional general purpose OS, Chrome is able to avoid many of the challenges of desktop computing, such as the need to define security domains, inter-domain file exchange (as there is essentially no filesystem visible to the user), and others, which is good, of course. But then again, Chrome OS is essentially just an environment to run the Chrome Browser, so the comparison to Qubes is a bit of a misunderstanding.

Technical aspects aside, there is always the privacy concern associated with running everything in a browser – why would all my private data be managed and accessible to some 3rd party organizations and their administrators?

• How is Qubes better than [your favorite commercial military-grade certified secure OS]?

You must have heard about the super secure military-grade, formally verified, 100% certified, and generally “unbreakable” operating systems made by companies such as Green Hills, Lynx Works, and others. How do they compare to Qubes OS?

Really, I have no idea. For a mere mortal like myself (and perhaps not a US citizen), it seems impossible to get any more technical documentation of those systems (anything beyond the marketing pseudo-technical gibberish), not to mention a trial copy to play with...

Thus, from my point of view, those systems are just a vaporware. If you, my dear reader, are privileged enough to have access to such system, then good for you, but don't expect me to treat seriously a security product that is not available for a wider audience to touch and play with... (And the Chineese surely have the copies already to play with ;)

• How is Qubes different than Bromium's “micro virtualization” solution?

Many people asked recently about the Bromium's upcoming product and how it differs from Qubes OS. Unfortunately there are few public information available on this product – essentially there is one not-very-technical whitepaper and there are Ian Pratt's presentation slides from the recent XenSummit about u-Xen, apparently a hypervisor that is to be ultimately used in their upcoming product.

The whitepaper suggests that Bromium is based on a hosted (type II) hypervisor running within a normal Window OS, and that this hypervisor is used to spawn a new “micro VM” for each new “task”, where apparently the task might be something as granular as opening a new tab in a Web browser, which makes it somehow similar to Google Chrome's approach. Clearly, the Bromium's main goal seem to be to automate the process of creating separation domains, which is in contrast with what we do on Qubes OS, where the user is required to define the domains explicitly.

The Pratt's slides provide also some technical insight into how Bromium intends to secure their hypervisor. As just discussed above, a hosted hypervisor must normally trust the hosting OS, in this case Windows, which, for obvious reasons, is not a good idea from the security standpoint. Pratt, however, clearly states that “host (...) can not interfere with the privacy or integrity of the hypervisor or other guests” (slide #8). This is a strong statement, so let's take a closer look at their approach to this problem.

The Bromium's idea of how to make their hypervisor (and the VMs) protected from a potentially malicious host OS is not really breakthrough: the slides suggest to “deprivilege the host into a VT-container” (I think the verb to bluepill is now an accepted term for such action ;), and to remove the host's access to the hypervisor pages (via EPT), as well as protect DMA access from devices via VT-d, plus to make this all sensible, use DRTM scheme such as Intel TXT, to load such a hypervisor from within a potentially untrusted OS.

So, what's wrong with the idea of a load-on-the-fly-secure-VMM-system? Isn't Ian Pratt correct that one could protect its memory and execution from the interference of the host? Actually that is possible – Intel TXT, VT-x, VT-d, and EPT give us means to achieve that (although there are a number of catches here). But he's missing one important point: it's the untrusted OS that still owns and manages the input devices (e.g. via USB stacks and drivers) and, most importantly, the output (via the GUI subsystem and drivers). Ensuring that the host OS cannot interfere (e.g. sniff the screen of trusted applications) might be very difficult, or even impossible, in practice.

If I ever was to break the security of such a system, I would just follow the simple way:

1) Infect the host e.g. via one of the many USB attacks (remember they cannot have sandboxed USB driver domain, as they have only a type II hosted hypervisor),

2) Hook somewhere into the GUI subsystem and keep recoding all the interesting data from the screen...

... or something like that ;)

There are also many other things that needs to be answered and which the publicly available documents are silent about, such as e.g. how does the system handle installation of new applications? How is clipboard and file exchange between (micro)VMs handled? How large are the interfaces exposed to each (micro)VM? For now, without a solid documentation available, and without any code to play with, it is just another vaporware for me. (Interestingly there seem to be Bromium's Beta program, which however doesn't seem to be working, at least not for me -- I tried to signup twice, but never got any confirmation or response...?)

• How is Qubes different from Xen Client?

In many aspects, Xen Client might be the most similar product to Qubes OS. Like Qubes, it is based on the Xen hypervisor and so it is also a standalone OS, that one must install instead of one's favorite system, and also, like Qubes, it is targeted for desktop systems, and also offers a possibility to run a few VMs at a time.

However, XenClient has been designed with a different goal in mind, namely as a “Virtual Desktops To Go” solution, while Qubes has been designed to provide seamless experience for secure multi-domain desktop system. As a result, lots of focus in Qubes has been put on creating trusted GUI subsystem, support for advanced networking configurations, secure inter-VM clipboard and file sharing, secure method to reuse the same filesystem as a basis for the AppVMs, and also to optimize the AppVMs so they start almost instantly and take little memory, so that one could easily run many of them at the same time. All those things seem to be missing from Xen Client (as well as solid technical documentation about its design).

***

I surely have missed a few other products or approaches -- feel free to point them out in the comments, and I might write a continuation post one day.

Introducing Qubes 1.0!

After nearly three years of work, I have a pleasure to announce that Qubes 1.0 has finally been released! To see the installation instructions and to get an ISO, please go to this page.

I would like to thank all the developers who have worked on this project. Creating Qubes OS has been a great challenge, especially for such a small team as ours, but ultimately, I'm very glad with the final outcome – it really is a stable and reasonably secure desktop OS. In fact I cannot think of any more secure alternative...

I use the term “reasonably secure”, because when it comes to defensive security it's difficult to use definite statements (“secure”, “unbreakable”, etc), unless one can formally prove the whole design and implementation to be 100% secure.

Unfortunately, contrary to common belief, there are no general purpose, desktop OSes, that would be formally proven to be secure. At the very best, there are some parts that are formally verified, such as some microkernels, but not whole OSes. And what good is saying that our microkernel is formally verified, if we continue to use a bloated and buggy X server as our GUI subsystem? After all, a GUI subsystem has access to all the user inputs and output, thus it is as much security sensitive, as is the the microkernel! Or power management subsystem, or filesystem server, or trusted boot scheme, or ... a dozens of other elements, which just cannot be forgotten if one wants to talk about a truly secure OS. As said before, I know of no general-purpose desktop OS that would be formally proven, and thus that could be called “secure”. You can also read more about challenges with formal verification microkernels in this article, and especially in this comment from the seL4 project leader.

In Qubes OS we took a practical approach and we have tried to focus on all those sensitive parts of the OS, and to make them reasonably secure. And, of course, in the first place, we tried to minimize the amount of those trusted parts, in which Qubes really stands out, I think.

So, we believe Qubes OS represents a reasonably secure OS. In fact I'm not aware of any other solution currently on the market that would come close when it comes to secure desktop environment. But then again, I'm biased, of course ;)

I wouldn't call Qubes OS “safe”, however, at least not at this stage. By “safe” I mean a product that is “safe to use”, which also implies “easy to use”, “not requiring special skills”, and thus harmless in the hands of an inexperienced user. I think that Apple iOS is a good example of such a “safe” OS – it automatically puts each application into its own sandbox, essentially not relaying on the user to make any security decisions. However, the isolation that each such sandbox provides is far from being secure, as various practical attacks have proven, and which is mostly a result of exposing too fat APIs to each sandbox, as I understand. In Qubes OS, it's the user that is responsible for making all the security decisions – how to partition her digital life into security domains, what network and other permissions each domain might have, whether to open a given document in a Disposable VM, etc. This provides for great flexibility for more advanced users, but the price to pay is that Qubes OS requires some skills and thinking to actually make the user's data more secure.

Generally Qubes OS is an advanced tool for implementing Security by Isolation approach on your desktop, using domains implemented as lightweight Xen VMs. It tries to marry two contradictory goals: how to make the isolation between domains as strong as possible, mainly due to clever architecture that minimizes the amount of trusted code, and how to make this isolation as seamless and easy as possible. Again, how the user is going to take advantage of this isolation is totally left up to the user. I realize this might be a tricky part for some users and some usage scenarios, yet, on the other hand, this seems to be the most flexible and powerful approach we could provide.

Thus people should realize that by mere fact of using Qubes OS they won't become automatically more secure – it's how they are going to use it might make them significantly more secure. A hypothetical exploit for your favourite web browser would work against Firefox running inside one of the Qubes VMs just as well as it worked for the same browser running on normal Linux. The difference that Qubes makes, is that this attacked browser might be just your for-personal-use-only browser which is isolated from your for-work-use-only-browser, and for-banking-use-only-browser.

Finally, even though Qubes has been created by a reasonably skilled team of people, it should not be considered bug free. In fact, over the last 3 years we already found 3 serious bugs/attacks affecting Qubes OS – one of them in the very code we created, and two other in Intel hardware. Again, we tried as much as possible to limit the amount of code that is security sensitive in the first place, yet we are just humans ;) So, I'm very curious to see others' attempts to break Qubes – I think it might make for a very interesting research. A good starting point for such research might be this page. And I know there are individuals out there who apparently only been waiting for Qubes 1.0 to come out, to get some glory (yet, it's not clear to me why to attack qemu, which is not part of the TCB in Qubes, but I guess great minds have their own mysteries ;)

In other words, please enjoy Qubes OS 1.0, hopefully it could make your digital life safer!

Please send all the technical questions regarding Qubes to the qubes-devel mailing list. Do not send them to me directly, nor post them in this blog's comments.

Qubes 1.0 Release Candidate 1!

I would like to announce the release of Qubes RC1. The installation ISO and instructions can be found here.

This release is expected to essentially be identical to the final 1.0 release, which will likely follow in the coming weeks, except for some minor, cosmetic fixes.

Comparing to the previous Beta 3 release, the major changes and improvements in this version include:

• A much improved Qubes Manager, that now allows to configure and manage almost every aspect of the Qubes system using a simple and intuitive GUI.
• All the VMs are now based on Fedora 17 template.
• Cleaned up and improved command lines tools for both Dom0 and for the VMs.
• Updated Dom0 and VM kernels are now based on 3.2.7-pvops kernel, which offer better hardware and power management support.
• Convenient menu improvements, that include e.g. a handy icon for launching a Disposable Web browser in a Disposable VM.
• Support for “yum proxy”, which smartly allows to update packages in a template VM (or other updateable VM), without requiring to grant general HTTP access for this VM. This has been a problem before, as the Fedora repos use hundreds of mirrored yum servers, and it wasn't possible to setup a single rule in the firewall VM to allow only access to the yum servers, and nothing else. Now, this is possible, and the primary application is to prevent user mistakes, e.g. against using the temaplate VM for Web Browsing.
• We also added support for an opt-in fullscreen mode for select VMs.
• ...plus lots of other improvements and fixes under the hood. As can be seen in the wiki, there has been over 200 tickets closed as part of the work on this release!

So, again, this is almost the final release, please test it and report any problems to the mailing list, so that we could fix them before Qubes 1.0 comes out officially.

Some comments on "Operation High Roller"

About a year ago I wrote about Why the US "password revolution" won't work, where I pointed out that a massive move towards two-factor authentication will not solve any of the identity theft problems that users experience today. Specifically, I wrote:

[People] don't understand that the [compromised] operating system can impersonate the user at will!

The compromised OS could have saved your PIN to this [smart] card when you used it previously (even if you configured it not to do so!) and now,  immediately, it could use the inserted card to authenticate as you to the bank and start issuing transactions on your behalf. And you won't even notice this all, because in the meantime it will show you a faked screen of your banking account. After all, it fully controls the screen.

The bottom line is that we cannot secure our digital lives, if our client operating systems could not be secured first.

But introduction of tokens won't make our operating systems any more secure!

This article sparked lots of controversy with many people, who considered it a fallacy to criticize two factor authentication...

Today, I came across the news about Operation High Roller, discovered recently by McAfee and Guardian Analytics. They released a paper with some details about the attacks and the malware deployed. Some interesting quotes:

All of the instances that involved High Roller malware could bypass complex multi-stage authentication. Unlike recent attacks that collect simple form authentication data—a security challenge question, a one-time token, or PIN—this attack can get past the extensive physical (“something you have”) authentication required by swiping a card in a reader and typing the input into a field (see Two-factor Authentication sidebar).

The attack asks the victim to supply the information required to get around the physical controls of smartcard reader plus pin pad entry to generate a one-time password (or digital token).

Having collected all the information it requires for the entire transfer, the malware stalls the user and executes its transaction in the background using the legitimate digital token.

Multiple after-the-theft behaviors hide evidence of the transaction from the user. For example, the client-side malware kills the links to printable statements. It also searches for and erases confirmation
emails and email copies of the statement. Finally, it also changes the transactions, transaction values, and account balance in the statement displayed on the victim’s screen so the amounts are what the account holder expects to see.

Defensive security is a difficult game, because one doesn't immediately see whether a given solution works or not. This is in stark contrast to other engineering disciplines (and to offensive security) where one usually have immediate feedback on whether something works well or not.

Say you want to build a redundant long-range video downlink for your unmanned, remotely operated helicopter -- you can throw in lots of money buying various high-gain antennas, circular antennas, antenna trackers, diversity systems, etc., but then ultimately you can verify your creation immediately by going into a field and trying to fly a few miles away, and see whether you loose the vision (usually in the middle of some life-threatening manoeuvre) or not. At least you can draw some lines of how good your solution is ("I can fly up to one mile away, but not more, unless there aren't that many trees around and the air is dry enough").

With security, especially with computer security, it is so different, because there is no immediate feedback. This results in various vendors pitching their products as wonderful solutions that just solve all the worlds problems, even though what they're saying in those marketing materials might be pure nonsense... (BTW, congrats to Simon Crosby for apparently creating a Windows-hosted VMM in below 10k LOC! ;)

The often made mistake is to say: "Perhaps there is a way to attack this solution, but then again, how much of the malware in the wild implements such attacks?" This is a classical thinking in our industry, and in my opinion, an inexcusable mistake! Let me say it clearly:

It doesn't matter whether what the malware in the wild does -- it matters what it could potentially do!

So, if we can do a quick brainstorming session and point out potential attacks within 1 hour against some technology/product X, then, if we don't see a solution how to prevent them generically, we should not bother and implement product X, because it will be defeated, sooner or later. Let's not waste time on useless solutions, life's too short!

Windows support coming to Qubes!

Ok, let's start with a screenshot :)

While the “Qubes 1.0” branch is currently in the final development and testing, we have already started working on the Next Big Feature, which is a support for HVM domains (hardware, or VT-x virtualized domains). This allows to run e.g. Windows VMs under Qubes. You might be wondering what so special about this, if Xen has been supporting HVM domains, and specifically Windows VMs for a long time, and Qubes uses Xen hypervisor, so why haven't we had Windows support since day one?

The are a couple of things that we don't like about HVM support in Xen (and also in other VMMs), which include: the need to run device emulator (AKA qemu) in Dom0, the need to use crappy VNC, or a similar protocol to access the VM's framebuffer, or alternatively, the crazy idea (from security point of view, that is) of using a pass-through graphics for a VM, the lack of support for disaggregated architecture where backends, e.g. network backends, run in other domains than Dom0. In fact even the Xen “stubdomain” feature, introduced a few years ago, that was supposed to be a solution allowing to move the qemu out of Dom0, in practice turned out to be quite disappointing, as the qemu in the stub domain still requires an accompanying process of another qemu in Dom0, somehow negating all the security benefits this architecture is supposed to bring... And not to mention the omni present assumption that backends run always in Dom0, hardcoded in a few places in the stubdomain code.

So, we didn't like it and that's why Qubes had no Windows support for long time. But this has now changed, as we have just finished the 1^st stage implementation of HVM support in Qubes, the way we like it, without any security compromises. In our implementation we've completely eliminated all the qemu remains from Dom0 (it's running in a micro stub domain), the graphics virtualization fully integrates with our very slim GUI daemon (we didn't have to modify our GUI daemon at all!), using our Xen-optimized, zero-copy, minimalist GUI protocol, and the networking is also fully integrated with the Qubes diaggregated networking architecture that uses isolated domains for all the networking stacks and drivers. Of course, there are still some rough edges, such as no clipboard support, and the virtualization is currently in a “per-desktop” mode, rather than in a “per-window” mode, which is used for PV domains. But, rest assured, we are working on those things right now...

This code is currently not public, and the plan is to release it only after Qubes 1.0 release, either as an upgrade, or as Qubes 2.0. All the dom0 code for HVM support will likely remain GPL, while any Windows-specific code (agent code) will likely be proprietary.

Qubes Beta 3!

-->

A new ISO with the just released Qubes Beta 3 is now available for download here.

Beta 3 fixes lots of annoying problems discovered in Beta 2 and earlier releases, and also implements a bunch of useful feature:

This includes the qvm-block tool and infrastructure for easy attachment of block devices to any AppVM, no matter which system VM is handling the actual USB controller. So, this allows to have untrusted USB domain(s), almost seamlessly integrated in the desktop system. One can consider to use it in order to prevent various USB attacks. The next release (the 1.0) will bring this feature to the Qubes GUI manager as well, making it easy to use for non-command-line users too.

Also, we have now introduced fully automatic Qubes build system, that allows to build all the Qubes packages, and also create the installation ISO, with just one command. More information on this system and on how to use it can be found in the wiki.

We have also updated to Fedora 15-based template as a default. Unfortunately F16-based template would require too much work to get all the Gnome 3 stuff working correctly. (The challenge here, is that we don't run a normal Windows and Desktop manager in every domain, in order to make the VMs light weight, and so we need to sometimes work around various problems this causes...).

Finally, we have added two new Qubes-specific applications:

• A plugin for Thunderbird (it is automatically installed in the template), that allows for one click opening of attachments in Disposable VMs, as well as one-click saving of the attachment to select VM.

• And something we call “split GPG”, that I will describe in a separate article later.

Those Qubes-specific applications are based on our Qubes RPC, introduced in Beta 2.

This is likely the last release before the “final 1.0”, that is scheduled to follow soon (TM). The only major work for 1.0 is GUI manager improvements to expose most of the Qubes functionality via clickable GUI, and command line tools cleanup and documentation. Plus testing and bugfixing :)

And then, the next thing we will be working on will be support for HVM domains, e.g. Windows. This work is starting actually just about now, but code will be released only after Qubes 1.0.

Thoughts on DeepSafe

Several people asked me recently what I though about DeepSafe. So, below I present my opinion...

First, for any AV system (or Host IPS, or Personal Firewall, etc) to work effectively, there are three problems that must be addressed:

1. How to protect the AV agent (code and data) from tampering (from the rest of the OS)?
2. How can the AV agent get reliable access to (sensitive pieces of) the system memory and registers, and/or provide reliable memory protection for the (sensitive pieces of) the OS.
3. What are those "sensitive pieces of” memory that should be monitored or protected?

From reading various PR materials, it seems like the #1 above is the primary differentiation factor for DeepSafe (DS). So, let's consider this problem in the context of e.g. a Windows OS. In order to protect its code and data, DS uses, as it is heavily advertised, Intel VT-x virtualization technology. Now, that sounds really secure -- after all what can be more secure than a hardware virtualization, right? ;)

But VT-x (including EPT) is only about CPU virtualization, which in our case translates to protecting the DS memory and registers from CPU-originating accesses. But, as every regular to this blog knows, there is also another method of accessing memory on any PC system, and this is through DMA transactions from devices. The OS (so also the kernel malware) is free to program one of the many devices in the system to issue DMA reads or writes to any physical memory it wants...

Now, in order to protect some portion of the system memory (DRAM, cache) against DMA accesses, we have the Intel VT-d technology... So, one would think that DS must be also using VT-d in order to protect itself.

Very well, let's assume then that the DeepSafe is not a total ripoff, and that it implements also VT-d protection for its agent, although I haven't found this mentioned in any of the public papers or press materials I found on the web...

This, however, would be a bit complex to do correctly, because the OS (so, also the kernel malware) still has a full control over the chipset (MCH), which is the entity... that controls the VT-d.

Now, in order to prevent the OS (or the kernel malware) from playing with the chipset for fun and profit, and e.g. disabling VT-d protection, DS would have to virtualize the chipset.

If you look at some consumer VMMs, such as VMware or Xen/Qemu, you would see that they all virtualize the chipset for their guests (of course), but that the chipset they provide this way is some kind of an ancient Pentium MCH. I don't think any of the consumers would be especially happy if they found out that after installing DS on their brand new 2012 laptop, Windows suddenly see a Pentium-era chipset... And this is not without a reason – chipsets, specifically MCHs, are one of the most complex devices, perhaps only beaten by GPUs in this category. There are virtually hundreds of configuration registers exposed by the chipset, some of them control the VT-d, some other control system memory maps and permissions, PCIe configuration, and many other things that I even have no idea about, and this all makes virtualizing the chipset a very challenging task.

So, it's either that McAfee and Intel found some interesting way of how to securely virtualize the chipset while preserving all of its (very rich) functionality, or that they... don't bother with VT-d protection and chipset virtualization at all, assuming that even without VT-d, DeepSafe is good enough and “rises the bar” anyway (sarcasm intended).

(Can somebody from McAfee or Intel confirm in the comments below what does DP really do?)

Anyway, let's assume they do have VT-d protection and they do virtualize the chipset somehow...

Now, we're moving on to the #2 point from the list of tasks above -- about the reliable

memory access or reliable protection.

So, let say that the DS agent decided that some part of the system memory, e.g. the IDT table, is sensitive and should be monitored/protected. So it sets up EPT traps to trigger an VT-x/EPT intercept on any access to that memory (or IDT base register), in order to find kernel malware that tried to modify IDT. That sounds really nice, but what if the malware uses DMA to modify IDT? DS would not be able to catch such access! (So far we considered the, hypothetical, use of VT-d only to protect the DS agent code).

One might think that DS is programming VT-d to sandbox each and every device in the system (so including GPU, USB controllers, NICs, SATA, etc) so they never be allowed to touch any of those sensitive parts of the system, such as IDT. Let's assume they do it this way...

And here we've arrived to the last point from the list at the beginning: which of the system memory constitutes those "sensitive pieces" that should be protected/monitored? IDT? Sure. What about all the code sections of the all the kernel modules? Yes. Are we fine now? Well, no, because the malware can hook some pointers other than the well known IDT. Some public NDIS data structure? Ok, we can add those to the protected areas. But, what about some undocumented NDIS structures? And this is just NDIS subsystem, one of the many subsystems in the Windows kernel... When we think about it, it should be intuitively obvious that in a general purpose Operating System like Windows, it is not possible (at least for 3^rd party) to make a satisfactory list of all the sensitive pieces of memory that should be monitored/protected, in order to detect all the system compromises.

Greg Hoglund, Jamie Butler, Alex Tereshkin, and myself, have been researching this area actively in the early years of this millennium. In addition to the Alex's paper linked above, you might also check out one of my last slides from this period.

I don't think anything has changed since that time. It was also the reason why I gave up on writing Windows compromise detectors, or forensic tools, and moved on to researching other ways to secure OSes, which finally gave birth to Qubes OS, many years later.

So, back to DS -- in order to provide a somehow satisfactory protection level for your general purpose OS, such as Windows, it would need to:

1. Use VT-d to protect its own memory,

2. Virtualize the chipset, at least some (sensitive) parts of it,

3. Program VT-d permissions for each device to exclude all the sensitive areas in the system that should be protected, and also protect one device from DMAing into/from another device memory (e.g. NIC stealing GPU framebuffer, or inserting instructions to the GPU instruction buffer, or keystrokes to USB controller buffer). Ideally, this could be done by programming VT-d to grant each device only access to its own DMA buffer, but as far as I know, this would be very hard to implement, if not impossible for a 3rd party, on a Windows OS (in contrast to Linux, which mostly support this model). Please correct me, if the recent Windows version allows for such use of VT-d.

4. Finally, and the most hard thing to solve, how to define all the "sensitive pieces of memory" in the system that should be protected and/or monitored? Although this is a somehow more generic problem, not specific to DS, but applying to any A/V, HIPS, or forensic tool.

So, is DeepSafe another piece of crap not worth any special attention, or has McAfee and Intel came up with some novel methods, e.g. for chipset virtualization, and other problems? Unless I see some technical info to backup the latter, I would have to assume, unfortunately, the former. But I would like to be mistaken – after all DeepSafe seems to be just a new incarnation of my Bluepill ;)