tag:blogger.com,1999:blog-245863882024-03-14T17:14:38.475+01:00The Invisible Things Lab's blogKernel, Hypervisor, Virtualization, Trusted Computing and other system-level security stuffJoanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.comBlogger114125tag:blogger.com,1999:blog-24586388.post-77535706491104199902015-02-09T19:48:00.004+01:002015-02-09T19:48:52.796+01:00Migrating my blog out of Blogger...I've migrated this blog to a new "platform".<br />
<br />
The new blog is now hosted <a href="http://blog.invisiblethings.org/">here</a>.<br />
<br />
<a href="http://blog.invisiblethings.org/2015/02/09/my-new-git-based-blog.html">This post</a> (via new blogging platform) explains the reasons of migration and how to use the new blog.<br />
<br />
Thanks!<br />
joanna. Joanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.com0tag:blogger.com,1999:blog-24586388.post-20499398532633746132014-11-27T14:57:00.001+01:002014-11-27T14:57:55.459+01:00Qubes R3/Odyssey initial source code releaseBack in 2013 we've started the work on generalizing Qubes architecture, which we code-named “Odyssey”, to allow for use of multiple hypervisors instead of just Xen via Hypervisor Abstraction Layer (“HAL” -> “Space Odyssey”, get it? ;). The concept has been described in <a href="http://theinvisiblethings.blogspot.com/2013/03/introducing-qubes-odyssey-framework.html">this post</a>, which I recommend to re-read if you're more interested in understanding our goals.<br /><br />We have been wandering here and there since that time. Lots of work has been invested in the light-weight Qubes edition for Windows, which, sadly, turned out to be <a href="http://theinvisiblethings.blogspot.com/2014/01/shattering-myths-of-windows-security.html">a failure</a>.<br /><br />We have also done a lot of work in the meantime to polish Qubes R2 and bring it to the state of the <a href="http://theinvisiblethings.blogspot.com/2014/09/announcing-qubes-os-release-2.html">final release</a>, which happened earlier this fall.<br /><br />We have also been heavily researching possibilities of other cool projects based on this flexible new architecture. Some of which you might hear about in the coming months, others turned out to be dead ends.<br /><br />Today we're finally releasing the Qubes R3 source code to the public. The code builds fine (see <a href="https://wiki.qubes-os.org/wiki/QubesR3Building">here</a> for building instruction), produces install-able ISO, and, if that was not enough, even seems to be working, mostly fine, when installed :)<br /><br />However, we don't recommend users to switch to it, and we intend this release for developers only, specifically those who would like to start working towards porting of other hypervisors, or other containerization technologies, like LXC, to Qubes R3. I highly recommend these devlopers to discuss what they try to achieve on the <a href="https://wiki.qubes-os.org/wiki/QubesLists">qubes-devel</a> mailing list, before they start the actual coding.<br /><br />Currently the only implemented and supported backend is Xen, of course, specifically the Xen 4.4, currently the latest version. It should be now trivial to switch to future versions as they become available, although, a decision to rush with that might not be such a no-brainer from the security point of view. We should remember that the hypervisor, unlike Linux kernel, is not someting you would like to change every month or so. Ideally we should aim for having a stable version of Xen for desktops that would work for years without needing any updates.<br />
<br />
But use of other hypervisors might open up lots of interesting possibilities: imagine e.g. Qubes Live USB edition that has backends for 1) Xen, 2)
KVM, and 3) LXC, and choose automatically the most secure one which is still supported on the given laptop.<br />
<br />
Major features of the current release, compared to Qubes R2:<br />
<ul>
<li>Hypervisor Abstraction Layer for all the core management stack (but still missing for the GUI daemon, see below)</li>
</ul>
<ul>
<li>New implementation of vchan and qrexec. As you might know our original vchan has been rewritten and improved (better performance and flexibility) and included in the upstream Xen starting from v4.2. Now we're switching to this upstream libvchan. Also, qrexec has been slightly rewritten to utilize some new features of this libvchan, which results in much better performance for inter-VM traffic (like a few orders of magnitude better!) Especially important for things such as USB virtualization that we're testing right now (not to be confused with USB controller pass-though).</li>
</ul>
There is still some work going on which we would like to complete before we officially decide to release Qubes OS 3.0-rc1 ISO, and this includes:<br />
<ul>
<li>Rewrite of some internal code for the core management stack, which includes internal API of the python classes. This should mostly be of no interest to users, and even most developers working on Qubes.</li>
</ul>
<ul>
<li>Initial code for <a href="https://wiki.qubes-os.org/ticket/853">Qubes Admin API</a> and port of Qubes Manager to use it.</li>
</ul>
Further down the road (Qubes OS 3.1) we plan to work on some really exciting things:<br />
<ul>
<li>More flexibility to qrexec policy (more on that in a separate post)</li>
<li>More flexibility to Qubes Admin API (expose it to slelect other VMs) </li>
<li>Split of Dom0 into (semi-depriviliged) GUI domain and minimal Admin domain. This would be great opportunity to also add the missing HAL support for the GUI daemon.</li>
</ul>
One of the immediate application of these features above would be to introduce support for remote management of Qubes installations, an absolutely necessary feature for corporate adoption of Qubes.<br />
<br />
Also note how all these tasks are independent of the actual hypervisor support, meaning it's perfectly possible for other developers to work on porting other hypervisors to Qubes in the meantime.<br /><br />The possibilities seems to be endless now. Join us and help us with The Revolution! :)<br />
<br />Joanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.comtag:blogger.com,1999:blog-24586388.post-43664427602267953412014-09-26T20:28:00.000+02:002014-11-27T13:23:40.232+01:00Announcing Qubes OS Release 2!<div class="separator" style="clear: both; text-align: center;">
</div>
Today <a href="https://wiki.qubes-os.org/wiki/QubesDownloads">we're releasing</a> Qubes OS R2! I'm not gonna write about all the cool features in this release because you can find all this in <a href="https://wiki.qubes-os.org/">our wiki</a> and previous announcements (<a href="http://theinvisiblethings.blogspot.com/2012/12/qubes-2-beta-1-with-initial-windows.html">R2-beta1</a>, <a href="http://theinvisiblethings.blogspot.com/2013/02/qubes-2-beta-2-has-been-released.html">R2-beta2</a>, <a href="http://theinvisiblethings.blogspot.com/2013/12/qubes-r2-beta-3-has-been-released.html">R2-beta3</a>, <a href="http://theinvisiblethings.blogspot.com/2014/04/qubes-os-r2-rc1-has-been-released.html">R2-rc1</a>, and <a href="http://theinvisiblethings.blogspot.com/2014/08/qubes-os-r2-rc2-debian-template-ssled.html">R2-rc2</a>). Suffice to say that we've come a long way over those 4+ years from a <a href="http://theinvisiblethings.blogspot.com/2010/04/introducing-qubes-os.html">primitive proof of concept</a> to a powerful desktop OS which, I believe, it is today.<br />
<br />
One of the biggest difficulties we have been facing with Qubes since the very beginning, has been the amount of this extra, not-so-exciting, not directly security-related work, but so much needed to ensure things actually work. Yet, the line between what is, and what is not-security related, is sometimes very thin and one can easily cross it if not being careful.<br />
<br />
It's great that we're receiving more and more community contributions. This includes not only bug fixes, but also invaluable efforts related to <a href="https://wiki.qubes-os.org/wiki/UserDoc">documentation</a>, <a href="https://wiki.qubes-os.org/wiki/HCL">HCL maintenance</a>, as well as some really non-trivial new features (advanced backups support, Debian and Arch templates, TorVM, Whonix port, etc). Thanks! <br />
<br />
I'm also happy to announce that <span id="goog_1035536959"></span><a href="https://independent.academia.edu/CasparBowden">Caspar Bowden<span id="goog_1035536960"></span></a>, a well known privacy advocate, expert on EU data protection law, member of the board of Tor, former Microsoft Chief Privacy Adviser, etc, will be taking a role as Qubes Policy Adviser, helping us to make Qubes OS more suitable for a wider audience of people interested in privacy, and be liaising with other projects that would like to build privacy services with Qubes as a base.<br />
<br />
And there is still a lot in front of us. Using the obligatory car analogy, I would say Qubes OS is currently like a racing car that just went into production as a road vehicle: one hell of an engine under-the-hood, and powerful new technologies until now unavailable even for professional use, yet lacking leather interior with 12-speaker audio system, and still with a manual transmission... This is just the beginning for making security by isolation on the desktop as "driveable" as a [insert your fav make of German fine cars] :)<br />
<br />
Exciting stuff is coming next: the Release 3 (“<a href="http://theinvisiblethings.blogspot.com/2013/03/introducing-qubes-odyssey-framework.html">Odyssey</a>”) and more, stay tuned!<br />
<br />
Thanks to <a href="https://wiki.qubes-os.org/wiki/QubesDevelopers">everyone</a> who has made Qubes OS possible, as well as all the upstream projects without which we would probably never even try this journey: Xen, Linux, Xorg, and many others!<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjouWgiZeM-Vfk2YfPCmTay1ItKDsIVl93btzhPfnFLkHy99tApm7WDFuRK2JzrwMfEu5rbtDNUS6k0G5RcXCkniNUGWss1b_6v8KQ9nh3iW8FSHK8X0ycmycqoC91QwPUaG9Iq/s1600/qubes-logo-blue.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjouWgiZeM-Vfk2YfPCmTay1ItKDsIVl93btzhPfnFLkHy99tApm7WDFuRK2JzrwMfEu5rbtDNUS6k0G5RcXCkniNUGWss1b_6v8KQ9nh3iW8FSHK8X0ycmycqoC91QwPUaG9Iq/s1600/qubes-logo-blue.png" height="200" width="200" /></a></div>
<br />Joanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.com9tag:blogger.com,1999:blog-24586388.post-22611569253864705152014-08-26T19:15:00.003+02:002014-08-26T19:15:58.669+02:00Physical separation vs. Software compartmentalizationMany people believe the Holy Grail of secure isolation is to use two or more physically separate machines. This belief seems so natural, that we often don't give it much thought. After all, what better isolation could we possible get than physical "airgap"?<br />
<br />
I argue with this point of view in this <a href="http://www.invisiblethingslab.com/resources/2014/Software_compartmentalization_vs_physical_separation.pdf">new paper</a>.<br />
<br />
I think a good place for in-depth technical discussions around the topics discussed in the paper would be our <a href="https://wiki.qubes-os.org/wiki/QubesLists">qubes-devel mailing list</a>.Joanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.comtag:blogger.com,1999:blog-24586388.post-76677430561086824052014-08-06T13:02:00.000+02:002014-11-27T13:24:15.997+01:00Qubes OS R2 rc2, Debian template, SSLed Wiki, BadUSB, and more...Today we're release the second release candidate (rc2) for Qubes OS R2. There are currently no more open tickets for the final R2 release, and we hope that what we release today is stable enough and so will be identical, or nearly identical, to the final R2 ISO, which we plan to release after the summer holidays. Download and installation instructions are <a href="https://wiki.qubes-os.org/wiki/QubesDownloads">here</a>.<br />
<br />
After Qubes rc1 release a <a href="http://theinvisiblethings.blogspot.com/2014/04/qubes-os-r2-rc1-has-been-released.html">few months ago</a> we have been hit by a number of problems related to unreliable VM start-ups. The most prevalent problem has been traced down to an upstream bug in systemd, which just happened to be manifesting on Qubes OS due to specific conditions imposed by our startup scripts.<br />
<br />
Actually, it has not been the first time when some things related to VM bootup or initialization didn't work quite well on Qubes, a side effect of heavy optimizations and stripping down we do in order to make the VMs as light weight as possible. E.g. we don't start most of the Desktop Environment which otherwise is assumed to be running by various desktop-related applications and services. In most cases these are really NOTOURBUG kind of problems, yet we just happen to be unlucky they manifest on Qubes. We do need more help from the community with testing, debugging and patching such NOTOURBUG problems in the upstream. The more people use Qubes OS, the higher the chances such problems will be addressed much quicker. Ideally, in the future, we could partner with a Linux distro that would include Qubes AppVM as one of the test cases.<br />
<br />
Speaking of different Linux distros -- we have also recently built and released an experimental (“beta”) <a href="https://wiki.qubes-os.org/wiki/Templates/Debian">Debian template for Qubes AppVMs</a>, a popular request expressed by our users for quite some time. It can be readily installed with just one command, as described in the wiki. It is supposed to behave as a first class Qubes AppVM with all the Qubes signature VM integration features, such as seamless GUI virtualization, secure clipboard, secure file copy, and other integration, all working out of the box. Special thanks to our community contributors for providing most of the patches required for porting of our agents and other scripts to Debian. This template is currently provided via our <span style="font-family: "Courier New",Courier,monospace;">templates-community</span> repo, but it nevertheless has been built and signed by ITL, and is also configured to fetch updates (for Qubes tools) from our server, but we look forward for somebody from the community to take over from us the maintenance (building, testing) of the updates for this template.<br />
<br />
Also in our "Templates Appstore" you can find now an experimental <a href="https://wiki.qubes-os.org/wiki/Templates/FedoraMinimal">“minimal” fedora-based template</a>, which might be used by more advanced users to build customized special-purpose VMs and templates.<br />
<br />
We have also moved our Wiki server to a bigger EC2 instance so it could better handle the increased traffic and also added a real CA-signed SSL certificate! But I encourage people to <a href="https://groups.google.com/d/msg/qubes-users/LsDpKnwN6w8/guoN9pKwcF4J">read why</a> this is mostly irrelevant from the security standpoint and why they should still be checking signatures on the ISOs.<br />
<br />
We also got a new logo (actually we never really had our own logo before). This also means Qubes now got its own distinct set of themes for installer, plymouth and, of course, a bunch of cool wallpapers with Qubes logo nicely engraved on them. However, it turned out that convincing KDE to set our wallpaper as a default one exceeds the collective mental abilities of ITL, and so one needs to right-click on the desktop and choose one of the Qubes-branded wallpapers manually after install or upgrade.<br />
<br />
Every once in a while people (re-)<a href="http://www.wired.com/2014/07/usb-security/">discover</a> that monolithic kernel-based desktop operating systems are not the best solution whenever the user even remotely cares about security...<br />
<br />
Yes, <a href="http://theinvisiblethings.blogspot.com/2011/06/usb-security-challenges.html">USB inherent insecurity</a>, as well as widespread <a href="http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html">GUI insecurity</a>, or <a href="http://theinvisiblethings.blogspot.com/2010/04/remotely-attacking-network-cards-or-why.html">networking stack insecurity</a>, trivial <a href="http://theinvisiblethings.blogspot.com/2009/10/evil-maid-goes-after-truecrypt.html">physical insecurities</a>, or <a href="http://theinvisiblethings.blogspot.com/2010/08/ms-dos-security-model.html">sick permissions model</a> as used in most desktop systems, have all been known facts for years. The recognition of these problems has been the primary motivator for us to start the work on Qubes OS back in 2009/2010. <br />
<br />
And yes, Qubes running on an appropriate hardware (specifically with Intel VT-d) can solve most of these problems. Correction: Qubes OS can allow the user or administrator to solve these problems, as unfortunately this still requires some configuration decisions made by the human operator. So today Qubes R2 is like a sports manual transmission, which requires a bit of skill to get most out of it. In the near future I see no reason why we should not be offering the "automatic 8-speed transmission" edition of Qubes OS. We just need more time to get there. The R3 release (<a href="http://theinvisiblethings.blogspot.com/2013/03/introducing-qubes-odyssey-framework.html">Odyssey</a>-based), whose early code is planned to be released just after the "final" R2, so sometime in September, is all about bringing us closer to that "automatic transmission" version.<br />
<br />
With my 10+ years of experience as a system-level security researcher, I believe there is no other way to go. <a href="http://theinvisiblethings.blogspot.com/2010/05/on-formally-verified-microkernels-and.html">Don't get deluded</a> that safe languages or formally verified microkernels could solve these problems. Security by Isolation, done sensibly, is the only way to go (of course it doesn't preclude making use of some formally verified components, like e.g. microkernel in place of Xen, at least in some editions of Qubes). <br />
<br />
Finally one more announcement for today: after writing this blog for 8 years, I've suddenly felt like I might need to try also some new form of expression... And so, for a few days, I now have a <a href="https://twitter.com/rootkovska">twitter account</a> (@rootkovska), which I hope to use for updates on Qubes, as well as more general commentary on various things happening in IT security.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjMty9R0NzniVjPT5thhZ54D3nR1Ip-B7Jr5VcGAHvt-6sn2UaNaTFVeMLedfjortBDgGln_BzOJbpqNplK3aG-pB933KG02ww5MEa44_mty_MJUypRJCUTdYzFYlR8zrTUYR-R/s1600/qubes-logo-blue.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjMty9R0NzniVjPT5thhZ54D3nR1Ip-B7Jr5VcGAHvt-6sn2UaNaTFVeMLedfjortBDgGln_BzOJbpqNplK3aG-pB933KG02ww5MEa44_mty_MJUypRJCUTdYzFYlR8zrTUYR-R/s1600/qubes-logo-blue.png" height="200" width="200" /></a></div>
Joanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.com11tag:blogger.com,1999:blog-24586388.post-75710538206044043192014-04-20T20:40:00.000+02:002014-11-27T13:24:27.320+01:00Qubes OS R2 rc1 has been released!Today we're releasing Qubes OS R2 rc1 (release candidate), which is expected to be the last milestone before the final Qubes OS R2 release. As mentioned <a href="http://theinvisiblethings.blogspot.com/2013/12/qubes-r2-beta-3-has-been-released.html">previously</a> today's release is bringing mainly UI improvements and polishing and lots of bugfixes, as well as some last new features: <br />
<ul>
<li>Both Dom0 and VMs have been upgraded to Fedora 20.</li>
</ul>
<ul>
<li>Support for full templates download via two new repo definitions: <a href="http://sourceforge.net/projects/qubesos/files/templates-itl/"><span style="font-family: "Courier New",Courier,monospace;">templates-itl</span></a> and <a href="http://sourceforge.net/projects/qubesos/files/templates-community/"><span style="font-family: "Courier New",Courier,monospace;">templates-community</span></a>. With a bit of imagination we could call it Qubes “AppStore” for VMs :) Currently we have only published one template there – the new default fc20-based template, but we plan to upload more templates in the coming weeks (such as the community-produced Arch Linux and Debian templates). Even though we have a separate repo for community contributed templates, we still plan on building those templates <i>ourselves</i>, from (contributed) sources.</li>
</ul>
<ul>
<li>Support for running Windows AppVMs in “full desktop” mode with support for arbitrary window resizing (which automatically adjusts the resolution in the VMs).</li>
</ul>
<ul>
<li>Support for on-the-fly switching between the “full desktop” and “seamless” modes for Windows AppVMs.</li>
</ul>
The last two features require, of course, our proprietary Qubes Windows Tools to be installed in the Windows AppVMs to work, which new version we have also published to the new repositories for R2rc1.<br />
<br />
We support smooth upgrading for current Qubes R2 Beta 3 users – the procedure is very simple, yet it will take some hours because of the Dom0 distro upgrading.<br />
<br />
As can be seen in our <a href="http://wiki.qubes-os.org/trac/report/3">ticketing system</a>, there really are only few minor cosmetic tasks left before the final Qubes R2 release. It is expected that upgrade from today's release to the final R2 will be very simple and quick – just standard updates installation.<br />
<br />
As usual, the detailed installation and upgrade instructions, as well as the HCL, can be found <a href="http://wiki.qubes-os.org/trac/wiki/QubesDownloads">here</a>. Note however, that the HCL for the today's release will take some days/weeks to compile, as we need to wait for reports from the community, and so for this time the HCL for the previous release (R2 Beta 3) should be used instead. It is reasonable to expect that the new HCL will be a subset of the previous one.<br />
<br />
Also, as usual, please keep in mind that we don't control the servers from which the ISO is being served and so please always make sure to verify the digital signature on the downloaded ISO before installing it.<br />
<br />
Please direct all the technical questions or comments regarding Qubes OS to <a href="http://wiki.qubes-os.org/trac/wiki/QubesLists">our mailing lists</a>.<br />
<br />
Enjoy!<br />
<br />Joanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.com10tag:blogger.com,1999:blog-24586388.post-3660660244652556602014-01-16T00:32:00.000+01:002014-11-27T13:24:38.464+01:00Shattering the myths of Windows securityWhen I originally described the flexible <a href="http://theinvisiblethings.blogspot.com/2013/03/introducing-qubes-odyssey-framework.html">Qubes Odyssey framework</a> several months ago, I mentioned that we would even consider to use “Windows Native Isolation” mechanisms as a primitive type of isolation provider (“hypervisor”) for some basic edition of Qubes for Windows. The idea has been very attractive indeed, because with minimal effort we could allow people to install and run such Qubes WNI on their normal, consumer Windows laptops.<br />
<br />
Sure, the inter-process isolation provided by a monolithic kernel such as Windows or Linux could never be compared to the inter-VM isolation offered even by the most lousy hypervisors. This is simply because the sizes of the interfaces exposed to untrusted entities (processes in case of a monolithic kernel; VMs in case of a hypervisor) are just incomparable. Just think about all those Windows system calls and GDI calls which any process can call and which contains probably thousands of bugs still waiting to be discovered by some kid with IDA. And think about those tens of thousands of drivers, which also expose (often unsecured) IOCTLs, as well as parsing the incoming packets, USB devices infos, filesystem metadata, etc. And then think about various additional services exposed by system processes, which are not part of the kernel, but which are still trusted and privileged. And now think about the typical interface that needs to be exposed to a typical VM: it's “just” the virtualized CPU, some emulated devices (some old-fashined Pentium-era chipset, SVGA graphics adapter, etc) and virtualized memory. <br />
<br />
Anyway, knowing all this, I still believed that Qubes WNI would make a whole lot of sense. This is because Qubes WNI would still offer a significant boost over the “Just Windows” default security, which is (still) essentially equivalent to the <a href="http://theinvisiblethings.blogspot.com/2010/08/ms-dos-security-model.html">MS-DOS security model</a>. And this is a real pity, because Windows OS has long implemented very sophisticated security mechanisms, such as complex ACLs applicable to nearly any object, as well as recent mechanisms such as UIPI/UAC, etc. So, why not use all those sophisticated security to bring some real-world security to Windows desktops!<br />
<br />
And, best of all, once people start using Qubes WNI, and they liked it, they could then pretty seamlessly upgrade to Xen-based Qubes OS, or perhaps Hyper-V-based Qubes OS (when we implement it) and their system would look and behave very similarly. Albeit with orders of magnitude stronger security. Finally, if we could get our Odyssey Framework to be flexible enough to support both Qubes WNI, as well as Xen-based Qubes OS, we should then be able to support any hypervisor or other isolation mechanism in the future.<br />
<br />
And so we decided to build the Qubes WNI. Lots of work we invested in building Qubes WNI was actually WNI-independent, because it e.g. covered adjusting the core Odyssey framework to be more flexible (after all “WNI” is quite a non-standard hypervisor) as well as some components that were Windows-specific, but not WNI-specific (e.g. could very well be used on Hyper-V based Qubes OS in the future). But we also invested lots of time into evaluating all those Windows security mechanisms in order to achieve our specific goals (e.g. proper GUI isolation, networking isolation, kernel object spaces isolation, etc)...<br />
<br />
Sadly this all has turned out to be a story without a happy end, as we have finally came to the conclusion that consumer Windows OS, with all those one-would-think sophisticated security mechanisms, is just not usable for any real-world domain isolation.<br />
<br />
And today we publish a technical paper about our findings on Windows security model and mechanisms and why we concluded they are inadequate in practice. The paper has been written by Rafał Wojdyła who joined ITL a few months ago with the main task of implementing Qubes WNI. I think most people will be able to learn a thing or two about Windows security model by reading this paper.<br />
<br />
Also, we still do have this little hope that somebody will read the paper and then write to us: “Oh, you're guys so dumb, you could just use this and that mechanism, to solve all your problems with WNI!” :)<br />
<br />
The paper can be downloaded from <a href="http://www.invisiblethingslab.com/resources/2014/A%20crack%20on%20the%20glass.pdf">here</a>.Joanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.com27tag:blogger.com,1999:blog-24586388.post-39576113666106378912013-12-11T00:14:00.000+01:002014-11-27T13:24:51.677+01:00Qubes R2 Beta 3 has been released!<style type="text/css">P { margin-bottom: 0.08in; }A:link { }</style>
<br />
<div style="margin-bottom: 0in;">
Today we're releasing Qubes R2 Beta 3,
one of the latest milestones on our roadmap for Qubes R2. Even though it is still called a
“beta”, most users should install it, because, we believe, it is
the most polished and stable Qubes edition. Looking back, I think it
was a mistake to use this alpha/beta/rc nomenclature to mark Qubes
releases, and so, starting with Qubes R3 we will be just using
version numbers: 3.0, 3.1, etc.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
Anyway, back to the R2 Beta 3 – below
I discuss some of the highlights of the today's release:</div>
<ul>
<li><div style="margin-bottom: 0in;">
The <b>seamless GUI virtualization
for Windows 7-based AppVMs</b>, and support for <b>HVM-based
templates </b>(e.g. Windows-based templates) is one of the most
spectacular feature of this release, I think. It has already been
discussed in an <a href="http://theinvisiblethings.blogspot.com/2013/11/windows-7-seamless-gui-integration.html">earlier blog post</a>,
and now instructions have also been added <a href="http://wiki.qubes-os.org/trac/wiki/WindowsAppVms">to the wiki</a>
for how to install and use such Windows AppVMs.</div>
<div style="margin-bottom: 0in;">
<br /></div>
</li>
<li><div style="margin-bottom: 0in;">
We've also introduced a much more
<b>advanced infrastructure for system backups</b>, so it is now
possible to make and restore backups to/from <i>untrusted </i><span style="font-style: normal;">VMs,
which allows e.g. to backup easily the whole system to a NAS, or
just to an USB device, not worrying that somebody might
exploit the NAS client over the network, or that plugging of the USB disk </span><span style="font-style: normal;">with
malformed partition table or filesystem </span><span style="font-style: normal;">might
compromise the system. The whole point here is that the VM that
handles the backup storage (and which might be directing it to a
NAS, or somewhere) might be compromised, and it still cannot do
anything that could compromise (or even DoS) the system, neither can
it sniff the data in the backup. I will write more about the
challenges we had to solve and how we did it in a separate blog
post. I'm very proud to note that majority of the implementation for
this has been contributed by the community, specifically Oliver
Medoc. </span><span style="font-style: normal;">Thanks!</span></div>
</li>
</ul>
<ul>
<li><div style="margin-bottom: 0in;">
<span style="font-style: normal;">A
very simple feature, trivial almost, yet very important from the
security point of view – it is now possible to set </span><span style="font-style: normal;"><b>'autostart'
property on select VMs</b></span><span style="font-style: normal;">.
Why is this so important for security? Because I can create e.g.
UsbVM, assign all my USB controllers to it, and then once I set it
as autostarting, I can have assurance that all my USB controllers
will be delegated to such AppVM immediately upon each system boot.
Having such a UsbVM is a very good idea, if one is afraid of
physical <span id="goog_20988535"></span><a href="http://www.blogger.com/goog_20988534">attacks coming though USB devices</a></span><a href="http://www.blogger.com/"><span style="font-style: normal;"></span></a><span style="font-style: normal;"><span id="goog_20988536"></span>.
And it now could double as a BackupVM with this new backup system
mentioned above!</span></div>
</li>
</ul>
<ul>
<li><div style="margin-bottom: 0in;">
<span style="font-style: normal;">To
improve hardware compatibility we now ship the installer with
</span><span style="font-style: normal;"><b>multiple </b></span><span style="font-style: normal;"><b>kernel
versions </b></span><span style="font-style: normal;">(3.7, 3.9, and
3.11) allowing to run the installation using any of those, e.g. if
it turned out that one kernel doesn't support the graphics card
correctly -- a typical problem many users faced in the past. All the kernels are also installed in the final system, allowing the user to easily boot with a select Dom0 kernel later, choosing the one which supports their hardware best. </span></div>
<div style="margin-bottom: 0in;">
<br /></div>
</li>
<li><div style="margin-bottom: 0in;">
<span style="font-style: normal;">Another popular problem of the past now was the lack of support for dynamically changing resolution/screen layout in the AppVMs when a seccond</span><sup><span style="font-style: normal;"></span></sup><span style="font-style: normal;">
monitor or a projector was hot-plugged in (which changed only the resolution layout in
Dom0). Now this problem has been solved and the </span><span style="font-style: normal;"><b>new
monitor layout is dynamically propagated to the AppVMs</b></span><span style="font-style: normal;">,
allowing to use all the screen real estate by the apps running there.</span></div>
</li>
</ul>
<ul>
<li><div style="margin-bottom: 0in;">
There has also been a significant
amount of <b>cleanups </b><b>and fixes</b>. This includes the
unification of paths and command names (“The Underscore
Revolution” as we call it), as well as refactoring of all the
source code components (which now closely matches what we have on
Qubes Odyssey/R3), and lots of various bugfixes.</div>
</li>
</ul>
<div style="margin-bottom: 0in;">
We're planning one more release (Qubes
R2 RC1) before the final R2, which will bring improvements mostly in
the area of more polished UI, such as allowing some of the tasks that
currently require commandline to be done from the Qubes Manager. So,
this would mostly be a minor cosmetic upgrade, plus bugfixes. And
probably we will also upgrade the default Linux template to Fedora 20.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
Installation and upgrade instructions
can be found <a href="http://wiki.qubes-os.org/trac/wiki/QubesDownloads">here</a>.</div>
Joanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.com8tag:blogger.com,1999:blog-24586388.post-38529162245749762242013-11-26T18:04:00.001+01:002014-11-27T13:25:04.398+01:00Windows 7 seamless GUI integration coming to Qubes OS!<style type="text/css">P { margin-bottom: 0.08in; }A:link { }</style>
<br />
<div style="margin-bottom: 0in;">
Finally, after months of hard work,
seamless mode for Windows 7 AppVMs is coming to Qubes OS! The new
Windows Support Tools will be released together with the Qubes OS R2
Beta 3, which we plan to release in the next 1-2 weeks. Here is an
obligatory screenshot showing a few Windows apps running in seamless
mode integrated onto Qubes trusted desktop (note the usual Qubes
trusted decorations around each of the Win7 windows):</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiLhobToYUd4PT2Og_yE81Wq40FC0jaNUOCmwU4kbbqp78LY-kWa7k7Z2TZzAjUvg3aV4FrmLhqI6EERCP895cXbt8dYlpoDSGR5mOBWVTsOUarbFrb8nK1oZ6cHD7boh241NZZ/s1600/windows-seamless-1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiLhobToYUd4PT2Og_yE81Wq40FC0jaNUOCmwU4kbbqp78LY-kWa7k7Z2TZzAjUvg3aV4FrmLhqI6EERCP895cXbt8dYlpoDSGR5mOBWVTsOUarbFrb8nK1oZ6cHD7boh241NZZ/s400/windows-seamless-1.png" height="225" width="400" /></a></div>
<br />
<style type="text/css">P { margin-bottom: 0.08in; }A:link { }</style>
<br />
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">The
seamless mode for Windows AppVMs is not </span><span style="font-style: normal;">yet
</span><span style="font-style: normal;">as </span><span style="font-style: normal;">polished</span><span style="font-style: normal;">
as the one we have for Linux AppVMs, </span><span style="font-style: normal;">because,
unlike what we do for Xorg, the Windows GUI agent is not based on
composition buffers extraction. </span><span style="font-style: normal;">This
causes some, </span><span style="font-style: normal;">rather</span><span style="font-style: normal;">
minor</span><span style="font-style: normal;">,
</span><span style="font-style: normal;">cosmetic problems. For example, when we have two overlapping windows from a Win7 AppVM, and move the top window away, its remaining "shadow" will be visible on the underlying window for the duration of the operation. But generally this all works reasonably good, and </span><span style="font-style: normal;">you
should not </span><span style="font-style: normal;">really </span><span style="font-style: normal;">feel
any slowness </span><span style="font-style: normal;">or heaviness
</span><span style="font-style: normal;">compared to Linux AppVMs
</span><span style="font-style: normal;">virtualization. It should be
noted that we managed to add this seamless support for Windows AppVMs
without any changes to our secure GUI virtualization protocol. </span></div>
<div style="margin-bottom: 0in;">
<br />
<span style="font-style: normal;">Of course, </span><span style="font-style: normal;">the
usual </span><span style="font-style: normal;">Qubes integration
features, such as secure inter-VM clipboard and file copy also work
for Windows AppVMs </span><span style="font-style: normal;">with the
tools installed</span><span style="font-style: normal;">. </span></div>
<div style="font-style: normal; margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">The
</span><span style="font-style: normal;">Qubes </span><span style="font-style: normal;">Windows
</span><span style="font-style: normal;">S</span><span style="font-style: normal;">upport
</span><span style="font-style: normal;">T</span><span style="font-style: normal;">ools
</span><span style="font-style: normal;">are proprietary, but they are
</span><span style="font-style: normal;">supposed to be installed </span><span style="font-style: normal;">only
in the Windows 7 VMs, which themselves contain millions of lines of
proprietary code </span><span style="font-style: normal;">already.</span><span style="font-style: normal;"> B</span><span style="font-style: normal;">esides that, the tools </span><span style="font-style: normal;">do
not introduce any other modifications to </span><span style="font-style: normal;">the system</span><span style="font-style: normal;">.</span>
</div>
<div style="font-style: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-style: normal; margin-bottom: 0in;">
As a special bonus
we have also added (and releasing also in R2B3) the support for template-based HVMs. So it will now be possible to
do something like this:</div>
<br />
<style type="text/css">P { margin-bottom: 0.08in; }A:link { }</style>
<br />
<div style="margin-bottom: 0in;">
<span style="font-family: DejaVu Sans Mono, monospace; font-size: x-small;"><span style="font-style: normal;">qvm-create
</span><span style="font-style: normal;">--</span><span style="font-style: normal;">hvm
work-win7 </span><b><span style="font-style: normal;">--</span></b><span style="font-style: normal;"><b>template
win7-x64</b> </span><span style="font-style: normal;">--</span><span style="font-style: normal;">label
green</span></span></div>
<span style="font-family: DejaVu Sans Mono, monospace; font-size: x-small;"><span style="font-style: normal;">qvm-create
</span><span style="font-style: normal;">--</span><span style="font-style: normal;">hvm
personal-win7 </span><b><span style="font-style: normal;">--</span></b><span style="font-style: normal;"><b>template
win7-x64</b> </span><span style="font-style: normal;">--</span><span style="font-style: normal;">label
purple</span></span><br />
<span style="font-family: DejaVu Sans Mono, monospace; font-size: x-small;"><span style="font-style: normal;">qvm-create</span><span style="font-style: normal;">
--</span><span style="font-style: normal;">hvm testing-win7 </span><b><span style="font-style: normal;">--</span></b><span style="font-style: normal;"><b>template
win7-x64</b> </span><span style="font-style: normal;">--</span><span style="font-style: normal;">label
red</span></span><br />
<span style="font-size: x-small;">
</span>
<br />
<div style="font-style: normal; margin-bottom: 0in;">
<span style="font-size: x-small;"><br /></span>
</div>
<span style="font-size: x-small;">
</span>
<style type="text/css">P { margin-bottom: 0.08in; }A:link { }</style><span style="font-style: normal;">... telling</span><span style="font-style: normal;">
</span><span style="font-style: normal;">Qubes to </span><span style="font-style: normal;">create</span><span style="font-style: normal;">
</span><span style="font-style: normal;">three</span><span style="font-style: normal;"> HVM </span><span style="font-style: normal;">
AppVMs based on </span><span style="font-style: normal;">th</span><span style="font-style: normal;">e
same </span><span style="font-style: normal;">template</span><span style="font-style: normal;">.</span><br />
<div style="font-style: normal; margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">All such template-based</span><span style="font-style: normal;"> </span><span style="font-style: normal;">AppVMs </span><span style="font-style: normal;">use the root filesystem from
the Template VM, which is shared in a read-only manner, of course,
but Qubes makes it look for the AppVMs as if the root filesystem was
</span><span style="font-style: normal;">writable.</span><span style="font-style: normal;">
Just like in case of </span><span style="font-style: normal;">Linux
AppVMs, the actual writes are stored in COW buffer</span><span style="font-style: normal;">s</span><span style="font-style: normal;">
backed by files stored in each of the AppVMs
directories. Upon AppVM's reboot, tho</span><span style="font-style: normal;">se</span><span style="font-style: normal;">
file</span><span style="font-style: normal;">s</span><span style="font-style: normal;">
</span><span style="font-style: normal;">are</span><span style="font-style: normal;">
discarded, which reverts the VMs' root filesystems back to that of the
template (the “golden image”). </span>
</div>
<div style="font-style: normal; margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">For
the above mechanism to make </span><span style="font-style: normal;">any
</span><span style="font-style: normal;">sense we should configure the </span><span style="font-style: normal;">OS
in the </span><span style="font-style: normal;">Template VM</span><span style="font-style: normal;">
to </span><span style="font-style: normal;">use</span><span style="font-style: normal;">
a separate disk for the user's home director</span><span style="font-style: normal;">y(ies</span><span style="font-style: normal;">)
(</span><span style="font-style: normal;">e.g. </span><span style="font-style: normal;">C:\Users
in case of Windows). </span><span style="font-style: normal;">Qubes automatically exposes an</span><span style="font-style: normal;"> additional
private disk to each of the AppVMs exactly for this very purpose. Again, just like it has been done for Linux AppVMs for years.</span></div>
<div style="font-style: normal; margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">The
above feature allows to create lots of Windows AppVMs quickly and
with minimal use of disk space, </span><span style="font-style: normal;">and
with an ability to centrally </span><span style="font-style: normal;">
</span><span style="font-style: normal;">update all the system
software in all the AppVMs all at once. </span><span style="font-style: normal;">Just
like for Linux AppVMs.</span></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">Users
should, however, ensure that the</span><span style="font-style: normal;">i</span><span style="font-style: normal;">r
license allows for such instantiating of the OS they use in the
template. </span><span style="font-style: normal;">Note that from the
technical point of view the OS is installed, and, in case of
Windows, also </span><span style="font-style: normal;"><span style="font-style: normal;">activated</span>, only once: in the template VM. The installed
files are never copied, they are only </span><i>shared</i><span style="font-style: normal;"> with the running instances of AppVMs. Consult your software licensing lawyer.</span></div>
Joanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.com10tag:blogger.com,1999:blog-24586388.post-79698057902858828122013-09-23T19:35:00.000+02:002014-11-27T13:25:17.519+01:00Thoughts on Intel's upcoming Software Guard Extensions (Part 2)<style type="text/css">P { margin-bottom: 0.08in; }</style>
<br />
<div style="font-weight: normal; margin-bottom: 0in;">
In the <a href="http://theinvisiblethings.blogspot.com/2013/08/thoughts-on-intels-upcoming-software.html">first part of this article</a> published a few weeks
ago,
I have discussed the basics of Intel SGX technology, and also
discussed challenges with using SGX for securing desktop systems,
specifically focusing on the problem of trusted input and output. In
this part we will look at some other aspects of Intel SGX, and we
will start with a discussion of how it could be used to create a
truly irreversible software.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<b>SGX Blackboxing – </b><b>A</b><b>pps
and </b><b>malware </b><b>that cannot be </b><b>reverse </b><b>engineered</b><b>?</b></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
A nice feature of
Intel SGX is that the processor automatically encrypts the content of
SGX-protected memory pages whenever it leaves the processor caches
and is stored in DRAM. In other words the code and data used by SGX
enclaves never leave the processor in plaintext.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
This feature, no
doubt influenced by the DRM industry, might profoundly change our
approach as to who controls our computers really. This is because it
will now be easy to create an application, or malware for that
matter, that just cannot be reversed engineered in any way. No more
IDA, no more debuggers, not even kernel debuggers, could reveal the
actual intentions of the EXE file we're about to run.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-weight: normal;">Consider
</span><span style="font-weight: normal;">the following </span><span style="font-weight: normal;">scena</span><span style="font-weight: normal;">rio,
</span><span style="font-weight: normal;">where a user downloads an
executable, say blackpill.exe, which in fact logically consists of
three parts:</span></div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<ol>
<li><div style="margin-bottom: 0in;">
<span style="font-weight: normal;">A
</span><b>1st stage loader</b><span style="font-weight: normal;">
(</span><b>SGX loader)</b><span style="font-weight: normal;"> which
is unencrypted, and </span><span style="font-weight: normal;">which</span><span style="font-weight: normal;">
task is to setup an SGX enclave, copy the rest of the code there,
</span><span style="font-weight: normal;">specifically the 2</span><sup><span style="font-weight: normal;">nd</span></sup><span style="font-weight: normal;">
stage loader, and then start executing the 2</span><sup><span style="font-weight: normal;">nd</span></sup><span style="font-weight: normal;">
stage loader...</span></div>
</li>
<li><div style="margin-bottom: 0in;">
<span style="font-weight: normal;">The
</span><b>2nd stage loader</b><span style="font-weight: normal;">,
which starts executing within the enclave, perform</span><span style="font-weight: normal;">s</span><span style="font-weight: normal;">
remote attestation with an external server and, in case the remote
attestation completes successfully, </span><span style="font-weight: normal;">obtains</span><span style="font-weight: normal;">
</span><span style="font-weight: normal;">a secret </span><span style="font-weight: normal;">key
from the remote server. This code is also delivered in plaintext
</span><span style="font-weight: normal;">too</span><span style="font-weight: normal;">.</span></div>
</li>
<li><div style="margin-bottom: 0in;">
<span style="font-weight: normal;">Finally
the </span><b>encrypted blob</b><span style="font-weight: normal;">
which can only be decrypted using the key obtained by the 2</span><sup><span style="font-weight: normal;">nd</span></sup><span style="font-weight: normal;">
stage loader from the remote server, </span><span style="font-weight: normal;">and
which contains the actual logic of the application (or malware).</span></div>
</li>
</ol>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-weight: normal;">We
can easily see that there is no way for the user to figure out what
the code from the encrypted blob is going to do on her computer. </span><span style="font-weight: normal;">This
is because the key will be released by the remote server only if the
</span><span style="font-weight: normal;">2</span><sup><span style="font-weight: normal;">nd</span></sup><span style="font-weight: normal;">
</span><span style="font-weight: normal;">stage loader can prove via
</span><span style="font-weight: normal;">r</span><span style="font-weight: normal;">emote
</span><span style="font-weight: normal;">a</span><span style="font-weight: normal;">ttestation
that it indeed executes within a protect SGX enclave and that it is
the original unmodified loader code that the application's author
created. Should one bit of this loader be modified, or should it be
attempted to run outside of an SGX enclave, or within a somehow
misconfigured SGX enclave, then the </span><span style="font-weight: normal;">r</span><span style="font-weight: normal;">emote
</span><span style="font-weight: normal;">a</span><span style="font-weight: normal;">ttestation
</span><span style="font-weight: normal;">would</span><span style="font-weight: normal;">
fail and the key will not be obtained.</span></div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
And once the key
is obtained, it is available only within the SGX enclave. It cannot
be found in DRAM or on the memory bus, even if the user had access to
expensive DRAM emulators or bus sniffers. And the key cannot also be
mishandled by the code that runs in the SGX enclave, because remote
attestation also proved that the loader code has not been modified,
and the author wrote the loader specifically not to mishandle the key
in any way (e.g. not to write it out somewhere to unprotected memory,
or store on the disk). Now, the loader uses the key to decrypt the
payload, and this decrypted payload remains within secure enclave,
never leaving it, just like the key. It's data never leaves the
enclave either...</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
One little catch
is how the key is actually sent to the SGX-protected enclave so that
it could not be spoofed in the middle? Of course it must be encrypted, but to which key? Well, we can have our 2<sup>nd</sup>
stage loader generate a new key pair and send the public key to the
remote server – the server will then use this public key to send
the actual decryption key encrypted with this loader's public key.
This is almost good, except for the fact that this scheme is not
immune to a classic main in the middle attack. The solution to this
is easy, though – if I understand correctly the description of the
new Quoting and Sealing operations performed by the Quoting Enclave –
we can include the generated public key hash as part of the data that
will be signed and put into the Quote message, so the remote sever
can be assured also that the public key originates from the actual
code running in the SGX enclave and not from Mallory somewhere in the
middle.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
So, what does the
application really do? Does it do exactly what has been advertised by
its author? Or does it also “accidentally” sniffs some system
memory or even reads out disk sectors and sends the gathered data to
a remote server, encrypted, of course? We cannot know this. And
that's quite worrying, I think.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
One might say that
we do accept all the proprietary software blindly anyway – after
all who fires up IDA to review MS Office before use? Or MS Windows?
Or any other application? Probably very few people indeed. But the
point is: this could be done, and actually some brave souls do that.
This could be done even if the author used some advanced form of
obfuscation. Can be done, even if taking lots of time. Now, with
Intel SGX it suddenly cannot be done anymore. That's quite a
revolution, complete change of the rules. We're no longer masters of
our little universe – the computer system – and now somebody else
is.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
Unless there was a
way for “Certified Antivirus companies” to get around SGX
protection.... (see below for more discussion on this).</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<b>...And some good applications of SGX</b></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
The SGX
blackboxing has, however, some good usages too, beyond protecting the
Hollywood productions, and making malware un-analyzable...</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
One particularly
attractive possibility is the “trusted cloud” where VMs offered
to users could not be eavesdropped or tampered by the cloud provider
admins. <a href="http://theinvisiblethings.blogspot.com/2011/12/trusted-execution-in-untrusted-cloud.html">I wrote</a> about such possibility two years ago,
but with Intel SGX this could be done much, much better. This will,
of course, require a specially written hypervisor which would be
setting up SGX containers for each of the VM, and then the VM could
authenticate to the user and prove, via remote attestation, that it
is executing inside a protected and properly set SGX enclave. Note
how this time we do not require the hypervisor to authenticate to the
users – we just don't care, if our code correctly attests that it
is in a correct SGX, it's all fine.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
Suddenly Google
could no longer collect and process your calendar, email, documents,
and medial records! Or how about a tor node that could prove to users
that it is not backdoored by its own admin and does not keep a log of
how connections were routed? Or a safe bitcoin web-based wallet? It's
hard to overestimate how good such a technology might be for bringing
privacy to the wide society of users...</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
Assuming, of
course, there was no backdoor for the NSA to get around the SGX
protection and ruin this all goodness...(see below for more
discussion on this).</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<b>New OS and VMM architectures</b></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
In the paragraph
above I mentioned that we will need specially written hypervisors
(VMMs) that will be making use of SGX in order to protect the user's
VMs against themselves (i.e. against the hypervisor). We could go
further and put other components of a VMM into protected SGX
enclaves, things that we currently, in Qubes OS, keep in separate
Service VMs, such as networking stacks, USB stacks, etc. Remember
that Intel SGX provides convenient mechanism to build inter-enclave
secure communication channels.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
We could also take
the “GUI domain” (currently this is just Dom0 in Qubes OS) and
move it into a separate SGX enclave. If only Intel came up with solid
protected input and output technologies that would work well with
SGX, then this would suddenly make whole lots of sense (unlike
currently
where <a href="http://theinvisiblethings.blogspot.com/2010/09/untrusting-your-gui-subsystem.html">it is very challenging</a>).
What we win this way is that no longer a bug in the hypervisor should
be critical, as it would be now a long way for the attacker who
compromised the hypervisor to steal any real secret of the user,
because there are no secrets in the hypervisor itself.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
In this setup the
two most critical enclaves are: 1) the GUI enclave, of course, and 2)
the admin enclave, although it is thinkable that the latter could be
made reasonably deprivileged in that it might only be allowed to
create/remove VMs, setup networking and other policies for them, but
no longer be able to read and write memory of the VMs (Anti Snowden
Protection, ASP?).</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
And... why use
hypervisors? Why not use the same approach to compartmentalize
ordinary operating systems? Well, this could be done, of course, but
it would require considerable rewrite of the systems, essentially
turning them into microkernels (except for the fact that the
microkernel would no longer need to be trusted), as well as the
applications and drivers, and we know that this will never happen.
Again, let me repeat one more time: the whole point of using
virtualization for security is that it wraps up all the huge APIs of
an ordinary OS, like Win32 or POSIX, or OSX, into a virtual machine
that itself requires orders of magnitude simpler interface to/from
the outside world (especially true for paravirtualized VMs), and all
this without the need to rewrite the applications.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<b>Trusting Intel – Next Generation
of Backdooring?</b></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
We have seen that
SGX offers a number of attractive functionality that could
potentially make our digital systems more secure and 3<sup>rd</sup>
party servers more trusted. But does it really?</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
The obvious
question, especially in the light of recent revelations about NSA
backdooring everything and the kitchen sink, is whether Intel will
have backdoors allowing “privileged entities” to bypass SGX
protections?</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<b>Traditional CPU backdooring</b></div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
Of course they
could, no question about it. But one can say that Intel (as well as
AMD) might have been having backdoors in their processors for a long
time, not necessarily in anything related to SGX, TPM, TXT, AMT, etc.
Intel could have built backdoors into simple MOV or ADD instructions,
in such a way that they would automatically disable ring/page
protections whenever executed with some magic arguments. <a href="http://theinvisiblethings.blogspot.com/2009/06/more-thoughts-on-cpu-backdoors.html">I wrote</a> more
about this many years ago.
</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
The problem with
those “traditional” backdoors is that Intel (or a certain agency)
could be caught using it, and this might have catastrophic
consequences for Intel. Just imagine somebody discovered (during a
forensic analysis of an incident) that doing:</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-family: "Courier New",Courier,monospace;">MOV eax, $deadbeef</span></div>
<span style="font-family: "Courier New",Courier,monospace;">
</span>
<div style="margin-bottom: 0in;">
<span style="font-family: "Courier New",Courier,monospace;">MOV ebx, $babecafe</span></div>
<span style="font-family: "Courier New",Courier,monospace;">
</span>
<div style="margin-bottom: 0in;">
<span style="font-family: "Courier New",Courier,monospace;">ADD eax, ebx</span></div>
<span style="font-family: "Courier New",Courier,monospace;">
</span>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
...causes ring
elevation for the next 1000 cycles. All the processors affected
would suddenly became equivalents of the old 8086 and would have to
be replaced. Quite a marketing nightmare I think, no?</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<b>Next-generation CPU backdooring</b></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
But as more and
more crypto and security mechanisms got delegated from software to
the processor, the more likely it becomes for Intel (or AMD) to
insert really “plausibly deniable” backdoors into processors.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
Consider e.g. <a href="http://people.umass.edu/gbecker/BeckerChes13.pdf">the recent paper</a> on how to plant a backdoor into the Intel's Ivy Bridge's
random number generator (usable via the new RDRAND instruction). The backdoor
reduces the actual entropy of the generator making it feasible to
later brute-force any crypto which uses keys generated via the
weakened generator. The paper goes into great lengths describing how
this backdoor could be injected by a malicious foundry (e.g. one in
China), behind the Intel's back, which is achieved by implementing
the backdoor entirely below the HDL level. The paper takes a
“classic” view on the threat model with Good Americans (Intel
engineers) and the Bad Chinese (foundry operators/employees).
Nevertheless, it should be obvious that Intel could have planted such
a backdoor without any effort or challenge described in the paper,
because they could do so at any level, not necessarily below HDL.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
But backdooring an
RNG is still something that leaves traces. Even though the backdoored
processor can apparently pass all external “randomness” testes,
such as the NIST testsuite, they still might be caught. Perhaps
because somebody will buy 1000 processors and will run them for a
year and will note down all the numbers generated and then conclude
that the distribution is quite not right. Or something like that. Or
perhaps because somebody will reverse-engineer the processor and
specifically the RNG circuitry and notice some gates are shorted to
GND. Or perhaps because somebody at this “Bad Chinese” foundry
will notice that.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
Let's now get back
to Intel SGX -- what is the actual Root of Trust for this technology?
Of course, the processor, just like for the old ring3/ring0
separation. But for SGX there is additional Root of Trust which is
used for remote attestation, and this is the private key(s) used for
signing the Quote Messages.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
If the signing
private key somehow got into the hands of an adversary, the remote
attestation breaks down completely. Suddenly the “SGX Blackboxed”
apps and malware can readily be decrypted, disassembled and reverse
engineered, because the adversary can now emulate their execution
step by step under a debugger and still pass the remote attestation.
We might say this is good, as we don't want irreversible malware and
apps. But then, suddenly, we also loose our attractive “trusted
cloud” too – now there is nothing that could stop the adversary,
who has the private signing key, to run our trusted VM outside of
SGX, yet still reporting to us that it is SGX-protected. And so,
while we believe that our trusted VM should be trusted and
unsniffable, and while we devote all our deepest secrets to it, the
adversary can read them all like on a plate.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
And the worst
thing is – even if somebody took such a processor, disassembled it
into pieces, analyzed transitor-by-transitor, recreated HDL, analyzed
it all, then still it all would look good. Because the backdoor is...
the leaked private key that is now also in the hands of the
adversary, and there is no way to prove it by looking at the
processor alone.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
As I understand,
the whole idea of having a separate TPM chip, was exactly to make
such backdoor-by-leaking-keys more difficult, because, while we're
all forced to use Intel or AMD processors today, it is possible that
e.g. every country can produce their own TPM, as it's million times
less complex than a modern processor. So, perhaps Russia could use
their own TPMs, which they might be reasonably sure they use private
keys which have not be handed over to the NSA.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
However, as I
mentioned in the first part of this article, sadly, this scheme
doesn't work that well. The processor can still cheat the external
TPM module. For example, in case of an Intel TXT and TPM – the
processor can produce incorrect PCR values in response to certain
trigger – in that case it no longer matters that the TPM is trusted
and keys not leaked, because the TPM will sign wrong values. On the
other hand we go back now to using “traditional” backdoors in the
processors, whose main disadvantage is that people might got cought
using them (e.g. somebody analyzed an exploit which turns out to be
triggering correct Quote message despite incorrect PCRs).</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
So, perhaps, the
idea of separate TPM actually does make some sense after all?</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<b>What about just accidental bugs in
Intel products?</b></div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
Conspiracy
theories aside, what about accidental bugs? What are the chances of
SGX being really foolproof, at least against those unlucky
adversaries who didn't get access to the private signing keys? The
Intel's processor have become quite a complex beasts these days. And
if you also thrown in the Memory Controller Hub, it's unimaginably
complex beast.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
Let's take a quick
tour back discussing some spectacular attacks against Intel
“hardware” security mechanisms. I wrote “hardware” in
quotation marks, because really most of these technologies is
software, like most of the things in electronics these days.
Nevertheless the “hardware enforced security” does have a special
appeal to lots of people, often creating an impression that these
must be some ultimate unbreakable technologies....</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
I think it all
started with our <a href="http://invisiblethingslab.com/resources/bh08/part2-full.pdf">exploit against Intel Q35 chipset</a> (slides
15+) demonstrated back in 2008 which was the first attack allowing to
compromise, otherwise hardware-protected, SMM memory on Intel
platforms (some other attacks against SMM shown before assumed the
SMM was not protected, which was the case on many older platforms).</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
This was then
shortly followed by <a href="http://invisiblethingslab.com/resources/bh09dc/Attacking%20Intel%20TXT%20-%20paper.pdf">another paper</a> from us about attacking Intel Trusted Execution Technology (TXT), which found
out and exploited a fact that TXT-loaded code was not protected
against code running in the SMM mode. We used our previous attack on
Q35 against SMM, as well as found a couple of new ones, in order to
compromise SMM, plant a backdoor there, and then compromise
TXT-loaded code from there. The issue highlighted in the paper has
never really been correctly patched. Intel has spent years developing
something they called STM, which was supposed to be a thin hypervisor
for SMM code sandboxing. I don't know if the Intel STM specification
has eventually been made public, and how many bugs it might be
introducing on systems using it, or how much inaccurate it might be.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
In the following
years we presented two more devastating attacks against Intel TXT
(none of which depending on compromised SMM): <a href="http://invisiblethingslab.com/resources/misc09/Another%20TXT%20Attack.pdf">one</a>
which exploited a subtle bug in the processor SINIT module allowing
to misconfigure VT-d protections for TXT-loaded code, and <a href="http://www.invisiblethingslab.com/resources/2011/Attacking_Intel_TXT_via_SINIT_hijacking.pdf">another one</a> exploiting a classic buffer overflow bug also in the processor's
SINIT module, allowing this time not only to fully bypass TXT, but
also fully bypass Intel Launch Control Policy and hijack SMM (several
years after our original papers on attacking SMM the old bugs got
patched and so this was also attractive as yet another way to
compromise SMM for whatever other reason).</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
Invisible Things
Lab has also <a href="http://invisiblethingslab.com/resources/bh09usa/Attacking%20Intel%20BIOS.pdf">presented</a> first, and as far as I'm aware still the only
one, attack on Intel BIOS that allowed to reflash the BIOS despite Intel's strong “hardware”
protection mechanism to allow only digitally signed code to be
flashed. We also <a href="http://invisiblethingslab.com/resources/bh09usa/Ring%20-3%20Rootkits.pdf">found out</a>
about secret processor in the chipset used for execution of Intel AMT
code and we found a way to inject our custom code into this special
AMT environment and have it executed in parallel with the main
system, unconstrained by any other entity.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
This is quite a
list of Intel significant security failures, which I think gives
something to think about. At the very least that just because
something is “hardware enforced” or “hardware protected”
doesn't mean it is foolproof against software exploits. Because, it
should be clearly said, all our exploits mentioned above were pure
software attacks.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
But, to be fair,
we have never been able to break Intel core memory protection (ring
separation, page protection) or Intel VT-x. Rafal Wojtczuk has
probably came closest with <a href="https://media.blackhat.com/bh-us-12/Briefings/Wojtczuk/BH_US_12_Wojtczuk_A_Stitch_In_Time_WP.pdf">his SYSRET attack</a>
in an attempt to break the ring separation, but ultimately the
Intel's excuse was that the problem was on the side of the OS
developers who didn't notice subtle differences in the behavior of
SYSRET between AMD and Intel processors, and didn't make their kernel
code defensive enough against Intel processor's odd behavior.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
We have also
<a href="http://www.invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf">demonstrated</a> rather impressive attacks bypassing Intel VT-d,
but, again, to be fair, we should mention that the attacks were
possible only on those platforms which Intel didn't equip with so
called Interrupt Remapping hardware, and that Intel knew that such
hardware was indeed needed and was planning it a few years before our
attacks were published.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
So, is Intel SGX
gonna be as insecure as Intel TXT, or as secure as Intel VT-x....?</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<b>The bottom line</b></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
Intel SGX promises
some incredible functionality – to create protected execution
environments (called enclaves) within untrusted (compromised)
Operating System. However, for SGX to be of any use on a client OS,
it is important that we also have technologies to implement trusted
output and input from/to the SGX enclave. Intel currently provides
little details about the former and openly admits it doesn't have the
later.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
Still, even
without trusted input and output technologies, SGX might be very
useful in bringing trust to the cloud, by allowing users to create
trusted VMs inside untrusted provider infrastructure. However, at the
same time, it could allow to create applications and malware that
could not be reversed engineered. It's quote ironic that those two
applications (trusted cloud and irreversible malware) are mutually
bound together, so that if one wanted to add a backdoor to allow A/V
industry to be able to analyze SGX-protected malware, then this very
same backdoor could be used to weaken the guarantees of the
trustworthiness of the user VMs in the cloud.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
Finally, a problem
that is hard to ignore today, in the post-Snowden world, is the ease
of backdooring this technology by Intel itself. In fact Intel doesn't
need to add anything to their processors – all they need to do is
to give away the private signing keys used by SGX for remote
attestation. This makes for a perfectly deniable backdoor – nobody
could catch Intel on this, even if the processor was analyzed
transistor-by-transistor, HDL line-by-line.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
As a system
architect I would love to have Intel SGX, and I would love to believe
it is secure. It would allow to further decompose Qubes OS,
specifically get rid of the hypervisor from the TCB, and probably
even more.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
<style type="text/css">P { margin-bottom: 0.08in; }</style>
</div>
<div style="font-weight: normal; margin-bottom: 0in;">
Special thanks to
Oded Horowitz for turning my attention towards Intel SGX.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
</div>
Joanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.com13tag:blogger.com,1999:blog-24586388.post-84407932167050364262013-08-30T14:14:00.000+02:002013-08-30T14:14:10.001+02:00Thoughts on Intel's upcoming Software Guard Extensions (Part 1)
<style type="text/css">P { margin-bottom: 0.08in; }</style>
<div style="margin-bottom: 0in;">
Intel Software Guard Extensions (SGX)
might very well be The Next Big Thing coming to our industry, since
the introduction of Intel VT-d, VT-x, and TXT technologies in the
previous decade. It apparently seem to promise what so far has never
been possible – an ability to create a secure <i>enclave</i><span style="font-style: normal;">
within a potentially compromised OS. It sounds just too great, so I
decided to take a closer look and share some early thoughts on this
technology</span><span style="font-style: normal;">.</span></div>
<div style="font-style: normal; margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
<b><span style="font-style: normal;">Intel
SGX –</span><span style="font-style: normal;"> secure enclaves
within </span><span style="font-style: normal;">untrusted</span><span style="font-style: normal;">
world!</span></b></div>
<div style="margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
Intel SGX is an upcoming technology,
and there is very little public documents about it at the moment. In
fact the only public papers and presentations about SGX can be found
in the agenda of <a href="https://sites.google.com/site/haspworkshop2013/workshop-program">one security workshop</a> that took place some two
months ago.
The three papers from Intel engineers presented there provide a reasonably good
technical introduction to those new processor extensions.
</div>
<div style="margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
You might think about SGX as of a next
generation of Intel TXT – a technology that has never really took
off, and which has had a long history of security problems disclosed
by certain team of researchers ;) Intel TXT has also been perhaps the
most misunderstood technology from Intel – in fact many people
thought about TXT as if it already could provide security enclaves
within untrusted OS – this however was not really true (even
ignoring for our multiple attacks) and I have spoke and wrote many
times about that in the past years.</div>
<div style="margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
It's not clear to me when SGX will make
it to the CPUs that we could buy in local shops around the corner. I
would be assuming we're talking about 3-5 years from now, because the
SGX is not even described in the Intel SDM at this moment.</div>
<div style="margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
Intel SGX is essentially a new mode of
execution on the CPU, a new memory protection semantic, plus a couple
of new instructions to manage this all. So, you create an enclave by
filling its protected pages with desired code, then you lock it down,
measure the code there, and if everything's fine, you ask the
processor to start executing the code inside the enclave. Since now
on, no entity, including the kernel (ring 0) or hypervisor (ring
“-1”), or SMM (ring “-2”) or AMT (ring “-3”), has no
right to read nor write the memory pages belonging to the enclave.
Simple as that!
</div>
<div style="margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
Why have we had to wait so long for
such technology? Ok, it's not really that simple, because we need
some form of attestation or sealing to make sure that the enclave was
really loaded with good code.</div>
<div style="margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
The cool thing about an SGX enclave is
that it can coexist (and so, co-execute) together with other code,
such all the untrusted OS code. There is no need to stop or pause the
main OS, and boot into a new stub mini-OS, like it was with the TXT
(this is what e.g. <a href="https://sparrow.ece.cmu.edu/group/flicker.html">Flicker</a> tried to do, and
which was very clumsy). Additionally, there can be multiple enclaves,
mutually untrusted, all executing at the same time.</div>
<div style="margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
<b>No more stinkin' TPMs nor BIOSes to
trust!</b></div>
<div style="margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
A nice surprise is that SGX
infrastructure no longer depends on the TPM to do measurements,
sealing and attestation. Instead Intel has a special enclave that
essentially emulates the TPM. This is a smart move, and doesn't
decrease security in my opinion. It surely makes us now trust only
Intel vs. trusting Intel plus some-asian-TPM-vendor. While it might
sound like a good idea to spread the trust between two or more
vendors, this only really makes sense if the relation between
trusting those vendors is expressed as “AND”, while in this case
the relation is, unfortunately of “OR” type – if the private EK
key gets leaked from the TPM manufacture, we can bypass any remote
attestation, and no longer we need any failure on the Intel's side.
Similarly, if Intel was to have a backdoor in their processors, this
would be just enough to sabotage all our security, even if the TPM
manufacture was decent and played fair.</div>
<div style="margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
Because of this, it's generally good
that SGX allows us to shrink the number of entities we need to trust
down to just one: Intel processor (which, these days include the CPUs
as well as the memory controller, and, often, also a GPU). Just to
remind – today, even with a sophisticated operating system
architecture like those we use in Qubes OS, which is designed with
decomposition and minimizing trust in mind, we still need to trust
the BIOS and the TPM, in addition to the processor.</div>
<div style="margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
And, of course, because SGX enclaves
memories are protected against any other processor mode's access, so
SMM backdoor no longer can compromise our protected code (in contrast
to TXT, where SMM <i>can</i><span style="font-style: normal;"> subvert
a TXT-loaded hypervisor</span>), nor any other entity, such as the
infamous AMT, or malicious GPU, should be able to do that.</div>
<div style="margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
So, this is all very good. However...</div>
<div style="margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
<b>Secure Input and Output (for Humans)</b></div>
<div style="margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
For any piece of code to be somehow
useful, there must be a secure way to interact with it. In case of
servers, this could be implemented by e.g. including the SSL endpoint
inside the protected enclave. However for most applications that run
on a client system, ability to interact with the user via screen and
keyboard is a must. So, one of the most important questions is how
does Intel SGX secures output to the screen from an SGX enclave, as
well as how does it ensure that the input the enclave gets is indeed
the input the user intended?</div>
<div style="margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
Interestingly, this subject is not very
thoroughly discussed in the Intel papers mentioned above. In fact
only one paper briefly mentions Intel Protected Audio Video Path
(PVAP) technology that apparently could be used to provide secured
output to the screen. The paper then references... a <a href="http://www.intel.com/support/graphics/sb/CS-029871.htm#whatis">consumer FAQ onBlueRay Disc Playback</a> using Intel HD graphics. There is no further
technical details and I was also unable to find any technical
document from Intel about this technology. Additionally this same
paper admits that, as of now, there is no protected <i>input</i>
technology available, even on prototype level, although they promise
to work on that in the future.</div>
<div style="margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
This might not sound very surprising –
after all one doesn't need to be a genius to figure out that the main
driving force behind this whole SGX thing is the DRM, and
specifically protecting Holywwod media against the pirate industry.
This would be nothing wrong in itself, assuming, however, the
technology could also have some other usages, that could really
improve security of the user (in contrast to the security of the
media companies).</div>
<div style="margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
We shall remember that all the secrets,
keys, tokens, and smart-cards, are ultimately to allow the user to
access some information. And how does people access information? By
viewing in on a computer screen. I know, I know, this so retro, but
until we have direct PC-brain interfaces, I'm afraid that's the only
way. Without properly securing the graphics output, all the secrets
can be ultimately leaked out.</div>
<div style="margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
Also, how people command their
computers and applications? Well, again using this retro thing called
keyboard and mouse (touchpad). However secure our enclave might be,
without secured input, the app would not be able to distinguish
intended user input from simulated input crafted by malware. Not to
mention about such obvious attacks as sniffing of the user input.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br />
</div>
<div style="font-weight: normal; margin-bottom: 0in;">
Without protected
input and output, SGX might be able to stop the malware from stealing
the user's private keys for email encryption or issuing bank
transactions, yet the malware will still be able to command this
super-secured software to e.g. decrypt all the user emails and later
steal the screenshots of all the plaintext messages (with a bit of
simple programming, the screenshot's could be turned back into nice
ASCII text for saving on bandwidth when leaking them out to a server
in Hong Kong), or better yet, perhaps just forward them to an email
address that the attacker controls (perhaps still encrypted, but
using the attackers key).</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br />
</div>
<div style="font-weight: normal; margin-bottom: 0in;">
But, let's ignore
for a moment this “little issue” of lack of protected input, and
lack of technical documentation on how secure graphics output is
really implemented. Surely it is thinkable that protected input and
output could be implemented in a number of ways, and so let's hope
Intel will do it, and will do right. We should remember here, that
whatever mechanism Intel is going to use to secure the graphics and
audio output, it surely will be an attractive target of attacks, as
there is probably a huge money incentive for such attacks in the film
illegal copying business.</div>
<div style="margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
<b>Securing </b><b>mainstream </b><b>client
OSes </b><b>and why this </b><b>is not so simple?</b></div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br />
</div>
<div style="font-weight: normal; margin-bottom: 0in;">
As mentioned
above, for SGX enclaves to be truly meaningful on client systems we
need protected input and output, to and from the secured enclaves.
Anyway, lets assume for now that Intel has come up with robust
mechanisms to provide these. Let's now consider further, how SGX
could be used to turn our current mainstream desktop systems into
reasonably secure bastions.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br />
</div>
<div style="font-weight: normal; margin-bottom: 0in;">
We start with a
simple scenario – a dedicated application for viewing of incoming
encrypted files, say PDFs, performing their decryption and signature
verification., and displaying of the final outcome to the user (via
protected graphics path). The application takes care about all the
key management too. All this happens, of coruse, inside an SGX
enclave(s).</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br />
</div>
<div style="font-weight: normal; margin-bottom: 0in;">
Now, this sounds
all attractive and surely could be implemented using the SGX. But
what about if we wanted our secure document viewer to become a bit
more than just a viewer? What if we wanted a secure version of MS
Word or Excel, with its full ability to open complex documents and
edit them?</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
<span style="font-weight: normal;">Well
it's obviously not enough to just put the </span><span style="font-weight: normal;">proverbial
</span><span style="font-weight: normal;">msword.exe into a </span><span style="font-weight: normal;">SGX</span><span style="font-weight: normal;">
enclave. It is not, because the msword.exe makes </span><span style="font-weight: normal;">use
</span><span style="font-weight: normal;">of million of other things
that are provided by the OS </span><span style="font-weight: normal;">and
3</span><sup><span style="font-weight: normal;">rd</span></sup><span style="font-weight: normal;">
libraries, in order to perform all sorts of tasks it is supposed to
do. It is not a straightforward decision to draw a line between
those parts that are security sensitive and those that are not. </span><span style="font-weight: normal;">Is
font parsing security critical? Is drawing proper labels on GUI
buttons and menu lists security critical? Is rendering of various
objects that are part of the (decrypted) document, such as pictures,
security critical? Is spellchecking security critical? Even if the
function of some of a subsystem seem not security critical (i.e. not
allows to easily </span><span style="font-weight: normal;">leak</span><span style="font-weight: normal;">
the plaintext document out of the enclave), let's not forget that all
this 3</span><sup><span style="font-weight: normal;">rd</span></sup><span style="font-weight: normal;">
party code would be interacting very closely with the
enclave-contained code. This means the attack surface exposed to all
those untrusted 3</span><sup><span style="font-weight: normal;">rd</span></sup><span style="font-weight: normal;">
party modules will be rather huge. And we already know it is rather
not possible to write a rendere</span><span style="font-weight: normal;">r</span><span style="font-weight: normal;">
for such complex documents as PDFs, DOCs, XLS, etc, without
introducing tons of exploitable bugs.</span><span style="font-weight: normal;">
</span><span style="font-weight: normal;">And these attack are not
coming now from the potentially malicious documents (against thos</span><span style="font-weight: normal;">e</span><span style="font-weight: normal;">
we protect, somehow, by parsing only signed document from trusted
peers), but are coming from the compromised OS.</span></div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
<span style="font-weight: normal;">Perhaps
it would be possible to take Adobe Reader, MS Word, Powerpoint, Excel
etc, and just rewrite every of those apps from scratch in a way that
</span><span style="font-weight: normal;">they were</span><span style="font-weight: normal;">
properly decomposed into sensitive parts that execute within SGC
enclave(s), and those that are not-sensitive and make use of all the
</span><span style="font-weight: normal;">OS-provided</span><span style="font-weight: normal;">
functionality, and further define clean and simple interfaces between
those parts, ensuring the “dirty” code cannot exploit the
sensitive code. </span><span style="font-weight: normal;">Somehow
attractive, but somehow I don't see this happening anytime soon.</span></div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br />
</div>
<div style="font-weight: normal; margin-bottom: 0in;">
But, perhaps, it
would be easier to do something different – just take the whole
msword.exe, all the DLLs it depends on, as well as all the OS
subsystems it depends on, such as the GUI subsystem, and put all of
this into an enclave. This sounds like a more rational approach, and
also more secure.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
<span style="font-weight: normal;">Only
notice one thing – we just created... a Virtual Machine </span><span style="font-weight: normal;">with
Windows OS inside and the msword.exe that uses this Windows OS.</span><span style="font-weight: normal;">.
Sure, it is not a VT-x-based VM, it is an SGX-based VM now, but it is
largely the same animal!</span></div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
<span style="font-weight: normal;">Again,
we came to the conclusion why the use of VMs is suddenly perceived as
such an increase in security (which some people cannot get, claiming
that introducing VM-layer only increases complexity) – the use of
VMs is profitable because </span><span style="font-weight: normal;">of
</span><span style="font-weight: normal;">one of thing: it suddenly
packs all the fat libraries- and OS-exposed APIs and subsystems into
one security domain, reducing all the interfaces between this code in
the VM and the outside world. Reducing of the interfaces between two
security domains is ALWAYS desirable.</span></div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br />
</div>
<div style="font-weight: normal; margin-bottom: 0in;">
But our
SGX-isolated VMs have one significant advantage over the other VM
technologies we got used to in the last decade or so – namely those
VMs can now be impenetrable to any other entity outside of the VM. No
kernel or hypervisor can peek into its memory. Neither can the SMM,
AMT, or even a determined physical attacker with DRAM emulator,
because SGX automatically encrypts any data that leave the processor,
so everything that is in the DRAM is encrypted and useless to the
physical attacker.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
<span style="font-weight: normal;">This
is a significant </span><span style="font-weight: normal;">achievement</span><span style="font-weight: normal;">.
Of course SGX, </span><span style="font-weight: normal;">strictly
speaking,</span><span style="font-weight: normal;"> is not a (full)
virtualization technology, </span><span style="font-weight: normal;">it's
not going to replace VT-x.</span><span style="font-weight: normal;">.
But remember we don't always need full virtualization, like VT-x,
often we can use paravirtualization and all we need in that case is a
good isolation technology. </span><span style="font-weight: normal;">For
examaple, </span><span style="font-weight: normal;">Xen use</span><span style="font-weight: normal;">s</span><span style="font-weight: normal;">
</span><span style="font-weight: normal;">paravirtualization</span><span style="font-weight: normal;">
for Linux-based </span><span style="font-weight: normal;">PV </span><span style="font-weight: normal;">VMs,
and use</span><span style="font-weight: normal;">s</span><span style="font-weight: normal;">
good-old ring3/ring0 separation mechanism </span><span style="font-weight: normal;">to
implement </span><span style="font-weight: normal;">this, and the
level </span><span style="font-weight: normal;">of </span><span style="font-weight: normal;">isolation
of </span><span style="font-weight: normal;">such </span><span style="font-weight: normal;">PV
domains on Xen is comparable to the isolation of HVMs, which are
virtualized using VT-x.</span></div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
<b>To Be Continued</b></div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
<span style="font-weight: normal;">In
the next part of this article, we will look into some interesting
unconventional uses of SGX, such as creating malware that cannot be
reversed engineered, or TOR nodes or Bitcoin mixers that should be
reasonably trusted, even if we don't trust the</span><span style="font-weight: normal;">ir</span><span style="font-weight: normal;">
operator</span><span style="font-weight: normal;">s</span><span style="font-weight: normal;">.
Then we will discuss how SGX might profoundly change the architecture
of the future operating systems, and virtualization systems, in a way
that we will no longer need to trust (large portions of) their
kernels or hypervisors, or system admins (Anti Snowden Protection?)
And, of course, how our Qubes OS might embrace this technology in the
future.</span></div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br />
</div>
<div style="font-weight: normal; margin-bottom: 0in;">
Finally, we should
discuss the important issue of whether this whole SGX, while
providing many great benefits for system architects, should really be
blindly trusted? What are the chances of Intel building in backdoors
there and exposing those to the NSA? Is there any difference in
trusting Intel processors today vs. trusting the SGX as a basis of
security model of all software in the future?</div>
<div style="margin-bottom: 0in;">
<br />
</div>
Joanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.com26tag:blogger.com,1999:blog-24586388.post-55265995826254156372013-06-21T12:15:00.000+02:002013-06-22T10:56:16.820+02:00Qubes OS R3 Alpha preview: Odyssey HAL in action!<style type="text/css">P { margin-bottom: 0.08in; }A:link { }</style>
<br />
<div style="margin-bottom: 0in;">
In a <a href="http://theinvisiblethings.blogspot.com/2013/03/introducing-qubes-odyssey-framework.html">previous post</a>
I have outlined a new direction we're aiming with the Qubes project,
which is a departure from using a “hardcoded” hypervisor with
Qubes (as well as “hardcoded” Linux as Dom0, GUI domain, etc).</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
Today I'm happy to announce that we've
already completed initial porting of the current Qubes OS into this
Hypervisor-Abstraction-Layer-based framework. The new version of
Qubes, that we call “R3 Alpha” for now, builds fine, installs
fine, and even (mostly) works(!), as can be admired on the screenshot
below :) It still uses Xen, of course, but this time in a
non-hardcoded way, which allows to replace it easily with another
hypervisor, as I discuss below.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh42l8RFjmA01qn-4JKDjMecHirq5rOEWt1r0xnOKR6g3W7To7HEkrI6Y-pyzpHgypTN8qiI53jxt51Rt8jgwviAEpnueW9O6QK4OKbKkgeLZUYUWcsG74MyK1-8f6CS27tM1gX/s1600/r3a1-konsoles.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="225" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh42l8RFjmA01qn-4JKDjMecHirq5rOEWt1r0xnOKR6g3W7To7HEkrI6Y-pyzpHgypTN8qiI53jxt51Rt8jgwviAEpnueW9O6QK4OKbKkgeLZUYUWcsG74MyK1-8f6CS27tM1gX/s400/r3a1-konsoles.png" width="400" /></a></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<style type="text/css">P { margin-bottom: 0.08in; }A:link { }</style>
</div>
<div style="margin-bottom: 0in;">
Our Qubes Odyssey <i>backend</i><span style="font-style: normal;">
</span><span style="font-style: normal;">needed </span>to support a
specific hypervisor comprises essentially three parts:</div>
<ol>
<li><div style="margin-bottom: 0in;">
<b>A libvirt driver</b> to support
a given VMM. In our case we got it (almost) for free, because Xen
4.2 is well supported by libvirt. I wrote “almost” for free,
because some patches to libvirt were still needed, mostly to get rid
of some unjustified simplifying assumptions, such as that all the
backends are always in Dom0, which is not the case for Qubes OS, of
course. Some of those patches were accepted into upstream libvirt,
some (still) not, so we had to fork libvirt.</div>
</li>
<li><div style="margin-bottom: 0in;">
A VMM-specific <b>implementation
of our vchan</b> – a simple, socket-like, VMM shared memory-based
communication stack between the VMs. Again, in case of Xen 4.2 we
got that (almost) for free, because Xen 4.2 has now included a
libxenvchan component, which is modified (improved and cleaned up)
version of our original vchan (written in early Qubes days for older
Xen versions) contributed and maintained by Daniel De Graff from the
NSA.</div>
</li>
<li><div style="margin-bottom: 0in;">
Some minor configuration files,
e.g. to tell libvirt which hypervisor protocol to use (in our case:
xen:///), and VM configuration template files.</div>
</li>
</ol>
<div style="margin-bottom: 0in;">
Now, if one wanted to switch Xen for
some other hypervisor, such as e.g. the KVM, we would need to write a
KVM Odyssey backend in a form of providing the above mentioned three
elements. Again, libvirt driver we would get for free, configuration
files would be trivial to write, and the only task which would
require some coding would be the vchan for KVM.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<style type="text/css">P { margin-bottom: 0.08in; }A:link { }</style>
</div>
<div style="margin-bottom: 0in;">
Ok, one thing that is left out
(non-HAL'ified) for now, is the xc_map_foreign_pages() Xen-specific
<a href="http://git.qubes-os.org/?p=joanna/gui-daemon.git;a=blob;f=shmoverride/shmoverride.c;h=0d66e4faa1ed47b4c1ced481df6e1e4819e53fc5;hb=HEAD#l71">function call</a> within our GUI daemon<a href="http://git.qubes-os.org/?p=joanna/gui-daemon.git;a=blob;f=shmoverride/shmoverride.c;h=0d66e4faa1ed47b4c1ced481df6e1e4819e53fc5;hb=HEAD#l71"></a>.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
Ideally such call could also be handled
by the libvirt API, however it's not clear to us whether true
zero-copy page access is really supported (and intended). If it is
not, we will try to contribute a patch to libvirt to add such
functionality, as it is generally useful for many things that involve
high-speed inter-VM communication, of which our GUI virtualization is
just one example. So, at this moment, one would need to add an ugly
#if (BACKEND_VMM == ...) to the code above and use another VMM's
function(s), equivalent to the xc_map_foreign_pages() on Xen.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
But besides the above, essentially
everything else should Just Work (TM). And that's pretty amazing, I
think :) While I personally can't immediately see any security
benefit of switching from Xen to KVM, it might appeal to some people
for other reasons (Performance? Better hardware support?). The point
is: this should be now easy to do.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
If one wanted to support some
Windows-based hypervisor, on the other hand, such as MS Hyper-V, or
Virtual Box on top of Windows, then two more things will need to be
taken care of:</div>
<div style="margin-bottom: 0in;">
<br /></div>
<ol>
<li><div style="margin-bottom: 0in;">
Our core management stack (the
core-admin repository), the core RPC services (mostly the qrexec
daemon, currently part of core-admin-linux repo), and the libvirt
code (core-libvirt, a forked original libvirt with some custom
patches I mentioned above), all would need to build and run fine on
Windows. While this is not a big problem for core-admin (it's all
python) and core-libvirt (it is supposed to build and run on Windows
fine), the qrexec daemon would need to be rewritten with Windows OS
in mind. We're currently working on this step, BTW.</div>
</li>
<li><div style="margin-bottom: 0in;">
The GUI daemon would also need to
be ported to run on Windows, instead of on top of X Server. This is
somehow orthogonal to the need to get rid of the hardcoded
xc_map_foreign_pages() function as mentioned above. This step might
be optional, however, if we wanted to use a Linux-based (and so
Xorg-based GUI server) as a GUI domain.</div>
</li>
</ol>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
Once the above two pieces are made
Windows-ready (note how I wrote Windows-ready, and not
specific-VMM-ready), we can then use any Windows-based hypervisor we
want (i.e. for which we have libvirt driver, and can write vchan).</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
This is again pretty amazing, because
it means we don't need N*M variations of each component (where N is
the number of VMMs, and M the number of host/GUI OSes to support) –
but only N+M! This is similar to how modern compilers are designed
using a language-specific frontends (C, C++, Pascal, C#, etc), and
architecture-specific backends (x86, x64, ARM, etc), and an
Intermediate Language for internal “grinding”, again achieving
this N+M number of needed variants instead of N*M, which otherwise
would be just totally impractical.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
One other detail I would like to point
out, and which is also visible on the screenshot above, is that we
also got rid of using the Xen-specific Xenstore infrastructure (a
registry-like tree-based infrastructure for inter-VM configuration
and status exchange), and we replaced it with our own, vchan-based
Qubes DB (core-qubesdb).</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
One interesting thing about Qubes DB is
that it get rids of the (overly complex and unnecessary) permission
system that is used by xenstore, and instead uses the most simple
approach: each VM has its separate Qubes DB daemon, and so a totally
separate configuration/state namespace. This is inline with the rest
of the Qubes philosophy, which basically says that: <b>permissions is
dead, long live separation!</b></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-weight: normal;">So,
in Qubes OS we just isolate everything by default, unless a
user/configuration specifically allows an exception – e.g. no file
copy operation between domains is possible, unless the user expresses
an explicit consent for it.</span>
</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-weight: normal;">Many
old-school security people can't imagine a system without
permissions, but </span><span style="font-weight: normal;">if we</span><span style="font-weight: normal;">
think about it more, we might get to a conclusion that: 1)
permissions are complex and so </span><span style="font-weight: normal;">often
</span><span style="font-weight: normal;">difficult to un</span><span style="font-weight: normal;">d</span><span style="font-weight: normal;">erstand
and set correctly, 2) require often complex code to parse </span><span style="font-weight: normal;">and
</span><span style="font-weight: normal;">make security decisions, and
3) often are absolutely unneeded.</span></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-weight: normal;">As a
practical example of how permissions </span><span style="font-weight: normal;">schemes
</span><span style="font-weight: normal;">might </span><span style="font-weight: normal;">sometime
</span><span style="font-weight: normal;">trick even (otherwise
somehow smart) developers</span><span style="font-weight: normal;">
into making a mistake consider <a href="http://git.qubes-os.org/?p=joanna/core-admin.git;a=commitdiff;h=59f71f634af596c8fe2ef507509bf1ae850286c7">this bug</a> in Qubes </span><span style="font-weight: normal;"></span><span style="font-weight: normal;">we made a </span><span style="font-weight: normal;">long
time ago when setting permissions on some xenstore key, which
resulted in some information leak (not much of a security problem in
general, but still). And just today</span><span style="font-weight: normal;">,
Xen.org has published <a href="http://lists.xenproject.org/archives/html/xen-devel/2013-06/msg02123.html">this advisory</a><span style="background-color: yellow;"></span>, that sounds pretty
serious, again caused by bad permissions on some xenstore keys. (Yes,
we do have <a href="https://groups.google.com/forum/#!msg/qubes-devel/KqZdbcgkTGU/YaTwNcQhcrgJ">updated Xen packages</a> </span><span style="font-weight: normal;"><span style="background-color: yellow;"></span>
</span><span style="font-weight: normal;">to fix that, of course</span><span style="font-weight: normal;">)</span><span style="font-weight: normal;">.</span></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
Back to Qubes R3 Alpha, the first
successful Qubes based on Odyssey HAL framework. As previously
mentioned, we plan to make most of the framework open sourced,
specifically all the non-Windows code. However, we're not publishing
this Odyssey/R3 code at this moment, mainly for two reasons: 1) we
don't want people to immediately start building other backends, such
as to support KVM, right at this stage, because we still might
want/need to modify some interfaces slightly, e.g. for our vchan, and
we don't want to tide our hands now, and 2) the other reason is that
we're still in the middle of “Beta” releases for Qubes R2, and we
want people to rather focus on testing that, rather stable release,
than jumping onto Qubes R3 alpha.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
In other news: everybody seems to be genuinely surprised that <i>unencrypted</i> information can be <a href="http://en.wikipedia.org/wiki/PRISM_%28surveillance_program%29">intercepted and analyzed</a> without user consent... Can it be that people will "discover" cryptography now? How many of you use PGP everyday? And how long will it take then to understand that cryptography without secure client devices is useless?</div>
Joanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.com8tag:blogger.com,1999:blog-24586388.post-76601689670118999542013-03-21T17:47:00.001+01:002014-11-27T13:26:11.508+01:00Introducing Qubes Odyssey Framework<style type="text/css">P { margin-bottom: 0.08in; }A:link { }</style>
<br />
<div style="margin-bottom: 0.12in;">
Qubes OS is becoming <a href="http://theinvisiblethings.blogspot.com/2013/02/qubes-2-beta-2-has-been-released.html">more and more</a> advanced, polished, and user friendly OS.</div>
<div style="margin-bottom: 0.12in;">
But Qubes OS, even as advanced as it
is now, surely have its limitations. Limitations, that for some users
might be difficult to accept, and might discourage them from even
trying out the OS. One such limitation is lack of 3D graphics support
for applications running in AppVMs. Another one is
still-far-from-ideal hardware compatibility – a somehow inherent
problem for most (all?) Linux-based systems.</div>
<div style="margin-bottom: 0.12in;">
There is also one more “limitation” of Qubes OS, particularly
difficult to overcome... Namely that it is a standalone Operating
System, not an <i>application</i> that could be installed inside the
user's <i>existing</i><span style="font-style: normal;"> OS. While
installing a new application that increases system's security is a
no-brianer for most people, switching to a new, exotic OS, is quite a
different story...</span></div>
<div style="font-weight: normal; margin-bottom: 0.12in;">
<span style="font-style: normal;">Before
I discuss how we plan to address those limitations, let's first make
a quick digression about what Qubes </span><i>really</i><span style="font-style: normal;">
</span><span style="font-style: normal;">is</span><span style="font-style: normal;">,
</span><span style="font-style: normal;">as many people often get that
wrong...</span></div>
<div style="font-weight: normal; margin-bottom: 0.12in;">
<span style="font-style: normal;">
<style type="text/css">P { margin-bottom: 0.08in; }A:link { }</style>
</span></div>
<div style="margin-bottom: 0.12in;">
<b><span style="font-style: normal;">What
Qubes IS, and what </span><span style="font-style: normal;">Qubes </span><span style="font-style: normal;">IS
NOT?</span></b></div>
<div style="margin-bottom: 0.12in;">
<span style="font-style: normal;">Qubes
surely is not Xen! Qubes only </span><i>uses</i><span style="font-style: normal;">
Xen to create isolat</span><span style="font-style: normal;">ed</span><span style="font-style: normal;">
containers – security domains </span><span style="font-style: normal;">(</span><span style="font-style: normal;">or
zones</span><span style="font-style: normal;">)</span><span style="font-style: normal;">.
Qubes also is not a Linux distribution! </span><span style="font-style: normal;">S</span><span style="font-style: normal;">ure,
we currently use Fedora 18 as the default template for AppVMs, but </span><span style="font-style: normal;">at
the same time </span><span style="font-style: normal;">we also support
Windows VMs. </span><span style="font-style: normal;">A</span><span style="font-style: normal;">nd
while we also use </span><span style="font-style: normal;">Linux </span><span style="font-style: normal;">as
GUI and admin domain, we could really use something different –
e.g. Windows as GUI domain.</span></div>
<div style="margin-bottom: 0.12in;">
<span style="font-style: normal;">So,
what is Qubes then? Qubes (note how I've suddenly dropped the OS
suffix) is several things:</span></div>
<ul>
<li><div style="margin-bottom: 0.12in;">
<span style="font-style: normal;">The
</span><span style="font-style: normal;"><b>way how to configure,
</b></span><span style="font-style: normal;"><b>harden, </b></span><span style="font-style: normal;"><b>and
</b></span><span style="font-style: normal;"><b>use</b></span><span style="font-style: normal;"><b>
</b></span><span style="font-style: normal;"><b>the </b></span><span style="font-style: normal;"><b>VMM</b></span><span style="font-style: normal;">
</span><span style="font-style: normal;">(e.g. Xen) to create
isolated security domains, and to minimize </span><span style="font-style: normal;">overall
</span><span style="font-style: normal;">system TC</span><span style="font-style: normal;">B</span><span style="font-style: normal;">.</span></div>
</li>
<li><div style="margin-bottom: 0.12in;">
<span style="font-style: normal;">Secure</span><span style="font-style: normal;">
</span><span style="font-style: normal;"><b>GUI virtualization</b></span><span style="font-style: normal;">
</span><span style="font-style: normal;">that provides strong gui isolation, while at the same time, provides also seamless
integration of all applications running in different VMs onto one common
desktop. Plus a</span><span style="font-style: normal;"> </span><span style="font-style: normal;">customized
GUI environment, </span><span style="font-style: normal;">including
</span><span style="font-style: normal;">trusted Window Manager that
provide</span><span style="font-style: normal;">s</span><span style="font-style: normal;">
unspoofable decorations for </span><span style="font-style: normal;">the
</span><span style="font-style: normal;">applications'</span><span style="font-style: normal;">
windows.</span></div>
</li>
<li><div style="margin-bottom: 0.12in;">
<span style="font-style: normal;">Secure
</span><span style="font-style: normal;"><b>inter-domain
</b></span><span style="font-style: normal;"><b>communication and
services </b></span><span style="font-style: normal;"><b>infrastructure</b></span><span style="font-style: normal;">
</span><span style="font-style: normal;">with </span><span style="font-style: normal;">centr</span><span style="font-style: normal;">ally
enforced</span><span style="font-style: normal;"> policy </span><span style="font-style: normal;">engine.
</span><span style="font-style: normal;">Plus some “core”
services built on top of this, such as secure file exchange between
domains.</span></div>
</li>
<li><div style="margin-bottom: 0.12in;">
<span style="font-style: normal;">Various
</span><span style="font-style: normal;"><b>additional services</b></span><span style="font-style: normal;">,
or “addons”, built on top of Qubes infrastructure, such as
Disposable VMs, Split GPG, TorVM, Trusted PDF converter, etc. These
are just few examples, as basically the sky is the limit here.</span></div>
</li>
<li><div style="margin-bottom: 0.12in;">
<span style="font-style: normal;"><b>Various
</b></span><span style="font-style: normal;"><b>additional
</b></span><span style="font-style: normal;"><b>customizations</b></span><span style="font-style: normal;">
to </span><span style="font-style: normal;">all the guest OSes that
run in various domains: GUI, Admin, ServiceVMs, and AppVMs.</span></div>
</li>
</ul>
<div style="font-weight: normal; margin-bottom: 0.12in;">
<style type="text/css">P { margin-bottom: 0.08in; }A:link { }</style>
</div>
<div style="margin-bottom: 0.12in;">
<b><span style="font-style: normal;">Introducing
</span><span style="font-style: normal;">Qubes HAL: Hypervisor
Abstraction Layer</span></b></div>
<div style="margin-bottom: 0.12in;">
<span style="font-style: normal;"><span style="font-weight: normal;">Because
Qubes is a bunch of technologies and approaches that are mostly
independent from the underlying hypervisor, </span></span><span style="font-style: normal;"><span style="font-weight: normal;">as
discussed above, </span></span><span style="font-style: normal;"><span style="font-weight: normal;">it's
quite natural to consider if we could easily build an abstraction
layer </span></span><span style="font-style: normal;"><span style="font-weight: normal;">to
</span></span><span style="font-style: normal;"><span style="font-weight: normal;">allow
</span></span><span style="font-style: normal;"><span style="font-weight: normal;">the
</span></span><span style="font-style: normal;"><span style="font-weight: normal;">use
</span></span><span style="font-style: normal;"><span style="font-weight: normal;">of
</span></span><span style="font-style: normal;"><span style="font-weight: normal;">different
VMMs with Qubes, instead </span></span><span style="font-style: normal;"><span style="font-weight: normal;">of
</span></span><span style="font-style: normal;"><span style="font-weight: normal;">j</span></span><span style="font-style: normal;"><span style="font-weight: normal;">ust
Xen? </span></span><span style="font-style: normal;"><span style="font-weight: normal;">Turns
out this is not as difficult as we originally though</span></span><span style="font-style: normal;"><span style="font-weight: normal;">t,
</span></span><span style="font-style: normal;"><span style="font-weight: normal;">a</span></span><span style="font-style: normal;"><span style="font-weight: normal;">nd
this is exactly the direction we're taking right now </span></span><span style="font-style: normal;"><span style="font-weight: normal;">with
Qubes Odyssey</span></span><span style="font-style: normal;"><span style="font-weight: normal;">!
</span></span><span style="font-style: normal;"><span style="font-weight: normal;">To
make this possible we're going to use the <a href="http://libvirt.org/">libvirt</a></span></span><a href="http://libvirt.org/"> project</a>.</div>
<div style="font-style: normal; font-weight: normal; margin-bottom: 0.12in;">
So, we might imagine Qubes that is based on Hyper-V or even Virtual
Box or VMWare Workstation. In the case of the last two Qubes would no
longer be a standalone OS, but rather an “application” that one
installs on top of an existing OS, such as Windows. The obvious
advantage we're gaining here is improved hardware compatibility, and
ease of deployment.</div>
<div style="font-style: normal; font-weight: normal; margin-bottom: 0.12in;">
And we can go even further and ask: why not use Windows Native
Isolation, i.e. mechanisms such as user account separation, process
isolation, and ACLs, to implement domain isolation? In other words
why not use Windows OS as a kind of “VMM”? This would further
dramatically improve then lightness of the system...</div>
<div style="font-style: normal; font-weight: normal; margin-bottom: 0.12in;">
Of course the price we pay for all this is progressively degraded
security, as e.g. Virtual Box cannot be a match to Xen in terms of
security, both architecturally and implementation-wise, and not to
mention the quality of isolation provided by the Windows kernel,
which is even less.</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2dKWISms147Bz2BuxhgtnxfGzeO7Tp6q2-qbHjUBW-RZxi-No6bB6f-BOmBHcpNP8RPTABGtngXjEM_KyhFpDH_g1W01XZQ4DY36GJodn02o7JFNpxzCqlztvYiULB0GrJ7vo/s1600/Qubes+Odyssey+Diagrams+1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2dKWISms147Bz2BuxhgtnxfGzeO7Tp6q2-qbHjUBW-RZxi-No6bB6f-BOmBHcpNP8RPTABGtngXjEM_KyhFpDH_g1W01XZQ4DY36GJodn02o7JFNpxzCqlztvYiULB0GrJ7vo/s400/Qubes+Odyssey+Diagrams+1.png" height="300" width="400" /></a></div>
<style type="text/css">P { margin-bottom: 0.08in; }A:link { }</style>
<br />
<div style="font-style: normal; font-weight: normal; margin-bottom: 0.12in;">
But on the other hand, it's still better than using “just Windows”
which offers essentially only one “zone”, so no domain isolation
at all! And if we can get, with minimal effort, most of our Qubes
code to work with all those various isolation providers then... why
not?</div>
<div style="font-style: normal; font-weight: normal; margin-bottom: 0.12in;">
Being able to seamlessly switch between various hypervisors is only
part of the story, of course. The remaining part is the support for
different OSes used for various Qubes domains. Currently we use
Linux, specifically Fedora 18, in our GUI & Admin domain, but
there is no fundamental reason why we couldn't use Windows there
instead. We discuss this more in-depth in one of the paragraphs
below.</div>
<div style="font-style: normal; font-weight: normal; margin-bottom: 0.12in;">
The diagram below tries to illustrate the trade-offs between hardware
compatibility and ease of deployment vs. security when using
different isolation backends with Qubes. Some variants might also
offer additional benefits, such as “super-lightness” in terms of
CPU and memory resources required, as is the case with
Windows Native Isolation.</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg95Hw_fthFFZnqgf3Qvciazk2VRp0To4vAKKd9C4PZLFDH2gNeCAKtgse_Nlw6kF2QqNFXRAEIWgskSySwTWHg56cliito1MybT6bqPGDe7btHfH7flPxXLuAkyILvyy0Btufm/s1600/Qubes+Odyssey+Diagrams+2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg95Hw_fthFFZnqgf3Qvciazk2VRp0To4vAKKd9C4PZLFDH2gNeCAKtgse_Nlw6kF2QqNFXRAEIWgskSySwTWHg56cliito1MybT6bqPGDe7btHfH7flPxXLuAkyILvyy0Btufm/s400/Qubes+Odyssey+Diagrams+2.png" height="300" width="400" /></a></div>
<style type="text/css">P { margin-bottom: 0.08in; }A:link { }</style>
<br />
<div style="margin-bottom: 0.12in;">
<b><span style="font-style: normal;">Some example configurations</span></b></div>
<div style="font-weight: normal; margin-bottom: 0.12in;">
<span style="font-style: normal;">Let's
now discuss two extreme variants of Qubes – one based on the
baremetal Xen hypervisor and the other one based on Windows Native
Isolation, so a variant from the </span><span style="font-style: normal;">opposite
</span><span style="font-style: normal;">end</span><span style="font-style: normal;">
of the spectrum </span><span style="font-style: normal;">(as shown on
the illustration above).</span></div>
<div style="font-weight: normal; margin-bottom: 0.12in;">
<span style="font-style: normal;">The
diagram below shows </span><span style="font-style: normal;">a
</span><span style="font-style: normal;">configuration that uses a
</span><span style="font-style: normal;">decent </span><span style="font-style: normal;">baremetal
hypervisor, such as Xen, with abilities to securely assign devices to untrusted
service </span><span style="font-style: normal;">domains</span><span style="font-style: normal;">
(NetVM, UsbVM). So</span><span style="font-style: normal;">, this is
very similar to the current Qubes OS.</span></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhsULafzhENjcO1BK7BmIC2B8Sp1HwioHz4jKN3IHR_jJAw7D0aZ2V6mxCU6zLy7CF5va9vAp3sgKumASNN6SP-LmtjoQPdQNmt74vf3qpCkazEjRGUILneF-qQvD_CWQMPaBeJ/s1600/Qubes+Odyssey+Diagrams+3.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhsULafzhENjcO1BK7BmIC2B8Sp1HwioHz4jKN3IHR_jJAw7D0aZ2V6mxCU6zLy7CF5va9vAp3sgKumASNN6SP-LmtjoQPdQNmt74vf3qpCkazEjRGUILneF-qQvD_CWQMPaBeJ/s400/Qubes+Odyssey+Diagrams+3.png" height="300" width="400" /></a></div>
<style type="text/css">P { margin-bottom: 0.08in; }A:link { }</style>
<br />
<div style="font-weight: normal; margin-bottom: 0.12in;">
<span style="font-style: normal;">Additionally
</span><span style="font-style: normal;">we</span><span style="font-style: normal;">
</span><span style="font-style: normal;">see</span><span style="font-style: normal;">
separate GUI and </span><span style="font-style: normal;">A</span><span style="font-style: normal;">dmin
domain</span><span style="font-style: normal;">s:</span><span style="font-style: normal;">
</span><span style="font-style: normal;">t</span><span style="font-style: normal;">he
GUI domain might perhaps be based on Windows, to provide users with a
familiar UI, while the </span><span style="font-style: normal;">A</span><span style="font-style: normal;">dmin
domain, </span><span style="font-style: normal;">tasked with domain
management and policy enforcement,</span><span style="font-style: normal;">
might be based on some minimal Linux </span><span style="font-style: normal;">distribution.</span></div>
<div style="font-weight: normal; margin-bottom: 0.12in;">
<span style="font-style: normal;">In
</span><span style="font-style: normal;">the </span><span style="font-style: normal;">current
Qubes OS </span><span style="font-style: normal;">there is no
distinction between a </span><span style="font-style: normal;">GUI and
</span><span style="font-style: normal;">an </span><span style="font-style: normal;">Admin
domain </span><span style="font-style: normal;">--</span><span style="font-style: normal;">
both </span><span style="font-style: normal;">are </span><span style="font-style: normal;">hosted
within one domain called “dom0”. But </span><span style="font-style: normal;">in
some cases </span><span style="font-style: normal;">there </span><span style="font-style: normal;">are
</span><span style="font-style: normal;">benefits of </span><span style="font-style: normal;">separating
the GUI domain from the Admin domain. </span><span style="font-style: normal;">I</span><span style="font-style: normal;">n
a corporate scenario, </span><span style="font-style: normal;">for
example, the Admin domain </span><span style="font-style: normal;">might
</span><span style="font-style: normal;">be accessible only </span><span style="font-style: normal;">to
the</span><span style="font-style: normal;"> IT department and not to
the end user. This way the user w</span><span style="font-style: normal;">ould</span><span style="font-style: normal;">
have no way of </span><span style="font-style: normal;">modifying
system-wide policies, and e.g. </span><span style="font-style: normal;">allowing
their “work” domain to suddenly talk to the </span><span style="font-style: normal;">wild
</span><span style="font-style: normal;">open Internet, </span><span style="font-style: normal;">o</span><span style="font-style: normal;">r
to copy </span><span style="font-style: normal;">work</span><span style="font-style: normal;">
project files from “work” to “personal” </span><span style="font-style: normal;">domains</span><span style="font-style: normal;">
(save for the exotic, </span><span style="font-style: normal;">low-bandwidth</span><span style="font-style: normal;">
covert channels, such as through CPU cache).</span></div>
<div style="font-weight: normal; margin-bottom: 0.12in;">
<span style="font-style: normal;">The
ability to deprivilege networking and USB stacks by assigning
corresponding devices (NICs, and USB controllers) to untrusted, or
semi-trused, domains provides great security benefit</span><span style="font-style: normal;">s</span><span style="font-style: normal;">.
</span><span style="font-style: normal;">This automatically
prevents various attacks </span><span style="font-style: normal;">against
</span><span style="font-style: normal;">the </span><span style="font-style: normal;">bugs
in </span><span style="font-style: normal;">WiFi stacks </span><span style="font-style: normal;">or
</span><a href="http://theinvisiblethings.blogspot.com/2011/06/usb-security-challenges.html"><span style="font-style: normal;">USB </span><span style="font-style: normal;">stacks</span></a><span style="font-style: normal;">.</span></div>
<div style="font-weight: normal; margin-bottom: 0.12in;">
<span style="font-style: normal;">What
is not seen on the diagram, but what is typical for baremetal
hypervisors is that</span><span style="font-style: normal;"> </span><span style="font-style: normal;">they
are usually much smaller than hosted hypervisors, </span><span style="font-style: normal;">implementing
less services, and </span><span style="font-style: normal;">delegating
most tasks, such as </span><span style="font-style: normal;">the
infamous </span><span style="font-style: normal;">I/O emulation</span><span style="font-style: normal;"> </span><span style="font-style: normal;">to </span><span style="font-style: normal;">(</span><span style="font-style: normal;">often</span><span style="font-style: normal;">)</span><span style="font-style: normal;">
unprivileged VMs.</span></div>
<div style="font-weight: normal; margin-bottom: 0.12in;">
<span style="font-style: normal;">Let's
now look at the other extreme example of using Qubes – the diagram
below shows </span><span style="font-style: normal;">an architecture
of a “Qubized” Windows system that uses either a hosted VMM, such
as Virtual Box or VMWare Workstation, or even </span><span style="font-style: normal;">the
previously mentioned </span><span style="font-style: normal;">Windows
Native Isolation mechanisms, as an isolation provider for domains.</span></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhsobtsgeQSUgZBabJ2itW-HC9OZn-t-nHOcgiWUY1X9NIVqDcIHc7qQO1f7Ndur2v6EbMOTs5Lk6zc1CDM3C2BkPzJQC2xLyUs4KmA0Hor9YgljbTDweCK69GdDL3vKOR6KcJw/s1600/Qubes+Odyssey+Diagrams+4.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhsobtsgeQSUgZBabJ2itW-HC9OZn-t-nHOcgiWUY1X9NIVqDcIHc7qQO1f7Ndur2v6EbMOTs5Lk6zc1CDM3C2BkPzJQC2xLyUs4KmA0Hor9YgljbTDweCK69GdDL3vKOR6KcJw/s400/Qubes+Odyssey+Diagrams+4.png" height="300" width="400" /></a></div>
<br />
<style type="text/css">P { margin-bottom: 0.08in; }A:link { }</style>
<br />
<div style="font-weight: normal; margin-bottom: 0.12in;">
<span style="font-style: normal;">Of
course this architecture lacks many benefits discussed above, such as
untrusted domains for networking and USB stacks, small hypervisors,
etc. But it still can be used to implement multiple security domains,
at </span><span style="font-style: normal;">a</span><span style="font-style: normal;">
much lower “price”: better hardware compatibility, easier
deployment, and in case of Windows Native Isolation – excellent
performance.</span></div>
<div style="font-weight: normal; margin-bottom: 0.12in;">
<span style="font-style: normal;">And
it really can be made reasonable, although it might require more
effort </span><span style="font-style: normal;">than it
might seem at first sight</span><span style="font-style: normal;">.
Take Windows Native Isolation – of course just creating different
user accounts to represent different domains is not enough, because
Windows still doesn't implement true GUI-level isolation. Nor network
isolation. So, there is a challenge to do it right, and “right”
in this case </span><span style="font-style: normal;">means </span><span style="font-style: normal;">to
make the isolation as good as the Windows kernel can isolate
processes from different users from each other.</span></div>
<div style="font-weight: normal; margin-bottom: 0.12in;">
<span style="font-style: normal;">Sure, a single kernel
exploit destroys this all, but it's still better than “one
application can (legally) read all my files” policy that 99% of all
desktop OSes out there essentially implement </span><span style="font-style: normal;">today.</span></div>
<div style="font-weight: normal; margin-bottom: 0.12in;">
<span style="font-style: normal;">Now,
probably the best thing with all this is that once we implement a
product based on, say, Qubes for Windows, together with various cool
“addons” that will take advantage of the Qubes services
infrastructure, and which shall be product-specific, it should then
be really easy to upgrade to another VMM, say Hyper-V to boost
security. And the users shall not even notice a change in the UI,
save for the performance degradation perhaps (well, clearly automatic
creation of VMs to handle various users tasks would be more costly on
Hyper-V than with Windows Native Isolation, where “VMs” are just... processes).</span></div>
<div style="margin-bottom: 0.12in;">
<b><span style="font-style: normal;">Qubes
building blocks – </span><span style="font-style: normal;">implementation
details</span></b></div>
<div style="font-weight: normal; margin-bottom: 0.12in;">
<span style="font-style: normal;">Let's
have a look </span><span style="font-style: normal;">now </span><span style="font-style: normal;">at
the repository layout for the latest Qubes </span><span style="font-style: normal;">OS</span><span style="font-style: normal;">
sources – every name listed below represents a separate code
repository that corresponds to a logical module, or a building block
of a Qubes system:</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">core-admin</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">core-admin-linux</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">core-agent-linux</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">core-agent-windows</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">core-vchan-xen</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">desktop-linux-kde</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">desktop-linux-xfce4</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">gui-agent-linux</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">gui-agent-windows</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">gui-agent-xen-hvm-stubdom</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">gui-common</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">gui-daemon</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">linux-dom0-updates</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">linux-installer-qubes-os</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">linux-kernel</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">linux-template-builder</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">linux-utils</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">linux-yum</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">qubes-app-linux-pdf-converter</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">qubes-app-linux-split-gpg</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">qubes-app-linux-tor</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">qubes-app-thunderbird</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">qubes-builder</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">qubes-manager</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">vmm-xen</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">vmm-xen-windows-pvdrivers</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">
<style type="text/css">P { margin-bottom: 0.08in; }A:link { }</style>
</span></div>
<div style="font-weight: normal; margin-bottom: 0.12in;">
<span style="font-style: normal;">Because
</span><span style="font-style: normal;">current </span><span style="font-style: normal;">Qubes
R2 still doesn't use HAL layer to support different hypervisors, it
can currently </span><span style="font-style: normal;">be </span><span style="font-style: normal;">used
</span><span style="font-style: normal;">with </span><span style="font-style: normal;">only
one hypervisor, </span><span style="font-style: normal;">namely Xen,
whose code is provided by the </span><span style="font-family: FreeMono, monospace;"><span style="font-style: normal;">vmm-xen</span></span><span style="font-style: normal;">
repository (in an ideal world we would be just using vanilla Xen
instead of build</span><span style="font-style: normal;">ing</span><span style="font-style: normal;">
our own from sources, </span><span style="font-style: normal;">but i</span><span style="font-style: normal;">n
reality we like the ability to build it ourselves, slightly modifying
some things).</span></div>
<div style="margin-bottom: 0.12in;">
<span style="font-style: normal;">O</span><span style="font-style: normal;">nce
we </span><span style="font-style: normal;">move towards the Qubes
Odyssey architecture </span><span style="font-style: normal;">(essentially
by replacing </span><span style="font-style: normal;">the</span><span style="font-style: normal;">
hardcoded calls </span><span style="font-style: normal;">to Xen's
management stack, </span><span style="font-style: normal;">in the
</span><span style="font-family: FreeMono, monospace;"><span style="font-style: normal;">core-admin</span></span><span style="font-style: normal;">
</span><span style="font-style: normal;">module, </span><span style="font-style: normal;">with
libvirt calls)</span><span style="font-style: normal;">, we could </span><span style="font-style: normal;">then
easily switch Xen for other hypervisors, such as Hyper-V or Virtual
Box. In case of Hyper-V we would not have access to the sources of
the VMM, of course, so would just be using the stock binaries,
although we still might want to maintain </span><span style="font-style: normal;">the</span><span style="font-style: normal;">
</span><span style="font-family: FreeMono, monospace;"><span style="font-style: normal;">vmm-hyperv
</span></span><span style="font-style: normal;">repository that could
contain various hardening scripts and configuration files </span><span style="font-style: normal;">for this
</span><span style="font-style: normal;">VMM. </span><span style="font-style: normal;">Or
might not. </span><span style="font-style: normal;">Also, chances are
high that we would be just able to use the stock libvirt driver</span><span style="font-style: normal;">s</span><span style="font-style: normal;">
for Hyper-V </span><span style="font-style: normal;">or Virtual Box,</span><span style="font-style: normal;">
so no need for creating </span><span style="font-family: FreeMono, monospace;"><span style="font-style: normal;">core-</span></span><span style="font-family: FreeMono, monospace;"><span style="font-style: normal;">libvirt-</span></span><span style="font-family: FreeMono, monospace;"><span style="font-style: normal;">hyper</span></span><span style="font-family: FreeMono, monospace;"><span style="font-style: normal;">v</span></span><span style="font-family: FreeMono, monospace;"><span style="font-style: normal;"></span></span>
or <span style="font-family: FreeMono, monospace;"><span style="font-style: normal;">core-</span></span><span style="font-family: FreeMono, monospace;"><span style="font-style: normal;"><span style="font-family: FreeMono, monospace;"><span style="font-style: normal;">libvirt-</span></span>virtualbox</span></span>
<span style="font-style: normal;">backend</span><span style="font-style: normal;">s</span><span style="font-style: normal;">.</span></div>
<div style="margin-bottom: 0.12in;">
<span style="font-style: normal;">What
we will need to provide, is our</span><span style="font-style: normal;">
custom inter-</span><span style="font-style: normal;">domain</span><span style="font-style: normal;">
communication library </span><span style="font-style: normal;">for
each hypervisor supported.</span><span style="font-style: normal;">
</span><span style="font-style: normal;">This means we will need to
write </span><span style="font-family: FreeMono, monospace;"><span style="font-style: normal;">core-vchan-hyper</span></span><span style="font-family: FreeMono, monospace;"><span style="font-style: normal;">v</span></span><span style="font-style: normal;">
or </span><span style="font-family: FreeMono, monospace;"><span style="font-style: normal;">core-vchan-virtualbox</span></span><span style="font-style: normal;">.
Most (all?) VMMs do provide some kind of API for inter-VM
communication (or at least VM-host communication), so the main task
of such component is to</span><span style="font-style: normal;"></span><span style="font-style: normal;"> wrap </span><span style="font-style: normal;">the
VMM-custom mechanism</span><span style="font-style: normal;"> with
Qubes-</span><span style="font-style: normal;">standarized</span><span style="font-style: normal;">
API for vchan </span><span style="font-style: normal;">(and this
standardization is one thing we're currently working on)</span><span style="font-style: normal;">.
</span><span style="font-style: normal;">All in all, i</span><span style="font-style: normal;">n
most cases </span><span style="font-style: normal;">this will be a</span><span style="font-style: normal;">
simple task.</span></div>
<div style="margin-bottom: 0.12in;">
If we, on the other hand, wanted to
support an “exotic” VMM, such as the previously mentioned Windows
Native Isolation, which is not really a true VMM, then we will need
to write our own libvirt backend to support is:</div>
<div style="margin-bottom: 0.12in;">
<span style="font-family: FreeMono, monospace;">core-libvirt-windows</span></div>
<div style="margin-bottom: 0.12in;">
... as well as the corresponding
vchan module (which should be especially trivial to write in this
case):</div>
<div style="margin-bottom: 0.12in;">
<span style="font-family: FreeMono, monospace;">core-vchan-windows</span></div>
<div style="margin-bottom: 0.12in;">
<span style="font-style: normal;"><span style="font-weight: normal;">Additionally,
if we're building a system where the Admin domain is not based on
Linux, which would </span></span><span style="font-style: normal;"><span style="font-weight: normal;">likely
</span></span><span style="font-style: normal;"><span style="font-weight: normal;">be
the case if we used Hyper-V, or Virtual Box for Windows, or,
especially, Windows Native Isolation, then we should also provide
</span></span><span style="font-family: FreeMono, monospace;"><span style="font-style: normal;"><span style="font-weight: normal;">core-admin-windows</span></span></span><span style="font-style: normal;"><span style="font-weight: normal;">
module, that, among other things, </span></span><span style="font-style: normal;"><span style="font-weight: normal;">should
</span></span><span style="font-style: normal;"><span style="font-weight: normal;">provide
</span></span><span style="font-style: normal;"><span style="font-weight: normal;">Qubes
</span></span><span style="font-style: normal;"><span style="font-weight: normal;"><a href="http://wiki.qubes-os.org/trac/wiki/Qrexec"><i>qrexec</i></a>
implementation, something that is highly OS-dependent.</span></span></div>
<div style="margin-bottom: 0.12in;">
<span style="font-style: normal;"><span style="font-weight: normal;">As can be seen
above, we currently only have </span></span><span style="font-family: FreeMono, monospace;"><span style="font-style: normal;"><span style="font-weight: normal;">core-admin-linux</span></span></span><span style="font-style: normal;"><span style="font-weight: normal;">,
which is understandable as we currently use Linux in Dom0. But the
good news is that we only </span></span><span style="font-style: normal;"><span style="font-weight: normal;">need
to </span></span><span style="font-style: normal;"><span style="font-weight: normal;">write
</span></span><span style="font-family: FreeMono, monospace;"><span style="font-style: normal;"><span style="font-weight: normal;">core-admin-XXX</span></span></span><span style="font-style: normal;"><span style="font-weight: normal;">
once for each OS that is to be supported as an </span></span><span style="font-style: normal;"><span style="font-weight: normal;">A</span></span><span style="font-style: normal;"><span style="font-weight: normal;">dmin
domain, a</span></span><span style="font-style: normal;"><span style="font-weight: normal;">s</span></span><span style="font-style: normal;"><span style="font-weight: normal;">
this </span></span><span style="font-style: normal;"><span style="font-weight: normal;">code
should not be depend on the actual VMM used (thanks to our smart
HAL).</span></span></div>
<div style="margin-bottom: 0.12in;">
<span style="font-style: normal;"><span style="font-weight: normal;">Similarly,
we also need to assure that our </span></span><span style="font-family: FreeMono, monospace;"><span style="font-style: normal;"><span style="font-weight: normal;">gui-daemon</span></span></span><span style="font-style: normal;"><span style="font-weight: normal;">
can run on the OS that is </span></span><span style="font-style: normal;"><span style="font-weight: normal;">to
be </span></span><span style="font-style: normal;"><span style="font-weight: normal;">used
as </span></span><span style="font-style: normal;"><span style="font-weight: normal;">a
</span></span><span style="font-style: normal;"><span style="font-weight: normal;">GUI
domain (again, in most cases GUI domain would be the same as Admin
domain, but not always). Here the situation is generally much easier
because “with just a few #ifdefs” our </span></span><span style="font-style: normal;"><span style="font-weight: normal;">current GUI</span></span><span style="font-style: normal;"><span style="font-weight: normal;">
daemon should compile and run on most OSes, from Linux/Xorg to
Windows and Macs </span></span><span style="font-style: normal;"><span style="font-weight: normal;">(which
is the reason we only have one </span></span><span style="font-family: FreeMono, monospace;"><span style="font-style: normal;"><span style="font-weight: normal;">gui-daemon</span></span></span><span style="font-style: normal;"><span style="font-weight: normal;">
repository, instead of several </span></span><span style="font-family: FreeMono, monospace;"><span style="font-style: normal;"><span style="font-weight: normal;">gui-daemon-XXX</span></span></span><span style="font-style: normal;"><span style="font-weight: normal;">).</span></span></div>
<div style="margin-bottom: 0.12in;">
<span style="font-style: normal;"><span style="font-weight: normal;">Finally
we should provide some code that will gather all the components
need</span></span><span style="font-style: normal;"><span style="font-weight: normal;">ed</span></span><span style="font-style: normal;"><span style="font-weight: normal;">
for our specific product and package this all into either an
installable ISO, </span></span><span style="font-style: normal;"><span style="font-weight: normal;">if
Qubes is </span></span><span style="font-style: normal;"><span style="font-weight: normal;">to
be </span></span><span style="font-style: normal;"><span style="font-weight: normal;">a
standalone OS, </span></span><span style="font-style: normal;"><span style="font-weight: normal;">like
current Qubes</span></span><span style="font-style: normal;"><span style="font-weight: normal;">,</span></span><span style="font-style: normal;"><span style="font-weight: normal;">
or </span></span><span style="font-style: normal;"><span style="font-weight: normal;">into
an </span></span><span style="font-style: normal;"><span style="font-weight: normal;">executable,
in case Qubes is </span></span><span style="font-style: normal;"><span style="font-weight: normal;">to
be </span></span><span style="font-style: normal;"><span style="font-weight: normal;">an
“application”. The installer, depending on the product, might do some cool things, such as e.g. take current user system and automatically move it into one of Qubes domains.</span></span></div>
<div style="margin-bottom: 0.12in;">
<span style="font-style: normal;"><span style="font-weight: normal;">To
summary, these would be the components needed to build “Qubes for
Windows” product:</span></span></div>
<span style="font-family: FreeMono, monospace;">core-admin</span>
<br />
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">core-admin-windows</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">core-agent-windows</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">core-vchan-windows</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">core-libvirt-windows </span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">desktop-windows</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">gui-agent-windows</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">gui-common</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">gui-daemon</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">windows-installer-qubes-for-windows</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">qubes-builder</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">qubes-manager</span></div>
<div lang="zxx" style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0.12in;">
<span lang="zxx">Additionally we
will likely need a few </span><span style="font-family: FreeMono, monospace;"><span lang="zxx">qubes-app-*</span></span><span lang="zxx">
modules that would implement some "addons", such as perhaps
automatic links and documents opening in specific VMs, e.g.:</span></div>
<div style="margin-bottom: 0.12in;">
<span style="font-family: FreeMono, monospace;"><span lang="zxx">qubes-app-windows-mime-handlers</span></span></div>
<div lang="zxx" style="margin-bottom: 0.12in;">
<span style="font-style: normal;"><span style="font-weight: normal;">Here, again,
the sky's the limit and this is specifically the area where each
vendor can go to great lenghts and build killer apps using our Qubes
framework.</span></span></div>
<div lang="zxx" style="margin-bottom: 0.12in;">
<span style="font-style: normal;"><span style="font-weight: normal;">Now</span></span><span style="font-style: normal;"><span style="font-weight: normal;">,
if we wanted to create "Qubes for Hyper-V" we would need the following
components:</span></span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">core-admin</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">core-admin-windows</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">core-agent-linux</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">core-agent-windows</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">core-vchan-hyperv</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">desktop-windows</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">gui-agent-linux</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">gui-agent-windows</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">gui-common</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">gui-daemon</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">windows-installer-qubes-hyperv</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">qubes-app-XXX</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">qubes-builder</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">qubes-manager</span></div>
<div lang="zxx" style="font-weight: normal; margin-bottom: 0in;">
<span style="font-family: FreeMono, monospace;">vmm-hyperv</span></div>
<div lang="zxx" style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0.12in;">
Here, as an example, I also left
optional <span style="font-family: FreeMono, monospace;">core-agent-linux</span> and
<span style="font-family: FreeMono, monospace;">gui-agent-linux</span> components
(the same that are to be used with Xen-based Qubes OS) to allow
support for also Linux-based VMs – if we can get those “for
free”, then why not!
</div>
<div style="margin-bottom: 0.12in;">
It should be striking how many of
those components are the same in both of those two cases –
essentially the only differences are made by the use of different
<span style="font-family: FreeMono, monospace;">vmm-*</span> components and, of
course, the different installer</div>
<div style="margin-bottom: 0.12in;">
It should be also clear now how this
framework now enables seamless upgrades from one product (say Qubes
for Windows) to another (say Qubes for Hyper-V).</div>
<div style="margin-bottom: 0.12in;">
<b>Licensing</b></div>
<div style="font-weight: normal; margin-bottom: 0.12in;">
Our business
model assumes working with vendors, as opposed to end users, and
licensing to them various code modules needed to create products
based on Qubes.</div>
<div style="font-weight: normal; margin-bottom: 0.12in;">
All the code
that comprises the base foundation needed for creation of any Qubes variant
(so <span style="font-family: FreeMono, monospace;">core-admin</span>, <span style="font-family: FreeMono, monospace;">gui-common</span>,
<span style="font-family: FreeMono, monospace;">gui-daemon</span>, <span style="font-family: FreeMono, monospace;">qubes-builder</span>
and <span style="font-family: FreeMono, monospace;">qubes-manager</span>) will be
kept open source, GPL specifically. Additionally all the code needed
for building of Xen-based Qubes OS with Linux-based AppVMs and
Linux-based GUI and Admin domains, will continue to be available as
open source. This is to ensure Qubes OS R3 that will be based on this
framework, can remain fully open source (GPL).</div>
<div style="font-weight: normal; margin-bottom: 0.12in;">
Additionally we
plan to double-license this core open source code to vendors who
would like to use it in proprietary products and who would not like
to be forced, by the GPL license, to share the (modified) sources.</div>
<div style="font-weight: normal; margin-bottom: 0.12in;">
All the other
modules, especially those developed to support other VMMs (Hyper-V,
Virtual Box, Windows Native Isolation), as well as those to support
Windows OS (<span style="font-family: FreeMono, monospace;">gui-agent-windows</span>,
<span style="font-family: FreeMono, monospace;">core-agent-windows</span>,
<span style="font-family: FreeMono, monospace;">core-admin-windows</span>, etc) will
most likely be proprietary and will be available only to vendors who
decide to work with us and buy a license.</div>
<div style="font-weight: normal; margin-bottom: 0.12in;">
So, if you want
to develop an open source product that uses Qubes framework, then you
can freely do that as all the required core components for this will
be open sourced. But if you would like to make a proprietary product,
then you should buy a license from us. I think this is a pretty fair
deal.
</div>
<div style="font-weight: normal; margin-bottom: 0.12in;">
<b>Current
status and roadmap</b></div>
<div style="font-weight: normal; margin-bottom: 0.12in;">
We're currently
working on two fronts: one is rewriting current Qubes code to support
Qubes HAL, while the other one is adding a backend for Windows Native
Isolation (which also involves doing things such as GUI isolation right on Windows).</div>
<div style="font-weight: normal; margin-bottom: 0.12in;">
We believe that by implementing two such extreme backends:
Xen and Windows Native Isolation we can best show the flexibility of
the framework (plus our customer is especially interested in this
backend;)</div>
<div style="font-weight: normal; margin-bottom: 0.12in;">
We should be able to publish some code, i.e. the framework
together with early Qubes OS R3 that will be based on it, sometime in
fall or maybe earlier.</div>
<div style="font-weight: normal; margin-bottom: 0.12in;">
We obviously
are determined to further develop Xen-based Qubes OS, because we
believe this is the most practically secure OS available today, and we believe such OS should be open source.</div>
<div style="font-weight: normal; margin-bottom: 0.12in;">
Qubes R2 will still be based on the
Xen-hardcoded code, because it's close to the final release and we
don't want to introduce such drastic changes at this stage. The only
thing that Qubes R2 will get in common with Qubes Odyssey is this new
source code layout as presented above (but still with hardcoded xl
calls and xen-vchan).</div>
<div style="font-weight: normal; margin-bottom: 0.12in;">
So, this is all
really exciting and a big thing, let's see if we can change the industry with this :)</div>
<div style="font-weight: normal; margin-bottom: 0.12in;">
Oh, and BTW,
some readers might be wondering why the framework was codenamed
“Odyssey” -- this is obviously because of the “HAL” which plays a
central role here, and which, of course, also brings to mind the
famous Kubrick's movie.</div>
<div style="font-weight: normal; margin-bottom: 0.12in;">
</div>
Joanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.com16tag:blogger.com,1999:blog-24586388.post-75599193554474714482013-02-28T19:26:00.002+01:002013-02-28T19:26:09.671+01:00Qubes 2 Beta 2 has been released!<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://wiki.qubes-os.org/trac/wiki/QubesScreenshots" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="225" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhP0l0JrtaG6VRLoDpKEzP6lKV_Yej9MNxYqHWXJbtOwXI6FmzoJ06ceh1nIOgiDNVIHAEKiFtXPPBUTDY8Fy1sfbx54Ust_bgUS66H6LqlW1uj70oLuDkSl1u5NCyGkSLAmZwZ/s400/r2b2-kde-start-menu.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><a href="http://wiki.qubes-os.org/trac/wiki/QubesScreenshots">Qubes R2 Beta 2 with KDE 4.9 environment (click for more screenshots)</a></td></tr>
</tbody></table>
<br />
<style type="text/css">
<!--
@page { margin: 0.79in }
P { margin-bottom: 0.08in }
A:link { so-language: zxx }
-->
</style>
<br />
<div style="margin-bottom: 0in;">
We're progressing fast and today I
would like to announce the release of Qubes R2 Beta 2 ISO. The
installation and upgrade instructions, as well as the ISO itself, can be
found via the <a href="http://wiki.qubes-os.org/trac/wiki/QubesDownloads">our wiki page</a>.
As usual, please remember to verify the digital signature of the
downloaded ISO.</div>
<div style="margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
The major changes in this beta release
include:</div>
<style type="text/css">
<!--
@page { margin: 0.79in }
P { margin-bottom: 0.08in }
A:link { so-language: zxx }
-->
</style>
<div style="margin-bottom: 0in;">
<style type="text/css">
<!--
@page { margin: 0.79in }
P { margin-bottom: 0.08in }
A:link { so-language: zxx }
-->
</style>
</div>
<ul>
<li><div style="margin-bottom: 0in;">
Upgraded Dom0 distribution to the
latest Fedora 18 (all previous releases used Fedora 13 for Dom0!)</div>
</li>
<li><div style="margin-bottom: 0in;">
Upgraded default VM template also
to Fedora 18</div>
</li>
<li><div style="margin-bottom: 0in;">
Upgraded Dom0 kernel to 3.7.6</div>
</li>
<li><div style="margin-bottom: 0in;">
Upgraded KDE environment in Dom0
(KDE 4.9)</div>
</li>
<li><div style="margin-bottom: 0in;">
Introduced Xfce 4.10 environment
for Dom0 as an alternative to KDE</div>
</li>
<li><div style="margin-bottom: 0in;">
A few other fixes and
improvements, including the recently discussed Disposable VM-based
<a href="http://theinvisiblethings.blogspot.com/2013/02/converting-untrusted-pdfs-into-trusted.html">PDF converter</a></div>
</li>
</ul>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
The upgrade of the Dom0 distribution and
kernel should significantly improve hardware compatibility – one of
the major problems with Qubes adoption so far, as we hear. Now, with the latest GPU drivers and Xorg packages, I hope we will be
able to cover a much boarder range of hardware (especially all the
newer GPUs).</div>
<div style="margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
The upgrade of KDE in Dom0 is mostly an
eye-candy type of improvement (but then, who doesn't like eye
candies!), as is the introduction of the Xfce4 as its alternative,
although, arguably, Xfce4 is considered faster and lighter than KDE.
In Qubes the choice of an actual desktop environment that runs in
Dom0 is not as important as it is on traditional Linux systems, I think,
simply because most of the functionality, typically provided by such
environments, such as apps and file management, is simply...
disabled, because on Qubes there are no user apps or files in Dom0.
</div>
<div style="margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
Nevertheless people love and hate
particular window managers and environments, and we hope that now, by
supporting alternative environments, we could appeal to even more
users.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
I'm glad that we just completed this
difficult phase of upgrading Qubes Dom0 distribution (for the first
time since Qubes R1 Beta 1!) -- this forced us to clean up the code
and prepare for some even bigger and bolder changes in the near
future. But those will come only in Release 3. As far as Release 2 is considered, we do have quite <a href="http://wiki.qubes-os.org/trac/report/3">a few more tickets</a> scheduled
for R2 Beta 3 milestone, but most of those represent various addons,
rather than modifications to Qubes core software.</div>
<div style="margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
So what are those brave changes that
are to happen in Release 3? That I will write about in a separate
blog post... Stay tuned!</div>
<div style="margin-bottom: 0in;">
<br />
</div>
<div style="margin-bottom: 0in;">
So, please enjoy this latest Qubes R2 beta release, and be sure to send all your questions and comments, as well as
the HCL info, to the <a href="http://wiki.qubes-os.org/trac/wiki/QubesLists">qubes-devel mailing list</a><a href="https://wiki.qubes-os.org/trac/wiki/QubesLists"></a>.
I have already upgraded my primary laptop to this release a few days
ago and everything seems to be working fine, so fear not!</div>
Joanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.com6tag:blogger.com,1999:blog-24586388.post-63019189616269503952013-02-21T20:07:00.001+01:002013-02-21T20:07:29.049+01:00Converting untrusted PDFs into trusted ones: The Qubes Way<div class="tr_bq">
<style type="text/css">
<!--
@page { margin: 0.79in }
P { margin-bottom: 0.08in }
A:link { so-language: zxx }
</style>
</div>
<div style="margin-bottom: 0in;">
Arguably one of the biggest challenges
for desktop security is how to handle those overly complex PDFs,
DOCs, and similar files, that are so often exchanged by people, or
downloaded from the Web, and that often provide a way for the
attacker to <a href="http://blogs.mcafee.com/mcafee-labs/analyzing-the-first-rop-only-sandbox-escaping-pdf-exploit">compromise</a> the user's desktop
system.<br />
<br /></div>
<div style="margin-bottom: 0in;">
Today I would like to discuss a recent
innovation we created for Qubes OS that allows to securely convert
those pesky PDFs (as well as essentially any graphics files) into
<i>trusted</i><span style="font-style: normal;"> PDFs. Here by a
“trusted PDF” I mean a file that should be </span><i>harmless</i><span style="font-style: normal;">
to the user's system, so, a non-malicious PDF.</span></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgPXvPr8vJ99JlPF4urQ8_kYO6ZqpAffh6fdbIWN9FaF9jnrxrHhDREODqQRB3GnUDivB4Pt35TMioHap7BCgnn1k2O98TOdK7pi4MBL4aXF_kVYqN4FymPDVPpUEojVqSA3lH-/s1600/r2b2-converting-pdf-2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="180" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgPXvPr8vJ99JlPF4urQ8_kYO6ZqpAffh6fdbIWN9FaF9jnrxrHhDREODqQRB3GnUDivB4Pt35TMioHap7BCgnn1k2O98TOdK7pi4MBL4aXF_kVYqN4FymPDVPpUEojVqSA3lH-/s320/r2b2-converting-pdf-2.png" width="320" /></a></div>
<div style="margin-bottom: 0in;">
<br /></div>
<span style="font-style: normal;">A few
years ago, we have already introduced a mechanism in Qubes OS called
<a href="http://theinvisiblethings.blogspot.com/2010/06/disposable-vms.html">Disposable VMs</a>,
that can be used to </span><i>safely</i><span style="font-style: normal;">
open any file, including PDFs, DOCs, etc. The file is being opened in
a... well a dedicated disposable VM that is created within seconds
(typically below 5 seconds) and all the file processing and rendering
happens inside this VM. Once the document is closed, the disposable
VM is automatically destroyed, and any changes to the file (e.g. if
the was an editable DOC file) are automatically propagated back into
the original file. This mechanism is very powerful, and I often use
it for my daily work. However, it surely is a bit cumbersome – who
wants to wait 5 seconds for the PDF to open, especially if I have a
dozen of invoices to look through! So, today I present an alternative
approach...</span><br />
<span style="font-style: normal;"> </span> <br />
<b>Approaches to converting PDFs</b><br />
<br />
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">The
problem of converting a potentially untrusted PDF into a harmless one
is certainly not a new one. Some tools have already be created for
this task.</span><br />
<br />
<span style="font-style: normal;">The typical approach is to parse the original PDF, look
for “potentially dangerous things” there, and remove them. As
simple as that! This is, of course, a typical AntiVirus approach to
the problem. And, typically as it is for most AV approaches, it's
completely useless against any more skilled and determined attacker
(and these are the ones we fear the most, don't we?).</span></div>
<div style="margin-bottom: 0in;">
<br />
<span style="font-style: normal;">A
somehow better approach is to parse the original PDF, disassemble it
into pieces, and then reassemble them into a new PDF only using the
“trusted” pieces – this, I think, could be called a
whitelisting approach.</span></div>
<div style="margin-bottom: 0in;">
<br />
<span style="font-style: normal;">Anyway,
the fundamental problem with the approaches mentioned above, is that
all of them require </span><i>parsing</i><span style="font-style: normal;">
of the original PDF file. And parsing is where the “big bang”
usually happens. Parsing is where our, normally pretty decent, code,
comes in close, intimate contact with some unknown complex input
data, which often leads to a successful abuse or exploitation.</span></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">
<style type="text/css">
<!--
@page { margin: 0.79in }
P { margin-bottom: 0.08in }
A:link { so-language: zxx }
</style>
</span></div>
<div style="margin-bottom: 0in;">
<br />
<b><span style="font-style: normal;">Parsing
PDFs safely</span></b></div>
<div style="margin-bottom: 0in;">
<br />
<span style="font-style: normal;">So,
how to perform parsing safely? Of course, that's simple! Let's run
the parser in an isolated container – in case of Qubes we already
have an ideal such container: it's the Disposable VMs.</span></div>
<div style="margin-bottom: 0in;">
<br />
<span style="font-style: normal;">But,
before we get too excited, let's think more about it – say we run
the parser safely isolated in a Disposable VM, meaning it couldn't
harm any of the rest of the system, except for the Disposable VM
itself, which we however won't worry much about, because it is
disposable... But then what?</span><br />
<br />
<span style="font-style: normal;">We want our PDF back in our original VM,
to actually use it, right? But we cannot just copy the result from
the Disposable VM, because if it got compromised, as a result of
parsing of the malicious PDF, then we would like get... a compromised
converted PDF. So, this approach gives us </span><i>nothing!</i><br />
<br />
<span style="font-style: normal;">(Even though our “solution” incorporates all the obligatory
buzzwords: “Disposable VMs” (“Micro Disposable VMs”?), “VMs
isolated using hardware Intel vPRO technology” and, of course, the
“hypervisor”! Sometime just the mere fact we use “hardware
virtualization” buys us nothing... People seem to forget about this
sometimes.)</span></div>
<div style="margin-bottom: 0in;">
<br />
<span style="font-style: normal;">So,
the trick to make this approach meaningful is to introduce what I
will call a “Simple Representation” of the input file. More on
this, straightforward concept, below. The idea is that our parser
(that runs in a Disposable VM) will be </span><i>expected</i><span style="font-style: normal;">
to return the Simple Representation of the original PDF. Of course,
it might very well go wild (as a result of exploitation by the PDF it
parses), and don't obey our expectations, and instead return
something totally different and potentially malicious. But that
doesn't matter! The whole point of the Simple Representation is that
it should be, well... simple to parse it safely and discard in case
what we're getting doesn't look like the Simple Representation.</span></div>
<div style="margin-bottom: 0in;">
<br />
<span style="font-style: normal;">Ok, so
what's the simplest possible representation of an arbitrary PDF file?
Yes, it's the RGB format, which is essentially just a raw array of
RGB values for each pixel. In fact, I'm not sure there could be
anything simpler in the Known Universe to represent a PDF file...</span></div>
<div style="margin-bottom: 0in;">
<br />
<span style="font-style: normal;">Now
this is all becoming simple: we would expect our parser to send us
just two things: the dimensions (W<span style="font-family: Liberation Serif,serif;"><span style="font-size: small;"> </span></span>x H) of the bitmap representation of
each of the page of the PDF in question, and each of the PDF page
itself converted into a raw RGB format. If the parser didn't obey, we
would still interpret whatever stream of bytes we get as a RGB bitmap
– in the worst case the PDF we create would look like un-tuned
analog TV screen.</span><br />
</div>
<div style="margin-bottom: 0in;">
<br />
<span style="font-style: normal;">The
diagram below summaries this idea:</span></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg8zC00KcqD0wjhLdSND7Xkn7hY2d92bsLErD2BmJspY_pck1-D1ovcwZOgZgfsFEYG4QLf-4n61rsLd6R6BL7B5hn92JPe20ZSjFxDSdS2qOXLYS2473AnIOtG7jNIFm0Xtvaj/s1600/pdf-conversion.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg8zC00KcqD0wjhLdSND7Xkn7hY2d92bsLErD2BmJspY_pck1-D1ovcwZOgZgfsFEYG4QLf-4n61rsLd6R6BL7B5hn92JPe20ZSjFxDSdS2qOXLYS2473AnIOtG7jNIFm0Xtvaj/s320/pdf-conversion.png" width="320" /></a></div>
<div style="margin-bottom: 0in;">
<br />
<style type="text/css">
<!--
@page { margin: 0.79in }
P { margin-bottom: 0.08in }
A:link { so-language: zxx }
</style>
</div>
<br />
<div style="margin-bottom: 0in;">
<b><span style="font-style: normal;">Implementing
this all on Qubes</span></b></div>
<div style="margin-bottom: 0in;">
<br />
<span style="font-style: normal;">Now I
would like to show how easy it is to implement such PDF converter
service using the Qubes advanced infrastructure that we call <a href="http://wiki.qubes-os.org/trac/wiki/Qrexec">qrexec</a>, and which is part of
Qubes core for quite some time now.</span></div>
<div style="margin-bottom: 0in;">
<br />
<span style="font-style: normal;">First,
let's choose the PDF and image conversion tools. The choice of PDF
converter is not security critical, because it will run in an
isolated Disposable VM. Here I decided to use pdftocairo converter,
which is part of the poppler-utils package on Fedora. We will also
use ImageMagick's “convert” command to convert the PNG files
(produced by pdftocairo, one for each PDF page) to the raw RGB
format. Incidentally ImageMagick <a href="http://www.imagemagick.org/script/formats.php">supports RGB format</a> natively.
As mentioned above, in addition to sending the raw RGB file, we would
also need to send the width and height of the pixmap – those can
easily be obtained using ImageMagick's “identify” command. Again,
all those programs discussed so far are not security critical –
they might get exploited during the processing of the untrusted input
PDF file, and we don't worry about that at all.</span></div>
<div style="margin-bottom: 0in;">
<br />
<span style="font-style: normal;">On the
receiving side, however, we need to use a foolproof parser for the
RGB format. Again, this is what we gain in this whole process –
instead of requiring a
foolproof-and-also-being-able-to-produce-non-malicious-PDFs parser,
we only require a foolproof RGB parses, and that's quite a gain! The
ImageMagick's convert comes to mind again here, and one might want to
use it like this:</span></div>
<br />
<blockquote>
<span style="font-family: "Courier New",Courier,monospace;">convert page.rgb page.pdf</span></blockquote>
<br />
<span style="font-style: normal;">Unfortunately
this would be wrong, because the convert program would still try to
detect the “real” format of the page.rgb file, and, if it looked
more like, say, JPEG or PDF, it would parse it accordingly,
compromising all our careful plan! What we really need is to tell our
convert program to always treat the input as raw RGB file, instead of
trying to be (too) smart and trying to guess the format by itself.
This can be achieved by adding the “rgb:” prefix in front of the
input argument, which provides explicit input format specification:</span><br />
<div style="margin-bottom: 0in;">
<br />
<blockquote class="tr_bq">
<span style="font-family: "Courier New",Courier,monospace;">convert -size ${IMG_WIDTH}x${IMG_HEIGHT} -depth ${IMG_DEPTH} rgb:$RGB_FILE pdf:$PDF_FILE </span></blockquote>
<br /><span style="font-style: normal;">Now
also needed to add size and depth explicitly, because the raw RGB
format doesn't convey such information (well, it has no header of any
sort at all!). Of course we need to obtain the width and height from
the parser, but we can validate such input rather easily. In addition
we make sure that the received RGB file has exactly the size as
indicated by width and height. With those precautions in place, there
would have to be really a </span><i><span style="font-style: normal;">gapping</span></i><span style="font-style: normal;"><span style="text-decoration: none;">
hole in the ImageMagic's RGB parsing code for the attacker to exploit
this. Perhaps instead of using the ImageMagick's convert I should
have written a small script in python that would parse the received
RGB file (and save it into a... RGB file, for later processing by
ImageMagick), but I sincerely think this would be an overkill here. </span></span></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;"><span style="text-decoration: none;"> </span></span>
</div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">Finally we can write the following two simple bash scripts, one for client: </span><a href="http://git.qubes-os.org/gitweb/?p=joanna/qpdf-converter.git;a=blob;f=qpdf-convert-client;h=e8ff2f816da9bdeffd4a0f3f8b177766fd7ac067;hb=HEAD"><span style="font-family: Courier 10 Pitch;"><span style="font-style: normal;">qpdf-convert-client</span></span></a>, and the other one, <a href="http://git.qubes-os.org/gitweb/?p=joanna/qpdf-converter.git;a=blob;f=qpdf-convert-server;h=944345d231f0f94eabedfbaf34e4753f4509fdb5;hb=HEAD">qpdf-convert-server</a>, for the server (which runs in a Disposable VM).<br />
<br /></div>
<div style="margin-bottom: 0in;">
Additionally we also need to create a
policy file in Dom0 in <span style="font-family: Courier 10 Pitch;">/etc/qubes_rpc/policy/</span>
to allow to use this service. The policy file content for this service should
look like this:<br />
<br />
<blockquote class="tr_bq">
<span style="font-family: "Courier New",Courier,monospace;">$anyvm $dispvm allow</span><br /><span style="font-family: "Courier New",Courier,monospace;"></span></blockquote>
<br />... which is pretty self explanatory.
When I do development I also add another line to the policy file like this:<br /><br />
<blockquote class="tr_bq">
<span style="font-family: "Courier New",Courier,monospace;">$anyvm devel-vm ask</span><br /><span style="font-family: "Courier New",Courier,monospace;"></span></blockquote>
<br />
... to allow me to run the server inside
my 'devel-vm' VM, instead of running it in Disposable VM every time,
which would be very inconvenient for development, as it would require
me to update the Disposable VM template each time I wanted to test a
new version of qpdf-convert-server.</div>
<div style="margin-bottom: 0in;">
<br />
The policy file should be placed in
Dom0 in <span style="font-family: Courier 10 Pitch;">/etc/qubes_rpc/policy/qubes.PdfConvert</span>
file – here the name of the file must be the same as the name of
the service, as invoked via <span style="font-family: Courier 10 Pitch;">qrexec_client_vm</span>
command, discussed below.</div>
<div style="margin-bottom: 0in;">
<br />
And, one last thing, in the destination
VM we must also create a file that will map the service name (so, the
<span style="font-family: Courier 10 Pitch;">qubes.PdfConvert</span> in our example)
to the actual binary that should be called in the VM when the service
is invoked. So, the file should be named:
<span style="font-family: Courier 10 Pitch;">/etc/qubes_rpc/qubes.PdfConvert</span>
(again, this is now in a VM, not in Dom0, also note the lack of
<span style="font-family: Courier 10 Pitch;">policy/</span> subdir), and it is
another one-liner with the following content:<br /><br />
<blockquote class="tr_bq">
<span style="font-family: "Courier New",Courier,monospace;">/usr/lib/qubes/qpdf-convert-server</span><br /><span style="font-family: "Courier New",Courier,monospace;"></span></blockquote>
<br />
The full source code of qpdf-converter can be seen and downloaded from <a href="http://git.qubes-os.org/gitweb/?p=joanna/qpdf-converter.git;a=tree">this git repo</a>.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
We're ready now to test our
<span style="font-family: Courier 10 Pitch;">qubes.PdfConvert</span> service: in the
requesting VM, i.e. the one from which we want to initiate the
conversion process we do:</div>
<div style="margin-bottom: 0in;">
<br /></div>
<blockquote class="tr_bq">
<div style="margin-bottom: 0in;">
<span style="font-family: "Courier New",Courier,monospace;"><span style="font-family: Courier 10 Pitch;">[user@work
Downloads]$ /usr/lib/qubes/qrexec_client_vm '$dispvm'
qubes.PdfConvert /usr/lib/qubes/qpdf-convert-client ITLquote.pdf </span></span>
</div>
<div style="margin-bottom: 0in;">
<span style="font-family: "Courier New",Courier,monospace;"><span style="font-family: Courier 10 Pitch;">->
Sending file to remote VM...</span></span></div>
<div style="margin-bottom: 0in;">
<span style="font-family: "Courier New",Courier,monospace;"><span style="font-family: Courier 10 Pitch;">->
Waiting for converted samples...</span></span></div>
<div style="margin-bottom: 0in;">
<span style="font-family: "Courier New",Courier,monospace;"><span style="font-family: Courier 10 Pitch;">->
Receving page 2 out of 2...</span></span></div>
<div style="margin-bottom: 0in;">
<span style="font-family: "Courier New",Courier,monospace;"><span style="font-family: Courier 10 Pitch;">->
Merging pages into a single PDF document...</span></span></div>
<div style="margin-bottom: 0in;">
<span style="font-family: "Courier New",Courier,monospace;"><span style="font-family: Courier 10 Pitch;">->
Converted PDF saved as: ITLquote.trusted.pdf</span></span></div>
<div style="margin-bottom: 0in;">
<span style="font-family: "Courier New",Courier,monospace;"><span style="font-family: Courier 10 Pitch;">->
Original file saved as .ITLquote.pdf</span></span></div>
</blockquote>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
Again, for development process I would
replace '$dispvm' with something like 'devel-vm'.</div>
<div style="margin-bottom: 0in;">
<br />
The <span style="font-family: Courier 10 Pitch;">qrexec_client_vm</span>
command, used above, is not actually intended to be used by user
directly (that's why it's installed in /usr/lib/qubes instead of
/usr/bin/), and so when one creates a Qubes qrexec service, it's
customary to create also a small wrapper around qrexec, like <a href="http://git.qubes-os.org/gitweb/?p=joanna/qpdf-converter.git;a=blob;f=qvm-convert-pdf;h=2a1c2ebd72d4a6e0ac275d1828c47f62bbb59bf5;hb=HEAD">this one</a>, that makes
using the service simple.</div>
<div style="margin-bottom: 0in;">
<br />
The presented converter saves the
original file as <span style="font-family: Courier 10 Pitch;">.${original_pdf}</span>
making it a hidden file to help the user avoid accidental opening.
The new, converted file gets <span style="font-family: Courier 10 Pitch;">.trusted.pdf</span>
suffix appended to the base name of the original file. I discuss more
issues regarding the human factor and avoiding accidental opening in
one of the next paragraphs below. The converter can also be used to convert essentially any image file, such as JPEG, PNG, etc, into a
PDF, using the same method.</div>
<div style="margin-bottom: 0in;">
<br />
As you can see creating client-server
services in Qubes is very simple – in fact it took me just one afternoon to get the inital working version of the converter (with subsequent "polishing" over the next 2 days).<br />
<br /></div>
<div style="margin-bottom: 0in;">
The qrexec infrastructure takes care
about all the under-the-hood tasks, such as starting the necessary
VMs, e.g. creating Disposable VM to handle the service
request,establishing communication channels between VMs (which are
ultimately implemented on top of Xen's shared memory), redirecting
client and server's stdin and stdout to each other, so that writing
services is very simple, even in shell, and, of course, obeying
policies defined centrally in Dom0.</div>
<div style="margin-bottom: 0in;">
<br />
Most “inter-VM” features in Qubes,
such as secure file copy between domains, opening files in Disposable
VMs, time synchronization, appmenus synchronization, etc, are all
implemented on top of qrexec. A notable exception is clipboard
exchange, which is implemented as part of the GUI protocol, but still
uses the same common qrexec code for policy processing (e.g. I use
this policy to block clipboard and file exchanges between my work and
personal domains).</div>
<div style="margin-bottom: 0in;">
<br />
<b>Limitations, other Simple
Representations</b></div>
<div style="margin-bottom: 0in;">
<br />
The obvious disadvantage of converting
a PDF to an RGB representation is that one looses text search, as
well as copy and edit capabilities (e.g. in case of PDF forms). So,
converting Intel's IA32 Software Developer's Manual this way would
certainly not be a good idea... But, hey, such large PDFs can always
be opened in a Disposable VM – they would be fully functional then,
only that you would need to wait a few seconds for the PDF window to
pop up. Or, better yet, why not keep all such PDFs in a dedicated
domain? E.g. I have a VM called “work-pub” where I keep tons of
various, publicly available PDFs, such as the mentioned Intel's SDM,
as well as various chipset docs, conferences papers and slides, and
generally lots of stuff. The key point is that all in this VM is
<i>public </i><span style="font-style: normal;">material (and also all
is related to my work), so that I don't really care if any of those
PDFs compromises my work-pub domain. In the worst case, I will revert
the VM from backup and download any missing PDFs again from the web.
They are public after all. </span><br />
<span style="font-style: normal;"> </span>
</div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">But
the PDF conversion described above comes extremely useful in case of
all the various invoices, Purchase Orders, NDAs, contracts, and
god-knows-what-else PDF documents, which I'm forced to deal with in
my “work” domain (where my email client runs). Most of those are
one pagers, or maximum a few pages long documents, so the fact that
they got converted to a bitmap provides me with very little
discomfort. At the same time I gain incredible freedom in opening all
those documents natively in my work VM, without fearing that one of
those invoices will comrpomise my work domain (which would be a
rather sad thing for me, although the really sensitive stuff is still
in some other domains ;)</span></div>
<div style="margin-bottom: 0in;">
<br />
<span style="font-style: normal;">An
interesting question is, however, can we come up with another form of
Simple Representation that would allow e.g. to preserve the text
searching ability of the converted PDFs (and DOCs, PPTs)? Probably...
yes. The choice of the Simple Representation should be thought of as
of a trade-off between security and document's features preservation.
I'm not an expert on PDF and DOC formats (and I'm not sure I want to
be) but it seems plausible that one could disassemble PDF into simple
pieces, select the really simple ones, send those pieces as a Simple
Representation back to client, and have them reassembled back into a
almost-fully-functional PDF. Here, again, the point is that the PDF
parsing is done in isolated Disposable VM, while the reassembly in
the trusted VM. Anyway, let me leave it as a exercise for the reader
:)</span><br />
<span style="font-style: normal;"> </span><style type="text/css">
<!--
@page { margin: 0.79in }
P { margin-bottom: 0.08in }
A:link { so-language: zxx }
</style>
</div>
<div style="margin-bottom: 0in;">
<b>Preventing user mistakes</b></div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br />
Being able to
right-click on a PDF file and have it converted into a trusted PDF is
one thing. Having this mechanism adopted by users and actually making
their daily computing safer, is another story.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
Users will likely
have hundreds of PDF spread over their home directories, and the real
challenge is how to make sure that the user never accidentally opens
the unconverted, untrusted PDF. We can think of several approaches to
this problem:</div>
<ul>
<li><div style="font-weight: normal; margin-bottom: 0in;">
We modify the
Thunderbird, Firefox, etc, e.g. by providing specific plugins, to
always perform PDF conversion on each file that we got via email or
downloaded from the Web. Additionally we convert all the already
present PDFs in the user's home directory (file system?). And,
additionally, we modify Qubes file copy operation to also always do
automatic PDF conversion whenever one transfers files from other
domains (if Qubes qrexec policy allows for such transfer in the
first place, of course).</div>
</li>
</ul>
<div style="font-weight: normal; margin-bottom: 0in;">
<br />
This approach
would not be optimal, because some PDFs, as we discussed above, might
not be well suited for conversion-through-bitmap process – they
might be large PDFs where text search is crucial, some conference
papers for review, where text copy is crucial, or some editable
forms. That's why it seems better to take a slightly different
approach:</div>
<ul>
<li><div style="margin-bottom: 0in;">
<span style="font-weight: normal;">We
modify mime handlers for PDF files (as well as any other files that
our converter supports) and then upon every opening of the file
(e.g. via mouse click in a file manager) our program gets to run and
its job is to determine whether the file should be opened natively,
converted to a trusted PDF, or perhaps opened in a Disposable VM. Of
course, upon “first” opening we should probably ask the user
about the decision, if this cannot be determined automatically. E.g.
if we can reliably determine the file is already converted, we can
safely open it without prompting the user, but if it's not, we
should ask – perhaps the user would like to open it in a
Disposable VM instead of converting, or perhaps the file should be
considered trusted anyway, because it was created by the user
herself.</span></div>
</li>
</ul>
<div style="font-weight: normal; margin-bottom: 0in;">
<br />
This second
approach seems like a way to go, and we will likely implement it
sooner or later (probably sooner, but after the upcoming R2 Beta2).
It should also be noted, that typically user would need such
mechanism only in some domains – e.g. I really feel the need for
such protection in my “work” domain, but not in any other. But
that, of course, depends on how one partitions their digital life
into security domains.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br />
One important
detail worth mentioning here, is that we should unconditionally
disable “Thumbnail View” in whatever file manager we use (which
itself is really a stupid feature – can people not read filenames
anymore or something?). <br />
<br /></div>
<b>Qubes: from containers isolation down to apps protection</b><br />
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
The mechanism introduced today, in
addition to the Disposable VMs mechanism introduced earlier,
represents a trend in Qubes development of “stepping down” into
AppVMs in order to also make the VMs themselves somehow more secure
(in addition to the isolation <i>between</i> the VMs).</div>
<div style="margin-bottom: 0in;">
<br />
Originally Qubes aimed at containers
isolation only. This included protecting the system TCB where
techniques such as deprivileged networking stacks (and optionally
also deprivileged USB stacks) have been deployed, as well as custom
GUI virtualization, and generally somehow “hardened” Xen
configuration. This also included protecting the VMs from each other,
where techniques such as secure clipboard, secure file copy and
generally secure qrexec infrastructure have been introduced, as well
as trusted GUI subsystem with explicit domain decorations.</div>
<div style="margin-bottom: 0in;">
<br />
But now, Qubes is stepping down into
the AppVMs in order to make the VMs themselves also less prone to
compromise. We surely will be working on more such mechanisms in the
future. We still are only at the beginning of the quest to create a
Reasonably Secure Desktop OS!<br />
<br />
<i>PS.</i> The presenetd converter will be part of the Qubes R2 Beta 2, that is expected to be released... in the comming days. Experienced users of Qubes R1 and R2 Beta 1 can install the converter immediately by building the rpm<span style="font-size: small;">s</span> from the git repo.<br /><br /><br /><span style="font-size: x-small;"><i>PS.</i> WTF is happening with the Blogger web interface? Seriously, I don't remember being so frustrated using any software in the recent years that I am right now, when editing this post (as well as the last several ones). It sometimes honours the line breaks, sometimes do not, sometimes inserts a couple of new lines, sometime removes them, sometime mysterious spaces appear at the end of lines, sometime those cannot be removed... It doesn't allow to paste pre-formatted code-listing (at least I couldn't figure out how to make it honour tabs). And yes, I'm using the "Compose mode", because when I try to switch to the HTML mode, not only I'm overwhelmed with tons of HTML markups, nobody knows what for, but also when I switch back to the Compose mode, my article tends to get even more fucked up! Really, a shame. I wish I could go away to some other blogging service, but I'm afraid that converting all my posts would be even a bigger PITA... Sigh.</span></div>
<div style="margin-bottom: 0in;">
</div>
<div style="margin-bottom: 0in;">
</div>
Joanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.com23tag:blogger.com,1999:blog-24586388.post-43709385764596560692012-12-14T13:42:00.001+01:002012-12-15T12:46:38.198+01:00Qubes 2 Beta 1 with initial Windows support has been released!<style type="text/css">
<!--
@page { margin: 0.79in }
P { margin-bottom: 0.08in }
A:link { so-language: zxx }
</style>
<br />
<div style="margin-bottom: 0in;">
It's my pleasure to announce the first Beta for Qubes Release 2 is now available for <a href="http://wiki.qubes-os.org/trac/wiki/QubesDownloads">download</a>.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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 <a href="http://theinvisiblethings.blogspot.com/2012/03/windows-support-coming-to-qubes.html">in the past</a>.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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).</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
More information about creating and
using HVM domains, including Windows-based AppVMs, can be found in the wiki <a href="http://wiki.qubes-os.org/trac/wiki/HvmCreate">here</a>.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
To summary, here's a quick list of some
of the exciting new features that toady's release brings in:</div>
<ul>
<li><div style="margin-bottom: 0in;">
Support for generic fully
virtualized VMs (without qemu in the TCB!)</div>
</li>
<li><div style="margin-bottom: 0in;">
Support for Windows-based AppVMs
integration (clipboard, file exchange, qrexec, pv drivers)</div>
</li>
<li><div style="margin-bottom: 0in;">
Secure audio input to select
AppVMs (Hello Skype users!)</div>
</li>
<li><div style="margin-bottom: 0in;">
Clipboard is now also controlled by
central policies, unified with other qrexec policies.</div>
</li>
<li><div style="margin-bottom: 0in;">
Out of the box TorVM support</div>
</li>
<li><div style="margin-bottom: 0in;">
Experimental support for PVUSB</div>
</li>
<li><div style="margin-bottom: 0in;">
Updated Xorg packages in Dom0 to
support new GPUs</div>
</li>
<li><div style="margin-bottom: 0in;">
DisposableVM customization
support</div>
</li>
<li><div style="margin-bottom: 0in;">
... and, as usual, various fixes
and other improvements :)</div>
</li>
</ul>
<div style="margin-bottom: 0in;">
Existing users of Qubes R1 can upgrade
without needing to reinstall – the upgrade procedure is described
<a href="http://wiki.qubes-os.org/trac/wiki/UpgradeToR2">here</a>.
Standard installation is described <a href="http://wiki.qubes-os.org/trac/wiki/InstallationGuideR2">here</a>.
</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
Enjoy!</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
PS. Please send all the technical questions to the <a href="http://wiki.qubes-os.org/trac/wiki/QubesDownloads">qubes-devel mailing list</a>, instead posting them as comments to this blog. Keep the comments here for more generic discussions.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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 <a href="http://wiki.qubes-os.org/trac/wiki/QubesDownloads">here</a>. 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.</div>
Joanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.com20tag:blogger.com,1999:blog-24586388.post-36479549729533461452012-09-12T19:02:00.000+02:002012-11-02T18:35:40.451+01:00How 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.<br />
<ul><b>
<li><b>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?</b></li>
</b></ul>
<b>
</b>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 <a href="http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html">some time ago</a>.
Proper GUI-level isolation was one of the main goals for Qubes.<br />
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
Additionally, all the various drivers,
networking and USB stacks, are also hosted in the kernel, making
attacks via buggy networking
(e.g. via <a href="https://www.blackhat.com/presentations/bh-usa-07/Eriksson_Oberg_Nyberg_and_Jammar/Whitepaper/bh-usa-07-eriksson_oberg_nyberg_and_jammar-WP.pdf">buggy 802.11 stacks</a>
or <a href="http://theinvisiblethings.blogspot.com/2010/04/remotely-attacking-network-cards-or-why.html">buggy firmware</a>) or <a href="http://theinvisiblethings.blogspot.com/2011/06/usb-security-challenges.html">USB stacks</a> a practical possibility. And there is essentially nothing one can do
about it, when using an OS based on a monolithic kernel.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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.</div>
<ul><b>
<li><b>How is Qubes better than just
running a bunch of VMs in VMWare or Virtual Box?</b></li>
</b></ul>
<b>
</b>
<br />
<div style="margin-bottom: 0in;">
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.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
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 <a href="http://qubes-os.org/Screenshots.html">trusted Window Manager</a> 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 <a href="http://theinvisiblethings.blogspot.com/2011/09/playing-with-qubes-networking-for-fun.html">advanced networking setups</a>,
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).</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
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.</div>
<ul>
<li><b>How does Qubes compare to [your favourite academic microkernel]? </b></li>
</ul>
<div style="font-weight: normal; margin-bottom: 0in;">
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 <i>on top </i><span style="font-style: normal;">of</span>
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.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
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.</div>
<ul>
<li><b>How is Qubes better than Google
Chrome OS?</b></li>
</ul>
<div style="margin-bottom: 0in;">
</div>
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.<br />
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
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 <a href="http://gawker.com/5637234/gcreep-google-engineer-stalked-teens-spied-on-chats?skyline=true&s=i">their administrators</a>?</div>
<ul>
<li><b>How is Qubes better than [your
favorite commercial military-grade certified secure OS]?</b></li>
</ul>
<div style="margin-bottom: 0in;">
</div>
You must have
heard about the super secure military-grade, formally verified, 100%
certified, and generally “unbreakable” operating systems made by
companies such as <a href="http://www.ghs.com/products/rtos/integrity.html">Green Hills</a>,
<a href="http://www.lynuxworks.com/virtualization/secure-client-virtualization.php">Lynx Works</a>,
and others. How do they compare to Qubes OS?<br />
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
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...</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
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 ;)</div>
<ul>
<li><b>How is Qubes different than
Bromium's “micro virtualization” solution?</b></li>
</ul>
<div style="margin-bottom: 0in;">
</div>
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 <a href="http://www.bromium.com/misc/BromiumMicrovirtualization.pdf">whitepaper</a>
and there are Ian Pratt's presentation <a href="http://www.slideshare.net/xen_com_mgr/xen-14203926">slides from the recent XenSummit about u-Xen</a>, apparently a
hypervisor that is to be ultimately used in their upcoming product.<br />
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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<span style="font-style: normal;"> 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.</span></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">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.</span></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">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 </span><i>to bluepill</i><span style="font-style: normal;">
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.</span></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">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.</span></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">If I ever was to break the security of such a system, I would just follow the simple way:</span></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">1) Infect the host e.g. via one of the many <a href="http://www.slideshare.net/xen_com_mgr/xen-14203926">USB attacks</a> (remember they cannot have sandboxed USB driver domain, as they have only a type II hosted hypervisor),</span></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">2) Hook somewhere into the GUI subsystem and keep recoding all the interesting data from the screen...</span></div>
<div style="margin-bottom: 0in;">
... or something like that ;)</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">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...?)</span></div>
<ul>
<li><b>How is Qubes different from Xen
Client?</b></li>
</ul>
<div style="margin-bottom: 0in;">
</div>
In many aspects, <a href="http://www.citrix.com/English/ps2/products/feature.asp?contentID=2300345">Xen Client</a>
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.<br />
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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).</div>
<br />
<div style="text-align: center;">
<b>***</b></div>
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.<br />
<div style="margin-bottom: 0in;">
</div>
Joanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.com20tag:blogger.com,1999:blog-24586388.post-75173888911094154252012-09-03T11:28:00.000+02:002012-11-02T18:27:09.610+01:00Introducing Qubes 1.0!<style type="text/css">
<!--
@page { margin: 0.79in }
P { margin-bottom: 0.08in }
A:link { so-language: zxx }
</style>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
<a href="http://wiki.qubes-os.org/trac/wiki/InstallationGuide">this page</a>.
<br />
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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
<i>reasonably</i> secure desktop OS. In fact I cannot think of any more
secure alternative...</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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 <i>parts</i><span style="font-style: normal;">
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 <a href="http://theinvisiblethings.blogspot.com/2010/05/on-formally-verified-microkernels-and.html">this article</a>, and especially in <a href="http://theinvisiblethings.blogspot.com/2010/05/on-formally-verified-microkernels-and.html?showComment=1273715093988#c5446971095022574368">this comment</a> from the seL4 project leader.</span></div>
<div style="font-style: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-style: normal; margin-bottom: 0in;">
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.
</div>
<div style="font-style: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-style: normal; margin-bottom: 0in;">
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 ;)</div>
<div style="font-style: normal; margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">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 <a href="http://theinvisiblethings.blogspot.com/2011/03/partitioning-my-digital-life-into.html">partition her digital life</a> into security domains,
what <a href="http://theinvisiblethings.blogspot.com/2011/09/playing-with-qubes-networking-for-fun.html">network</a>
and other permissions each domain might have, whether to open a given
document in a <a href="http://theinvisiblethings.blogspot.com/2010/06/disposable-vms.html">Disposable VM</a>,
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.</span></div>
<div style="font-style: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-style: normal; margin-bottom: 0in;">
Generally Qubes OS
is an advanced tool for implementing Security by Isolation approach
on your desktop, using <i>domains </i>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.</div>
<div style="font-style: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-style: normal; margin-bottom: 0in;">
Thus people should
realize that by mere fact of using Qubes OS they won't become
automatically more secure – it's <i>how</i> 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 <a href="http://wiki.qubes-os.org/trac/wiki/SecurityGoals">difference that Qubes makes</a>, 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.</div>
<div style="font-style: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-style: normal; margin-bottom: 0in;">
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 <a href="http://wiki.qubes-os.org/trac/wiki/SecurityBulletins">already found</a> 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 <a href="http://wiki.qubes-os.org/trac/wiki/SecurityCriticalCode">this page</a>.
And I know there are individuals out there who apparently only been
waiting for Qubes 1.0 to come out, to <a href="http://twitter.com/0xcharlie/status/15335343502">get some glory</a>
(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
;)</div>
<div style="font-style: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-style: normal; margin-bottom: 0in;">
In other words,
please enjoy Qubes OS 1.0, hopefully it could make your digital life
safer!</div>
<div style="font-style: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-style: normal; margin-bottom: 0in;">
Please send all
the <i>technical</i> questions regarding Qubes to the <a href="https://groups.google.com/forum/?fromgroups#!forum/qubes-devel">qubes-devel mailing list</a>.
Do not send them to me directly, nor post them in this blog's
comments.</div>
Joanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.com51tag:blogger.com,1999:blog-24586388.post-81043248519732970502012-07-21T16:12:00.001+02:002012-11-02T18:27:23.368+01:00Qubes 1.0 Release Candidate 1!<style type="text/css">
<!--
@page { margin: 0.79in }
P { margin-bottom: 0.08in }
A:link { so-language: zxx }
</style>
<div style="margin-bottom: 0in;">
I would like to announce the release of Qubes RC1. The
installation ISO and instructions can be found <a href="http://wiki.qubes-os.org/trac/wiki/InstallationGuide">here</a>.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEihGBeIf4SWlpUOmo9HshCzYeeSvyLzovyk89CEAp7zJxZvp-pgrqnljR91r7h-ot8I27DBZhgVygw3kDKXvUEWnwn9VnqqVB8rkTXKGdnMx1aBgjMEvpWPdjZIYbX21ch9hCrF/s1600/snapshot9.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="180" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEihGBeIf4SWlpUOmo9HshCzYeeSvyLzovyk89CEAp7zJxZvp-pgrqnljR91r7h-ot8I27DBZhgVygw3kDKXvUEWnwn9VnqqVB8rkTXKGdnMx1aBgjMEvpWPdjZIYbX21ch9hCrF/s320/snapshot9.png" width="320" /></a></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
Comparing to the previous <a href="http://theinvisiblethings.blogspot.com/2012/02/qubes-beta-3.html">Beta 3 release</a>, the major changes and improvements in this version include:</div>
<ul>
<li><div style="margin-bottom: 0in;">
A much improved <b>Qubes Manager</b>, that
now allows to configure and manage almost every aspect of the Qubes
system using a simple and intuitive GUI. </div>
</li>
<li><div style="margin-bottom: 0in;">
All the VMs are now based on <b>Fedora 17 template</b>.</div>
</li>
<li><div style="margin-bottom: 0in;">
Cleaned up and improved command
lines tools for both <a href="http://wiki.qubes-os.org/trac/wiki/DomZeroTools">Dom0</a>
and for the <a href="http://wiki.qubes-os.org/trac/wiki/VmTools">VMs</a>.</div>
</li>
<li><div style="margin-bottom: 0in;">
Updated Dom0 and VM kernels are now based
on 3.2.7-pvops kernel, which offer better hardware and power
management support.</div>
</li>
<li><div style="margin-bottom: 0in;">
Convenient menu improvements, that
include e.g. a handy icon for launching a <b>Disposable Web browser</b> in
a Disposable VM.</div>
</li>
<li><div style="margin-bottom: 0in;">
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.</div>
</li>
<li><div style="margin-bottom: 0in;">
We also added support for an
<a href="http://wiki.qubes-os.org/trac/wiki/FullScreenMode"> <b>opt-in fullscreen mode</b></a> for select VMs.</div>
</li>
<li><div style="margin-bottom: 0in;">
...plus lots of other improvements
and fixes under the hood. As <a href="http://wiki.qubes-os.org/trac/query?status=closed&milestone=Release+1.0&col=id&col=summary&col=milestone&col=status&col=type&col=priority&col=component&order=priority">can be seen</a> in the wiki, there has been
over 200 tickets closed as part of the work on this release!</div>
</li>
</ul>
<div style="margin-bottom: 0in;">
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.</div>
Joanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.com15tag:blogger.com,1999:blog-24586388.post-73666699064995920652012-06-27T16:00:00.003+02:002012-11-02T18:06:08.839+01:00Some comments on "Operation High Roller"About a year ago I wrote about <a href="http://theinvisiblethings.blogspot.com/2011/04/why-us-password-revolution-wont-work.html">Why the US "password revolution" won't work</a>, where I pointed out that a massive move towards two-factor authentication will <i>not</i> solve any of the identity theft problems that users experience today. Specifically, I wrote:<br />
<blockquote class="tr_bq">
[People] don't understand that the [compromised] <i>operating system can impersonate the user at will</i>! </blockquote>
<blockquote class="tr_bq">
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 <i>as you</i>
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.</blockquote>
<blockquote class="tr_bq">
The bottom line is that <b>we cannot secure our digital lives, if our client operating systems could not be secured first</b>. </blockquote>
<blockquote class="tr_bq">
<b>But introduction of tokens won't make our
operating systems any more secure</b>!</blockquote>
<br />
This article sparked lots of controversy with many people, who considered it a fallacy to criticize two factor authentication...<br />
<br />
Today, I came across the news about <i>Operation High Roller</i>, discovered recently by McAfee and Guardian Analytics. They <a href="http://www.mcafee.com/us/resources/reports/rp-operation-high-roller.pdf">released a paper</a> with some details about the attacks and the malware deployed. Some interesting quotes:<br />
<blockquote class="tr_bq">
<b>All of the instances that involved High Roller malware could bypass complex multi-stage authentication.</b> 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).</blockquote>
<blockquote class="tr_bq">
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). </blockquote>
<blockquote class="tr_bq">
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.</blockquote>
<blockquote class="tr_bq">
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<br />
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.</blockquote>
<br />
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.<br />
<br />
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").<br />
<br />
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 <a href="http://www.bromium.com/misc/BromiumMicrovirtualization.pdf">in those marketing materials</a> might be pure nonsense... (BTW, congrats to Simon Crosby for <a href="http://www.wired.com/wiredenterprise/2012/06/crosby-bromium-microvisor/all/">apparently creating a Windows-hosted VMM in below 10k LOC!</a> ;)<br />
<br />
The often made mistake is to say: "Perhaps there is a way to attack this solution, but then again, how much of the malware <i>in the wild</i> implements such attacks?" This is a classical thinking in our industry, and in my opinion, an inexcusable mistake! Let me say it clearly:<br />
<br />
<div style="text-align: center;">
<b>It doesn't matter whether what the malware in the wild does -- it matters what it <i>could </i>potentially do!</b></div>
<br />
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 <i>will</i> be defeated, sooner or later. Let's not waste time on useless solutions, life's too short!Joanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.com8tag:blogger.com,1999:blog-24586388.post-25363192807757111642012-03-03T12:43:00.000+01:002012-12-15T12:48:18.912+01:00Windows support coming to Qubes!<style type="text/css">
<!--
@page { margin: 0.79in }
P { margin-bottom: 0.08in }
A:link { so-language: zxx }
</style>Ok, let's start with a screenshot :)<br />
<div style="margin-bottom: 0in;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.qubes-os.org/files/screenshots/release-2-alpha-1/qubes-hvm-windows.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="225" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjnQjqSI3JpTyuMrU0TaUqMagefz3X_ykT9vqIw1knwPALCQEQyujaMgv5v-rF84MYxhV6sVLGLROVzNQ7Ik26aUNpd3E5lxlzkM6ttrC3hKDJLHHRlGMy2LnKVflJqH03LkAVC/s400/qubes-hvm-windows.png" width="400" /></a></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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?</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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<sup>st</sup> 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, <a href="http://wiki.qubes-os.org/trac/wiki/GUIdocs">minimalist GUI protocol</a>, and the networking is
also fully integrated with the <span id="goog_1494091458"></span><a href="http://theinvisiblethings.blogspot.com/2011/09/playing-with-qubes-networking-for-fun.html">Qubes diaggregated networking architecture</a><a href="http://www.blogger.com/"></a><span id="goog_1494091459"></span>
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...</div>
<div style="margin-bottom: 0in;">
<br /></div>
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.Joanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.com34tag:blogger.com,1999:blog-24586388.post-72720882057653691342012-02-06T11:45:00.002+01:002012-11-02T18:06:34.499+01:00Qubes Beta 3!<style type="text/css">
<!--
@page { margin: 0.79in }
P { margin-bottom: 0.08in }
A:link { so-language: zxx }
</style>
-->
<br />
<div style="margin-bottom: 0in;">
A new ISO with the just released Qubes
Beta 3 is now available for download <a href="http://wiki.qubes-os.org/trac/wiki/InstallationGuide">here</a>.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
Beta 3 fixes lots of annoying problems
discovered in Beta 2 and earlier releases, and also implements a
bunch of useful feature:</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
This includes the <a href="http://wiki.qubes-os.org/trac/wiki/StickMounting"><span style="font-family: "Courier New",Courier,monospace;">qvm-block</span> tool</a> 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 <a href="http://theinvisiblethings.blogspot.com/2011/06/usb-security-challenges.html">various USB attacks</a>. 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.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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 <a href="http://wiki.qubes-os.org/trac/wiki/QubesBuilder">wiki</a>.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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...).</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
Finally, we have added two new
Qubes-specific applications:</div>
<ul>
<li>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.</li>
</ul>
<ul>
<li>And something we call “split
GPG”, that I will describe in a separate article later.</li>
</ul>
Those
Qubes-specific applications are based on our <a href="http://wiki.qubes-os.org/trac/wiki/Qrexec">Qubes RPC</a>, introduced in Beta 2.<br />
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
This is likely the last release before
the “final 1.0”, that is scheduled to follow <i>soon</i><span style="font-style: normal;">
(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 :)</span></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">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.</span></div>
<div style="margin-bottom: 0in;">
</div>
Joanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.com13tag:blogger.com,1999:blog-24586388.post-68046894025122539672012-01-21T18:01:00.002+01:002012-03-28T11:10:27.715+02:00Thoughts on DeepSafe<style type="text/css">
<!--
@page { margin: 0.79in }
P { margin-bottom: 0.08in }
A:link { so-language: zxx }
-->
</style>
<br />
<div style="margin-bottom: 0in;">
Several people asked me recently what I
though about <a href="http://www.mcafee.com/us/solutions/mcafee-deepsafe.aspx">DeepSafe</a>.
So, below I present my opinion...
</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
First, for any AV system (or Host IPS,
or Personal Firewall, etc) to work effectively, there are three problems that must be addressed:</div>
<ol>
<li><div style="margin-bottom: 0in;">
How to protect the AV agent (code
and data) from tampering (from the rest of the OS)?</div>
</li>
<li><div style="margin-bottom: 0in;">
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.</div>
</li>
<li><div style="margin-bottom: 0in;">
What are those "sensitive
pieces of” memory that should be monitored or protected?</div>
</li>
</ol>
<div style="margin-bottom: 0in;">
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? ;)
</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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 <i>any
</i><span style="font-style: normal;">physical </span>memory it
wants...</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
Very well, let's assume then that the
DeepSafe is not a <span style="font-style: normal;">total </span>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...</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
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.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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).</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
(Can somebody from McAfee or Intel
confirm in the comments below what does DP really do?)</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
Anyway, let's assume they <i>do</i>
have VT-d protection and they <i>do </i>virtualize the chipset
somehow...</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
Now, we're moving on to the #2 point
from the list of tasks above -- about the reliable</div>
<div style="margin-bottom: 0in;">
memory access or reliable protection.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
So, let say that the DS agent decided
that some part of the system memory, e.g. the IDT table, is <i>sensitive</i>
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).</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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 <i>never </i>be
allowed to touch any of those sensitive parts of the system, such as
IDT. Let's assume they do it this way...</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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 <a href="https://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Tereshkin.pdf">undocumented NDIS structures</a>?
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<sup>rd</sup> 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.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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 <a href="https://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-Rutkowska.pdf">last slides</a> from
this
period.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
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:</div>
<ol>
<li><div style="margin-bottom: 0in;">
Use VT-d to protect its own
memory,</div>
</li>
</ol>
<ol start="2">
<li><div style="margin-bottom: 0in;">
Virtualize the chipset, at least
some (sensitive) parts of it,</div>
</li>
</ol>
<ol start="3">
<li><div style="margin-bottom: 0in;">
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.</div>
</li>
</ol>
<ol start="4">
<li><div style="margin-bottom: 0in;">
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.</div>
</li>
</ol>
<div style="margin-bottom: 0in;">
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 ;)
</div>Joanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.com9tag:blogger.com,1999:blog-24586388.post-69751440727975891662011-12-13T20:25:00.000+01:002012-03-28T11:10:17.874+02:00Trusted Execution In Untrusted Cloud<style type="text/css">
p { margin-bottom: 0.08in; }a:link { }
</style>
<br />
<div style="margin-bottom: 0in;">
Wouldn't it be nice if we could
actually own our data and programs in the cloud? By “owning” here
I mean to have control over their confidentiality and integrity. When
it comes to confidentiality and integrity for the <i>data,</i><span style="font-style: normal;">
it's</span> not much of a rocket since, as the classic crypto (and
secure client systems) is all that we need. <span style="font-style: normal;">I
have already wrote about it in an <a href="http://theinvisiblethings.blogspot.com/2011/05/untrusting-cloud.html">earlier post</a>.</span></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;"> </span></div>
<div style="margin-bottom: 0in;">
<style type="text/css">
p { margin-bottom: 0.08in; }a:link { }
</style>
</div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">But it
would also be nice, if we could somehow get the same confidentiality
and integrity assurance for our </span><i>programs</i><span style="font-style: normal;">
that we upload for the execution in the cloud...</span></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">For
example, a company might want take their
database application, that deal with all sorts of corporate critical
sensitive data, and then upload and <i>safely </i>run this application on e.g.
Amazon's EC2, or maybe even to some China-based EC2-clone. Currently t</span>here is really nothing
that could stop the provider, who has a full control over the kernel
or the hypervisor under which our application (or our VM) executes, from reading the contents of our process' memory and stealing
the secrets from there. This is all easy stuff to do from the technical point of
view, and this is also <a href="http://www.schneier.com/blog/archives/2011/12/security_proble_2.html">not just my own paranoia</a>... </div>
<span style="font-style: normal;"></span>
<br />
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">Plus,
there are the usual concerns, such as: is the infrastructure of the
cloud provider really that safe and secure, as it is advertised? How
do we know nobody found an exploitable bug in the hypervisor and was
not able to compromise other customer's VMs from within the
attacker-hired VM? Perhaps the same question applies if we didn't decided to outsource the apps to a 3</span><sup><span style="font-style: normal;">rd</span></sup><span style="font-style: normal;">
party cloud, but in case of a 3</span><sup><span style="font-style: normal;">rd</span></sup><span style="font-style: normal;">
party clouds we really don't know about what measures have been
applied. E.g. does the physical server on which my VMs are hosted also used to host some foreign customers? From China maybe? You
get the point.</span></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">Sometimes
all we really need is just integrity, e.g. if we wanted to host an
open source code revision system, e.g. a git repository or a file
server. Remember the <a href="http://www.linuxfoundation.org/news-media/blogs/browse/2011/08/cracking-kernelorg">kernel.org incident</a>?
On a side note, I find the Jonathan Corbet's self-comforting remarks
on how there was really nothing to worry about, to be strikingly
naive... I could easily think of a few examples of how the
attacker(s) could have exploited this incident, so that Linus &
co. would never (not soon) find out. But that's another story...</span></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">But, h</span><span style="font-style: normal;">ow can one protect a <i>running</i> process, or a VM, from a
potentially compromised OS, or a hypervisor/VMM?</span></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">To
some extent, at least theoretically, Intel Trusted Execution
Technology (TXT), could be used to implement such protection.
Intel TXT can attest to a remote entity, in that case this would be
the cloud customer, about the hash of the hypervisor (or kernel) that has been
loaded on the platform. This means it should be possible for the user
to know that the cloud provider uses the unmodified Xen 4.1.1 binary
as the hypervisor and not some modified version, with a built-in FBI backdoor for
memory inspection. Ok, it's a poor example, because the Xen
architecture (and any other commercially used VMM) allow the administrator who controls Dom0 (or equivalent) to essentially
inspect and modify all the memory in the system, also that belonging
to other VMs, and no special backdoors in the hypervisor are needed for this.</span></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">But let's assume hypothetically that Xen 5.0 would change that
architecture, and so the
Dom0 would not be able to access any other VM's memory anymore. Additionally,
if we also assumed that the Xen hypervisor was <i>secure</i>, so that it was
not possible to exploit any flaw in the hypervior, then we should be fine.
Of course, assuming also there were also no flaws in the TXT implementation,
and that the SMM was properly sandboxed, or that we trusted (some parts
of) the BIOS (these are really complex problems to solve in practice, but I know
there is some work going on in this area, so there is some hope).</span></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">Such a
TXT-bases solution, although a step forward, still requires us to trust the cloud provider a
bit... First, TXT doesn't protect against bus-level physical attacks
– think of an attacker who replaces the DRAM dies with some kind of
DRAM emulator – a device that looks like DRAM to the host, but on
the other end allows full inspection/modification of its contents
(well, ok, this is still a bit tricky, because of the lack of
synchronization, but doable).</span></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">Additionally
for Remote Attestation to make any sense, we must somehow know that
we “talk to” a real TPM, and not to some software-emulated TPM.
The idea here is that only a “real” TPM would have access to a
private key, called Endorsement Key, used for signing during Remote
Attestation procedure (or used during the generation of the AIK key,
that can be used alternatively for Remote Attestation). But then
again who generates (and so: owns) the private endorsement keys? Well,
the TPM manufacturer, that can be... some Asian company that we not
necessarily want to trust that much...</span></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">Now we see it would really be advantageous for customers, if Intel decided
to return to the practice of implementing TPM internally inside the chipset, as they did in the past for their Series 4 chipsets (e.g.
Q45). This would also protect against the LCP bus-level attacks
against TPM (although somebody told me recently that TPM in current
systems cannot be so easily attacked from LCP bus, because of some
authentication protocol being used there – I really don't know, as
physical attacks have not been the area we ever looked at
extensively; any comments on that?).</span></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">But
then again, the problem of DRAM content sniffing always remains,
although I would consider this to be a complex and expensive attack.
So, it seems to me that most governments would be able to bypass such
TXT-ensured guarantees in order to “tap” the user's programs
executing in the cloud provides that operate within their
jurisdictions. But at least this could stop malicious companies from
staring up fake cloud services with an intent to easily harvest some
sensitive data from unsuspecting users.</span></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">It seems that the only way to solve the above problem of DRAM sniffing attacks is to add some protection at the processor level. We can imagine two solutions that processor vendors could implement:</span></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">First,
they could opt for adding an in-processor hardware mechanism for
encrypting all the data that leave the processor, to ensure that
everything the is kept in the DRAM is encrypted (and, of course, also
integrity-protected), with some private key that never leave the processor. This could be seen as an extension to the Intel TXT.</span></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">This would mean, however, we still needed to relay on:
1) the hypervisor to not contain bugs, 2) the whole VMM architecture
to properly protect VM's memory, specifically against the Dom0, 3)
Intel TXT to not be buggy either, 4) SMM being properly sandboxed, or
alternatively to trust (some parts of) the BIOS and SMI handler, 5)
TPM's EK key to be non-compromised and verifiable as genuine, and 6)
TPM bus attacks made impossible (those two could be achieved by
moving the TPM back onto the chipset, as mentioned above), and finally, 7) on the
encryption key used by the processor for data encryption to be safely
kept in the processor.</span></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">That's
still quite a lot of things to trust, and it requires quite a lot of work to make it practically really secure...</span></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">The other option is a bit more crazy, but also more powerful. The
idea is that the processor might allow to create </span><i>untrusted
supervisors</i><span style="font-style: normal;"> (or hypervisors).
Bringing this down to x86 nomenclature, it would mean that kernel
mode (or VT-x root) code cannot sniff or inject code into (crypto-protected) memory of the usermode processes (or VT-x guests).
This idea is not as crazy as you might think, and there has even been
<a href="http://www.eecg.toronto.edu/%7Elie/papers/lie-sosp2003.pdf">some academic work</a> done in this area.
Of course, there are many catches here, as this would require
specifically written and designed applications. And if we ever
considered to use this technology also for client systems (how nice
it would be if we could just get rid of some 200-300 kLOC of the Xen
hypervisor from the TCB in Qubes OS!), the challenges are even
bigger, mostly relating to safe and secure trusted output (screen)
and, especially, input (keyboard, mouse).</span></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">If
this worked out, then we would need to trust just one element: the
processor. But we need to trust it <a href="http://theinvisiblethings.blogspot.com/2009/06/more-thoughts-on-cpu-backdoors.html">anyway</a>.
Of course, we also need to trust some software stack, e.g. the
compilers we use at home to build our application, and the libraries
it uses, but that's somehow an unrelated issue. What is important is
that we now would be able to choose that (important) software stack
ourselves, and don't care about all the other software used by the
cloud provider.</span></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">As I
wrote above, the processor is this final element we always need to
rust. In practice this comes down to also trusting the US government :) But we might imagine users consciously choosing e.g.
China-based, or Russia-based cloud providers and require
(cryptographically) to run their hosted programs on US-made
processors. I guess this could provide reasonable politically-based safety.
And there is also ARM, with its licensable processor cores, where, I can
imagine, the licensee (e.g. an EU state) would be able to put their
own private key, not known to any other government (here I assume the
licensee also audits the processor RTL for any signs of backdoors). I'm not sure if it would be
possible to hide such a private key from a foundry in Hong Kong, or
somewhere, but luckily there are also some foundries within the EU.</span></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<span style="font-style: normal;">In any
case, it seems like we could make our cloud computing orders of
magnitude safer and more secure than what is now. Let's see whether
the industry will follow this path...</span></div>
<span style="font-style: normal;"> </span>Joanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.com17tag:blogger.com,1999:blog-24586388.post-78450925467780532422011-12-06T10:48:00.001+01:002012-03-28T11:10:07.825+02:00Exploring new lands on Intel CPUs (SINIT code execution hijacking)Today we're releasing a new paper where we describe exploiting a bug in Intel SINIT authenticated code module that allows for arbitrary code execution in what we call an “SINIT mode”. So, to the already pretty-well explored “lands” on Intel processors, that include ring 3 (usermode), ring 0 (kernelmode), ring “-1” (VT-x root), and ring “-2” (SMM), we're now adding a new “island”, the SINIT mode, a previously unexplored territory inhabited so far only by the Intel-blessed opcodes. <br />
<br />
What is really interesting about the attack are the consequences of SINIT mode hijacking, which include ability to bypass Intel TXT, LCP, and also compromise system SMRAM.<br />
<br />
It's also interesting how difficult was this vulnerability for Intel to patch, as they had to release not only updated SINIT modules, but also updated microcode for all the affected processors, and also work with the BIOS vendors so they release updated BIOSes that would be unconditionally loading this updated microcode (plus provide anti-rollback mechanisms for both the BIOS and microcode). Quite an undertaking...<br />
<br />
You can get the paper <a href="http://www.invisiblethingslab.com/resources/2011/Attacking_Intel_TXT_via_SINIT_hijacking.pdf">here</a>.<br />
<br />
Intel also published an advisory yesterday, which can be downloaded from their website <a href="http://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00030&languageid=en-fr">here</a>. The advisory is peculiar in a few ways, however...<br />
<br />
First, the advisory (I'm referring to the revision 1.0) never explicitly mentions that the attack allows to bypass TXT launch itself, only that the attack “may compromise certain SINIT ACM functionality, including launch control policy and additionally lead to compromise of System Management Mode (SMM). Intel also recommend to disable TXT altogether in the BIOS, as a preventive measure, in case the user doesn't “actively running Intel® TXT”... This reminds me how various vendors started actively disabling Intel VT-x after certain virtualization rootkits have been demonstrated some 5 years ago, and how many laptops still ship with this technology disabled today (or VT-d at least) to the questionable delight of many users.<br />
<br />
Second, the advisory assigns only an “Important” rating to this vulnerability, even though <a href="http://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00021&languageid=en-fr">another Intel advisory</a>, published some two years ago for a problem also reported by us, and which which was strictly a <i>subset</i> of the current vulnerability in terms of powers that it gave to the attacker (in other words the current vulnerability provides the attacker with everything that the previous one did, plus much more), was given a “Critical” rating... This is called evolution, I guess, and I wonder what would be considered critical by Intel these days?<br />
<br />
<b>UPDATE (Dec 7th, 2011):</b> Intel has just released <a href="http://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00030&languageid=en-fr">an updated advisory</a> (release 1.1) that now explicitly states that the vulnerability also bypasses Intel TXT.<br />
<br />
This is the last paper co-authored with Rafal Wojtczuk, who recently decided to try some new things and to leave ITL. Rafal has been the most talented exploit writer I have worked with, and I will surely miss his ingenious insights, such as e.g. how to practically win an absolutely hopeless race condition with ICMP-delivered MSI! But then again, how many times can one break Intel technologies, before getting bored? At the same time ITL is really transforming now into a development company, with all our efforts around Qubes and architecting, rather than on breaking. I wish Rafal all the best with his new endeavors, and thank him for all the excellent contributions he made while working for ITL over the past 3+ years.Joanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.com6