http://www.secuobs.com Observatoire de la securite Internet fr webmaster@secuobs.com 2015-02-09 20:04:54 - The Invisible Things Lab's blog : I've migrated this blog to a new platform The new blog is now hosted here This post via new blogging platform explains the reasons of migration and how to use the new blog Thanks joanna http://www.secuobs.com/revue/news/558738.shtmlhttp://www.secuobs.com/revue/news/558738.shtml Secuobs.com : 2014-11-27 15:15:34 - The Invisible Things Lab's blog - Back 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 this post, which I recommend to re-read if you're more interested in understanding our goals 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 failure We have also done a lot of work in the meantime to polish Qubes R2 and bring it to the state of the final release, which happened earlier this fall 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 Today we're finally releasing the Qubes R3 source code to the public The code builds fine see here for building instruction , produces install-able ISO, and, if that was not enough, even seems to be working, mostly fine, when installed 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 qubes-devel mailing list, before they start the actual coding Currently the only implemented and supported backend is Xen, of course, specifically the Xen 44, 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 But use of other hypervisors might open up lots of interesting possibilities imagine eg 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 Major features of the current release, compared to Qubes R2 Hypervisor Abstraction Layer for all the core management stack but still missing for the GUI daemon, see below 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 v42 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 There is still some work going on which we would like to complete before we officially decide to release Qubes OS 30-rc1 ISO, and this includes 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 Initial code for Qubes Admin API and port of Qubes Manager to use it Further down the road Qubes OS 31 we plan to work on some really exciting things More flexibility to qrexec policy more on that in a separate post More flexibility to Qubes Admin API expose it to slelect other VMs 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 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 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 The possibilities seems to be endless now Join us and help us with The Revolution http://www.secuobs.com/revue/news/547549.shtmlhttp://www.secuobs.com/revue/news/547549.shtml Secuobs.com : 2014-09-26 20:44:07 - The Invisible Things Lab's blog - Today we're releasing Qubes OS R2 I'm not gonna write about all the cool features in this release because you can find all this in our wiki and previous announcements R2-beta1, R2-beta2, R2-beta3, R2-rc1, and R2-rc2 Suffice to say that we've come a long way over those 4 years from a primitive proof of concept to a powerful desktop OS which, I believe, it is today 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 It's great that we're receiving more and more community contributions This includes not only bug fixes, but also invaluable efforts related to documentation, HCL maintenance, as well as some really non-trivial new features advanced backups support, Debian and Arch templates, TorVM, Whonix port, etc Thanks I'm also happy to announce that Caspar Bowden, 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 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 Exciting stuff is coming next the Release 3 Odyssey and more, stay tuned Thanks to everyone 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 IMAGE http://www.secuobs.com/revue/news/537075.shtmlhttp://www.secuobs.com/revue/news/537075.shtml Secuobs.com : 2014-08-26 19:22:44 - The Invisible Things Lab's blog - Many 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 I argue with this point of view in this new paper I think a good place for in-depth technical discussions around the topics discussed in the paper would be our qubes-devel mailing list http://www.secuobs.com/revue/news/531642.shtmlhttp://www.secuobs.com/revue/news/531642.shtml Secuobs.com : 2014-08-06 13:58:53 - The Invisible Things Lab's blog - 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 here After Qubes rc1 release a few months ago 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 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 Eg 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 Speaking of different Linux distros -- we have also recently built and released an experimental beta Debian template for Qubes AppVMs, 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 templates-community 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 Also in our Templates Appstore you can find now an experimental minimal fedora-based template, which might be used by more advanced users to build customized special-purpose VMs and templates 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 read why this is mostly irrelevant from the security standpoint and why they should still be checking signatures on the ISOs 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 Every once in a while people re- discover that monolithic kernel-based desktop operating systems are not the best solution whenever the user even remotely cares about security Yes, USB inherent insecurity, as well as widespread GUI insecurity, or networking stack insecurity, trivial physical insecurities, or sick permissions model 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 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 Odyssey-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 With my 10 years of experience as a system-level security researcher, I believe there is no other way to go Don't get deluded 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 eg microkernel in place of Xen, at least in some editions of Qubes 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 twitter account rootkovska , which I hope to use for updates on Qubes, as well as more general commentary on various things happening in IT security IMAGE http://www.secuobs.com/revue/news/528591.shtmlhttp://www.secuobs.com/revue/news/528591.shtml Secuobs.com : 2014-04-20 20:47:08 - The Invisible Things Lab's blog - 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 previously today's release is bringing mainly UI improvements and polishing and lots of bugfixes, as well as some last new features Both Dom0 and VMs have been upgraded to Fedora 20 Support for full templates download via two new repo definitions templates-itl and templates-community 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 ourselves, from contributed sources Support for running Windows AppVMs in full desktop mode with support for arbitrary window resizing which automatically adjusts the resolution in the VMs Support for on-the-fly switching between the full desktop and seamless modes for Windows AppVMs 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 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 As can be seen in our ticketing system, 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 As usual, the detailed installation and upgrade instructions, as well as the HCL, can be found here 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 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 Please direct all the technical questions or comments regarding Qubes OS to our mailing lists Enjoy http://www.secuobs.com/revue/news/509345.shtmlhttp://www.secuobs.com/revue/news/509345.shtml Secuobs.com : 2014-01-16 01:30:11 - The Invisible Things Lab's blog - When I originally described the flexible Qubes Odyssey framework 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 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 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 MS-DOS security model 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 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 And so we decided to build the Qubes WNI Lots of work we invested in building Qubes WNI was actually WNI-independent, because it eg 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 eg 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 eg proper GUI isolation, networking isolation, kernel object spaces isolation, etc 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 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 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 The paper can be downloaded from here http://www.secuobs.com/revue/news/491863.shtmlhttp://www.secuobs.com/revue/news/491863.shtml Secuobs.com : 2013-12-11 00:35:09 - The Invisible Things Lab's blog - 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 30, 31, etc Anyway, back to the R2 Beta 3 below I discuss some of the highlights of the today's release The seamless GUI virtualization for Windows 7-based AppVMs, and support for HVM-based templates eg Windows-based templates is one of the most spectacular feature of this release, I think It has already been discussed in an earlier blog post, and now instructions have also been added to the wiki for how to install and use such Windows AppVMs We've also introduced a much more advanced infrastructure for system backups, so it is now possible to make and restore backups to from untrusted VMs, which allows eg 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 with malformed partition table or filesystem 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 Thanks A very simple feature, trivial almost, yet very important from the security point of view it is now possible to set 'autostart' property on select VMs Why is this so important for security Because I can create eg 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 attacks coming though USB devices And it now could double as a BackupVM with this new backup system mentioned above To improve hardware compatibility we now ship the installer with multiple kernel versions 37, 39, and 311 allowing to run the installation using any of those, eg 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 Another popular problem of the past now was the lack of support for dynamically changing resolution screen layout in the AppVMs when a seccond monitor or a projector was hot-plugged in which changed only the resolution layout in Dom0 Now this problem has been solved and the new monitor layout is dynamically propagated to the AppVMs, allowing to use all the screen real estate by the apps running there There has also been a significant amount of cleanups and fixes 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 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 Installation and upgrade instructions can be found here http://www.secuobs.com/revue/news/485514.shtmlhttp://www.secuobs.com/revue/news/485514.shtml Secuobs.com : 2013-11-26 18:36:08 - The Invisible Things Lab's blog - 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 IMAGE The seamless mode for Windows AppVMs is not yet as polishedas the one we have for Linux AppVMs, because, unlike we do for Xorg, the Windows GUI agent is not based on composition buffers extraction This causes some, ratherminor, cosmetic problems For example, when we have two overlapping windows, 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 you should not really feel any slowness or heaviness compared to Linux AppVMs 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 Of course, the usual Qubes integration features, such as secure inter-VM clipboard and file copy also work for Windows AppVMs with the tools installed The Qubes Windows Support Tools are proprietary, but they are supposed to be installed only in the Windows 7 VMs, which themselves contains millions of lines of proprietary code already,and besides that the tools do not require any modifications to any other open source components of the system As a special bonus we have also added and releasing also in R2B3 the support for template-based HVMs So it is now possible to do something like this qvm-create --hvm work-win7 --template win7-x64 --label greenqvm-create --hvm personal-win7 --template win7-x64 --label purpleqvm-create--hvm testing-win7 --template win7-x64 --label red which tells Qubes to createthree HVM AppVMs based on the template win7-x64 All such template-based AppVMs 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 writableJust like in case of Linux AppVMs, the actual writes are stored in COW buffersbacked by files stored in each of the AppVMs directories Upon AppVM's reboot, thosefilesarediscarded, which reverts their root filesystems back to that of the template the golden image For the above mechanism to make any sense we should have the OS in the Template VMconfigured in such as way so that it usesa separate disk for the user's home directory ies eg C Usersin case of Win 7 Qubes automatically exposes an additional private disk to each of the AppVM exactly for this very purpose Again, just like it has been done for Linux AppVMs for years The above feature allows to create lots of Windows AppVMs quickly and with minimal use of disk space, and with an ability to centrally update all the system software in all the AppVMs all at once Just like for Linux AppVMs Users should, however, ensure that their license allows for such instantiating of the OS they use in the template Note that from the technical point of view the OS is installed and activated in case of Windows only once, and this is in the template VM The installed files are never copied, they are only sharedbetween the AppVMs which have been instantiated upon the template VM http://www.secuobs.com/revue/news/483151.shtmlhttp://www.secuobs.com/revue/news/483151.shtml Secuobs.com : 2013-09-23 20:25:46 - The Invisible Things Lab's blog - In the first part of this article 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 SGX Blackboxing Apps and malware that cannot be reverse engineered 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 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 Consider the following scenario, where a user downloads an executable, say blackpillexe, which in fact logically consists of three parts 1 A 1st stage loader SGX loader which is unencrypted, and which task is to setup an SGX enclave, copy the rest of the code there, specifically the 2nd stage loader, and then start executing the 2nd stage loader 2 The 2nd stage loader, which starts executing within the enclave, performs remote attestation with an external server and, in case the remote attestation completes successfully, obtains a secret key from the remote server This code is also delivered in plaintext too 3 Finally the encrypted blob which can only be decrypted using the key obtained by the 2nd stage loader from the remote server, and which contains the actual logic of the application or malware 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 This is because the key will be released by the remote server only if the 2ndstage loader can prove via remote attestation 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 remote attestation wouldfail and the key will not be obtained 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 eg 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 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 2ndstage 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 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 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 Unless there was a way for Certified Antivirus companies to get around SGX protection see below for more discussion on this And some good applications of SGX The SGX blackboxing has, however, some good usages too, beyond protecting the Hollywood productions, and making malware un-analyzable One particularly attractive possibility is the trusted cloud where VMs offered to users could not be eavesdropped or tampered by the cloud provider admins I wrote 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 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 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 New OS and VMM architectures 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 ie 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 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 it is very challenging 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 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 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 Trusting Intel Next Generation of Backdooring We have seen that SGX offers a number of attractive functionality that could potentially make our digital systems more secure and 3rdparty servers more trusted But does it really 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 Traditional CPU backdooring 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 I wrote more about this many years ago 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 MOV eax, deadbeefMOV ebx, babecafeADD eax, ebx 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 Next-generation CPU backdooring 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 Consider eg the recent paper 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 eg 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 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 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 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 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 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 eg 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 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 eg somebody analyzed an exploit which turns out to be triggering correct Quote message despite incorrect PCRs So, perhaps, the idea of separate TPM actually does make some sense after all What about just accidental bugs in Intel products 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 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 I think it all started with our exploit against Intel Q35 chipset 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 This was then shortly followed by another paper 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 In the following years we presented two more devastating attacks against Intel TXT none of which depending on compromised SMM onewhich exploited a subtle bug in the processor SINIT module allowing to misconfigure VT-d protections for TXT-loaded code, and another one 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 Invisible Things Lab has also presented 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 found outabout 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 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 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 his SYSRET attackin 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 We have also demonstrated 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 So, is Intel SGX gonna be as insecure as Intel TXT, or as secure as Intel VT-x The bottom line 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 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 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 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 Special thanks to Oded Horowitz for turning my attention towards Intel SGX http://www.secuobs.com/revue/news/470316.shtmlhttp://www.secuobs.com/revue/news/470316.shtml Secuobs.com : 2013-08-30 14:15:57 - The Invisible Things Lab's blog - 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 enclavewithin 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 Intel SGX secure enclaves within untrustedworld 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 one security workshop 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 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 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 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 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 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 eg Flicker tried to do, and which was very clumsy Additionally, there can be multiple enclaves, mutually untrusted, all executing at the same time No more stinkin' TPMs nor BIOSes to trust 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 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 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 can subvert a TXT-loaded hypervisor , nor any other entity, such as the infamous AMT, or malicious GPU, should be able to do that So, this is all very good However Secure Input and Output for Humans 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 eg 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 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 consumer FAQ onBlueRay Disc Playback 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 inputtechnology available, even on prototype level, although they promise to work on that in the future 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 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 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 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 eg 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 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 Securing mainstream client OSes and why this is not so simple 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 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 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 Well it's obviously not enough to just put the proverbial mswordexe into a SGXenclave It is not, because the mswordexe makes use of million of other things that are provided by the OS and 3rdlibraries, 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 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 ie not allows to easily leakthe plaintext document out of the enclave , let's not forget that all this 3rdparty code would be interacting very closely with the enclave-contained code This means the attack surface exposed to all those untrusted 3rdparty modules will be rather huge And we already know it is rather not possible to write a rendererfor such complex documents as PDFs, DOCs, XLS, etc, without introducing tons of exploitable bugsAnd these attack are not coming now from the potentially malicious documents against thosewe protect, somehow, by parsing only signed document from trusted peers , but are coming from the compromised OS 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 they wereproperly decomposed into sensitive parts that execute within SGC enclave s , and those that are not-sensitive and make use of all the OS-providedfunctionality, and further define clean and simple interfaces between those parts, ensuring the dirty code cannot exploit the sensitive code Somehow attractive, but somehow I don't see this happening anytime soon But, perhaps, it would be easier to do something different just take the whole mswordexe, 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 Only notice one thing we just created a Virtual Machine with Windows OS inside and the mswordexe that uses this Windows OS Sure, it is not a VT-x-based VM, it is an SGX-based VM now, but it is largely the same animal 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 of 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 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 This is a significant achievement Of course SGX, strictly speaking, is not a full virtualization technology, it's not going to replace VT-x 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 For examaple, Xen usesparavirtualizationfor Linux-based PV VMs, and usesgood-old ring3 ring0 separation mechanism to implement this, and the level of isolation of such PV domains on Xen is comparable to the isolation of HVMs, which are virtualized using VT-x To Be Continued 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 theiroperators 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 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 http://www.secuobs.com/revue/news/465866.shtmlhttp://www.secuobs.com/revue/news/465866.shtml Secuobs.com : 2013-06-21 12:15:07 - The Invisible Things Lab's blog - In a previous postI 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 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 IMAGE Our Qubes Odyssey backendneeded to support a specific hypervisor compromises essentially three parts 1 A libvirt driver to support a given VMM In our case we got it almost for free, because Xen 42 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 2 A VMM-specific implementation of our vchan a simple, socket-like, VMM shared memory-based communication stack between the VMs Again, in case of Xen 42 we got that almost for free, because Xen 42 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 3 Some minor configuration files, eg to tell libvirt which hypervisor protocol to use in our case xen , and VM configuration template files Now, if one wanted to switch Xen for some other hypervisor, such as eg 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 Ok, one thing that is left out non-HAL'ified for now, is the xc_map_foreign_pages Xen-specific function call within our GUI daemon 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 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 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 1 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 2 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 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 ie for which we have libvirt driver, and can write vchan 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 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 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 permissions is dead, long live separation So, in Qubes OS we just isolate everything by default, unless a user configuration specifically allows an exception eg no file copy operation between domains is possible, unless the user expresses an explicit consent for it Many old-school security people can't imagine a system without permissions, but if wethink about it more, we might get to a conclusion that 1 permissions are complex and so often difficult to understand and set correctly, 2 require often complex code to parse and make security decisions, and 3 often are absolutely unneeded As a practical example of how permissions schemes might sometime trick even otherwise somehow smart developersinto making a mistake consider this bug in Qubes we made a 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, Xenorg has published this advisory, that sounds pretty serious, again caused by bad permissions on some xenstore keys Yes, we do have updated Xen packages to fix that, of course 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, eg 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 In other news everybody seems to be genuinely surprised that unencrypted information can be intercepted and analyzed 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 http://www.secuobs.com/revue/news/452825.shtmlhttp://www.secuobs.com/revue/news/452825.shtml Secuobs.com : 2013-03-21 18:39:52 - The Invisible Things Lab's blog - Qubes OS is becoming more and more advanced, polished, and user friendly OSBut 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 systemsThere is also one more limitation of Qubes OS, particularly difficult to overcome Namely that it is a standalone Operating System, not an application that could be installed inside the user's existing 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 storyBefore I discuss how we plan to address those limitations, let's first make a quick digression about what Qubes reallyis, as many people often get that wrongWhat Qubes IS, and what Qubes IS NOT Qubes surely is not Xen Qubes only usesXen to create isolatedcontainers security domains or zones Qubes also is not a Linux distribution Sure, we currently use Fedora 18 as the default template for AppVMs, but at the same time we also support Windows VMs And while we also use Linux as GUI and admin domain, we could really use something different eg Windows as GUI domainSo, what is Qubes then Qubes note how I've suddenly dropped the OS suffix is several things The way how to configure, harden, and use the VMM eg Xen to create isolated security domains, and to minimize overall system TCB Secure GUI virtualization 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 customized GUI environment, including trusted Window Manager that provides unspoofable decorations for the applications' windows Secure inter-domain communication and services infrastructure with centrally enforced policy engine Plus some core services built on top of this, such as secure file exchange between domains Various additional services, 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 Various additional customizations to all the guest OSes that run in various domains GUI, Admin, ServiceVMs, and AppVMs Introducing Qubes HAL Hypervisor Abstraction LayerBecause Qubes is a bunch of technologies and approaches that are mostly independent from the underlying hypervisor, as discussed above, it's quite natural to consider if we could easily build an abstraction layer to allow the use of different VMMs with Qubes, instead of just Xen Turns out this is not as difficult as we originally thought, and this is exactly the direction we're taking right now with Qubes Odyssey To make this possible we're going to use the libvirt projectSo, 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 deploymentAnd we can go even further and ask why not use Windows Native Isolation, ie 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 systemOf course the price we pay for all this is progressively degraded security, as eg 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 IMAGE 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 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 belowThe 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 IMAGE Some example configurationsLet'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 opposite endof the spectrum as shown on the illustration above The diagram below shows a configuration that uses a decent baremetal hypervisor, such as Xen, with abilities to securely assign devices to untrusted service domains NetVM, UsbVM So, this is very similar to the current Qubes OS IMAGE Additionally weseeseparate GUI and Admin domains the GUI domain might perhaps be based on Windows, to provide users with a familiar UI, while the Admin domain, tasked with domain management and policy enforcement,might be based on some minimal Linux distributionIn the current Qubes OS there is no distinction between a GUI and an Admin domain --both are hosted within one domain called dom0 But in some cases there are benefits of separating the GUI domain from the Admin domain In a corporate scenario, for example, the Admin domain might be accessible only to the IT department and not to the end user This way the user wouldhave no way of modifying system-wide policies, and eg allowing their work domain to suddenly talk to the wild open Internet, or to copy workproject files from work to personal domains save for the exotic, low-bandwidthcovert channels, such as through CPU cache 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 benefits This automatically prevents various attacks against the bugs in WiFi stacks or USB stacksWhat is not seen on the diagram, but what is typical for baremetal hypervisors is that they are usually much smaller than hosted hypervisors, implementing less services, and delegating most tasks, such as the infamous I O emulation to often unprivileged VMsLet's now look at the other extreme example of using Qubes the diagram below shows an architecture of a Qubized Windows system that uses either a hosted VMM, such as Virtual Box or VMWare Workstation, or even the previously mentioned Windows Native Isolation mechanisms, as an isolation provider for domains IMAGE 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 amuch lower price better hardware compatibility, easier deployment, and in case of Windows Native Isolation excellent performanceAnd it really can be made reasonable, although it might require more effort than it might seem at first sight 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 means to make the isolation as good as the Windows kernel can isolate processes from different users from each otherSure, a single kernel exploit destroys this all, but it's still better than one application can legally read all my files policy that 99pourcents of all desktop OSes out there essentially implement todayNow, 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 Qubes building blocks implementation detailsLet's have a look now at the repository layout for the latest Qubes OSsources every name listed below represents a separate code repository that corresponds to a logical module, or a building block of a Qubes system core-admincore-admin-linuxcore-agent-linuxcore-agent-windowscore-vchan-xendesktop-linux-kdedesktop-linux-xfce4gui-agent-linuxgui-agent-windowsgui-agent-xen-hvm-stubdomgui-commongui-daemonlinux-dom0-updateslinux-installer-qubes-oslinux-kernellinux-template-builderlinux-utilslinux-yumqubes-app-linux-pdf-converterqubes-app-linux-split-gpgqubes-app-linux-torqubes-app-thunderbirdqubes-builderqubes-managervmm-xenvmm-xen-windows-pvdrivers Because current Qubes R2 still doesn't use HAL layer to support different hypervisors, it can currently be used with only one hypervisor, namely Xen, whose code is provided by the vmm-xenrepository in an ideal world we would be just using vanilla Xen instead of buildingour own from sources, but in reality we like the ability to build it ourselves, slightly modifying some things Once we move towards the Qubes Odyssey architecture essentially by replacing thehardcoded calls to Xen's management stack, in the core-adminmodule, with libvirt calls , we could 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 thevmm-hyperv repository that could contain various hardening scripts and configuration files for this VMM Or might not Also, chances are high that we would be just able to use the stock libvirt driversfor Hyper-V or Virtual Box,so no need for creating core-libvirt-hypervor core-libvirt-virtualboxbackendsWhat we will need to provide, is ourcustom inter-domaincommunication library for each hypervisor supportedThis means we will need to write core-vchan-hypervor core-vchan-virtualbox 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 wrap the VMM-custom mechanism with Qubes-standarizedAPI for vchan and this standardization is one thing we're currently working on All in all, in most cases this will be asimple taskIf 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 core-libvirt-windows as well as the corresponding vchan module which should be especially trivial to write in this case core-vchan-windowsAdditionally, if we're building a system where the Admin domain is not based on Linux, which would likely be the case if we used Hyper-V, or Virtual Box for Windows, or, especially, Windows Native Isolation, then we should also provide core-admin-windowsmodule, that, among other things, should provide Qubes qrexecimplementation, something that is highly OS-dependentAs can be seen above, we currently only have core-admin-linux, which is understandable as we currently use Linux in Dom0 But the good news is that we only need to write core-admin-XXXonce for each OS that is to be supported as an Admin domain, asthis code should not be depend on the actual VMM used thanks to our smart HAL Similarly, we also need to assure that our gui-daemoncan run on the OS that is to be used as a 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 current GUIdaemon should compile and run on most OSes, from Linux Xorg to Windows and Macs which is the reason we only have one gui-daemonrepository, instead of several gui-daemon-XXX Finally we should provide some code that will gather all the components neededfor our specific product and package this all into either an installable ISO, if Qubes is to be a standalone OS, like current Qubes,or into an executable, in case Qubes is to be an application The installer, depending on the product, might do some cool things, such as eg take current user system and automatically move it into one of Qubes domainsTo summary, these would be the components needed to build Qubes for Windows product core-admincore-admin-windowscore-agent-windowscore-vchan-windowscore-libvirt-windows desktop-windowsgui-agent-windowsgui-commongui-daemonwindows-installer-qubes-for-windowsqubes-builderqubes-manager Additionally we will likely need a few qubes-app- modules that would implement some addons , such as perhaps automatic links and documents opening in specific VMs, eg qubes-app-windows-mime-handlersHere, 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 frameworkNow, if we wanted to create Qubes for Hyper-V we would need the following components core-admincore-admin-windowscore-agent-linuxcore-agent-windowscore-vchan-hypervdesktop-windowsgui-agent-linuxgui-agent-windowsgui-commongui-daemonwindows-installer-qubes-hypervqubes-app-XXXqubes-builderqubes-managervmm-hyperv Here, as an example, I also left optional core-agent-linux and gui-agent-linux 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 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 vmm- components and, of course, the different installerIt 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 LicensingOur business model assumes working with vendors, as opposed to end users, and licensing to them various code modules needed to create products based on QubesAll the code that comprises the base foundation needed for creation of any Qubes variant so core-admin, gui-common, gui-daemon, qubes-builderand qubes-manager 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 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 sourcesAll 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 gui-agent-windows, core-agent-windows, core-admin-windows, etc will most likely be proprietary and will be available only to vendors who decide to work with us and buy a licenseSo, 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 Current status and roadmapWe'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 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 We should be able to publish some code, ie the framework together with early Qubes OS R3 that will be based on it, sometime in fall or maybe earlierWe 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 sourceQubes 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 So, this is all really exciting and a big thing, let's see if we can change the industry with this 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 http://www.secuobs.com/revue/news/435093.shtmlhttp://www.secuobs.com/revue/news/435093.shtml Secuobs.com : 2013-02-28 20:07:12 - The Invisible Things Lab's blog - IMAGE Qubes R2 Beta 2 with KDE 49 environment click for more screenshots 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 our wiki page As usual, please remember to verify the digital signature of the downloaded ISO The major changes in this beta release include Upgraded Dom0 distribution to the latest Fedora 18 all previous releases used Fedora 13 for Dom0 Upgraded default VM template also to Fedora 18 Upgraded Dom0 kernel to 376 Upgraded KDE environment in Dom0 KDE 49 Introduced Xfce 410 environment for Dom0 as an alternative to KDE A few other fixes and improvements, including the recently discussed Disposable VM-based PDF converter 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 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 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 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 few more tickets scheduled for R2 Beta 3 milestone, but most of those represent various addons, rather than modifications to Qubes core software 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 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 qubes-devel mailing list I have already upgraded my primary laptop to this release a few days ago and everything seems to be working fine, so fear not http://www.secuobs.com/revue/news/430756.shtmlhttp://www.secuobs.com/revue/news/430756.shtml Secuobs.com : 2013-02-21 20:49:45 - The Invisible Things Lab's blog - 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 compromise the user's desktop system 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 trusted PDFs Here by a trusted PDF I mean a file that should be harmlessto the user's system, so, a non-malicious PDF IMAGE A few years ago, we have already introduced a mechanism in Qubes OS called Disposable VMs, that can be used to safelyopen 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 eg 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 Approaches to converting PDFs 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 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 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 Anyway, the fundamental problem with the approaches mentioned above, is that all of them require parsingof 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 Parsing PDFs safely 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 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 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 nothing 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 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 expectedto 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 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 Now this is all becoming simple we would expect our parser to send us just two things the dimensions W 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 The diagram below summaries this idea IMAGE Implementing this all on Qubes Now I would like to show how easy it is to implement such PDF converter service using the Qubes advanced infrastructure that we call qrexec, and which is part of Qubes core for quite some time now 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 supports RGB format 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 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 convert pagergb pagepdf Unfortunately this would be wrong, because the convert program would still try to detect the real format of the pagergb 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 convert -size IMG_WIDTH x IMG_HEIGHT -depth IMG_DEPTH rgb RGB_FILE pdf PDF_FILE 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 gappinghole 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 Finally we can write the following two simple bash scripts, one for client qpdf-convert-client, and the other one, qpdf-convert-server, for the server which runs in a Disposable VM Additionally we also need to create a policy file in Dom0 in etc qubes_rpc policy to allow to use this service The policy file content for this service should look like this anyvm dispvm allow which is pretty self explanatory When I do development I also add another line to the policy file like this anyvm devel-vm ask 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 The policy file should be placed in Dom0 in etc qubes_rpc policy qubesPdfConvertfile here the name of the file must be the same as the name of the service, as invoked via qrexec_client_vmcommand, discussed below And, one last thing, in the destination VM we must also create a file that will map the service name so, the qubesPdfConvert 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 etc qubes_rpc qubesPdfConvert again, this is now in a VM, not in Dom0, also note the lack of policy subdir , and it is another one-liner with the following content usr lib qubes qpdf-convert-server The full source code of qpdf-converter can be seen and downloaded from this git repo We're ready now to test our qubesPdfConvert service in the requesting VM, ie the one from which we want to initiate the conversion process we do user work Downloads usr lib qubes qrexec_client_vm ' dispvm' qubesPdfConvert usr lib qubes qpdf-convert-client ITLquotepdf - Sending file to remote VM- Waiting for converted samples- Receving page 2 out of 2- Merging pages into a single PDF document- Converted PDF saved as ITLquotetrustedpdf- Original file saved as ITLquotepdf Again, for development process I would replace ' dispvm' with something like 'devel-vm' The qrexec_client_vmcommand, 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 this one, that makes using the service simple The presented converter saves the original file as original_pdf making it a hidden file to help the user avoid accidental opening The new, converted file gets trustedpdfsuffix 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 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 The qrexec infrastructure takes care about all the under-the-hood tasks, such as starting the necessary VMs, eg 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 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 eg I use this policy to block clipboard and file exchanges between my work and personal domains Limitations, other Simple Representations The obvious disadvantage of converting a PDF to an RGB representation is that one looses text search, as well as copy and edit capabilities eg 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 Eg 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 public 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 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 An interesting question is, however, can we come up with another form of Simple Representation that would allow eg 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 Preventing user mistakes 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 storyUsers 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 We modify the Thunderbird, Firefox, etc, eg 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 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 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 eg 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 Eg 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 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 eg 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 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 Qubes from containers isolation down to apps protection 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 between the VMs 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 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 PS 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 rpms from the git repo PS 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 http://www.secuobs.com/revue/news/429213.shtmlhttp://www.secuobs.com/revue/news/429213.shtml Secuobs.com : 2012-12-14 13:49:36 - The Invisible Things Lab's blog - It's my pleasure to announce the first Beta for Qubes Release 2 is now available for download This release introduces generic support for fully virtualized AppVMs called HVMs in Xen parlance , and specifically initial support for Windows-based AppVMs integration It's been quite a challenge to add support for secure HVMs to Qubes without breaking its security architecture, and I already wrote about it in the past Generic support for HVMs means you can now install many different OSes as Qubes VMs, such as various Linux distros, BSD systems, and, of course, Windows Essentially all you need is an installation ISO and the whole process is similar to creating a VM in a program like Virtual Box or VMWare Workstation although we believe the underlying architecture for this is more secure in Qubes Additionally we provide a set of tools for Windows-based AppVMs Windows 7 specifically which allow for tight integration with the rest of the Qubes system This currently includes support for secure and policy controllable clipboard and file exchanges between the Windows-based AppVMs and other AppVMs, integration with Qubes advanced networking infrastructure, and PV drivers for faster operation As of now there is still no seamless app integration for Windows applications, so Windows VMs are presented as full-desktop-within-a-window, but we're aiming to add support for this in the next Betas Unlike the rest of Qubes, which is distributed under a GPL v2 license, the Qubes Windows Support Tools are not open sourced and are distributed as binaries only, under a proprietary license They are free to use for any Qubes 2 user The tools are not part of the Qubes 2 installation ISO which is GPL , and are down loadable on demand More information about creating and using HVM domains, including Windows-based AppVMs, can be found in the wiki here To summary, here's a quick list of some of the exciting new features that toady's release brings in Support for generic fully virtualized VMs without qemu in the TCB Support for Windows-based AppVMs integration clipboard, file exchange, qrexec, pv drivers Secure audio input to select AppVMs Hello Skype users Clipboard is now also controlled by central policies, unified with other qrexec policies Out of the box TorVM support http wikiqubes-osorg trac wiki HvmCreate Experimental support for PVUSB Updated Xorg packages in Dom0 to support new GPUs DisposoableVM customization support and, as usual, various fixes and other improvements Existing users of Qubes R1 can upgrade without needing to reinstall the upgrade procedure is described here Standard installation is described here Enjoy PS Please send all the technical questions to the qubes-devel mailing list, instead posting them as comments to this blog Keep the comments here for more generic discussions PS2 As usual, I would like to remind that we have little control over the servers that are used for Qubes ISO distributions and that the downloads should be verified according to the procedure described here We always assume that even our own servers git, wiki, yum could be compromised, and yet this should not affect Qubes security in any way, because of the extensive use of digital signatures everywhere in the development and distribution process http://www.secuobs.com/revue/news/417058.shtmlhttp://www.secuobs.com/revue/news/417058.shtml Secuobs.com : 2012-09-12 19:24:17 - The Invisible Things Lab's blog - Many people ask how does Qubes OS differ from other approaches to desktop security Today I'm trying to answer the most popular questions 1 Why bother with Qubes OS, if any Linux BSD already allows to setup different user accounts, or some form of light-weight containers or sandboxes, such as chroot, LXC, SELinux First, if you use Xorg or similar X-based server as your GUI server, and this is what nearly all Linux, and most of the other non-Windows OSes use, then you don't have any form of GUI-level isolation, which is essential for a desktop system I wrote more about this surprising problem some time ago Proper GUI-level isolation was one of the main goals for Qubes Second, all mainstream desktop OSes, such as Windows, Linux, BSD, even OSX, are all based on a monolithic kernels, which present a significant security problem This is because a typical monolithic kernel of a contemporary desktop OS contains tens of millions of lines of code, and to make it worse, most of this code is reachable from untrusted applications via all sorts of APIs, making the attack surface on the kernel huge And it requires just one successful kernel exploit to own the whole system, bypassing any security mechanisms that might have been built on top of it, such as SELinux, LXC, etc Additionally, all the various drivers, networking and USB stacks, are also hosted in the kernel, making attacks via buggy networking eg via buggy 80211 stacksor buggy firmware or USB stacks a practical possibility And there is essentially nothing one can do about it, when using an OS based on a monolithic kernel In Qubes, on the other hand, we use Xen hypervisor to provide security isolation between domains, and Xen is just a few hundred of thousands lines of code It also doesn't need to provide all sorts of APIs to applications, because the Xen hypervisor is essentially only interested in CPU scheduling, memory management and power management, and very few things beyond that Most notably, the Xen hypervisor knows nothing about networking, disk storage, filesystems, USB stacks, etc, as all those tasks are delegated to often untrusted service VMs 2 How is Qubes better than just running a bunch of VMs in VMWare or Virtual Box First, products such as VMWare Workstation or Fusion, or Virtual Box, are all examples of type II hypervisors sometimes called hosted VMMs , which means that they run inside a normal OS, such as Windows, as ordinary processes and or kernel modules This means that they use the OS-provided services for all sorts of things, from networking, USB stacks, to graphics output and keyboard and mouse input, which in turn implies they can be only as secure as the hosting OS is If the hosting OS got compromised, perhaps via a bug in its DHCP client, or USB driver, then it is a game over, also for all your VMs Second, those popular consumer type II VMM systems have not been designed with security as a primary goal Instead, their main focus has been on easy of use, performance, and providing seamless integration of the guest OS es with the host OS Especially the latter, which involves lack of good method to identify which domain a given application belongs to so, lack of trusted Window Manager , support for shared clipboards which every other VM can steal, insecure file sharing methods, and others, all make it not a very desirable solution when strong domain isolation is important This is not to imply that Qubes doesn't support clipboard or file sharing between domains, it does it's just that we do it in a secure way, at least so we believe On the other hand, there are many usability improvements in Qubes that are specific to multi-domain system, and which you won't find in the above mentioned products, such as trusted Window Manager that, while maintaining great seamless integration of all the applications onto a common desktop, still allows the user to always know which domain owns which window, support for advanced networking setups, per-domain policies, the just mentioned secure mechanisms for clipboard and filesystem sharing, and many other Qubes also focuses on making the VMs light-weight so that it was possible to run really a lot of them at the same time, and also on mechanism to allow for secure filesystem sharing between domains templates Finally, the commercial hosted VMMs are really bloated pieces of code They support everything and the kitchen sink eg Open GL exposed to VMs, and various additional interfaces to allow eg 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 3 How does Qubes compare to your favourite academic microkernel While the Xen hypervisor can indeed be considered a microkernel if you're not a strict terminology freak, Qubes itself is much more than just the hypervisor Qubes is everything that is needed to build a reasonably secure desktop OS on top ofa baremetal hypervisor or microkernel Theoretically, with just a few cosmetic changes at least architecture-wise , Qubes could perhaps swap the Xen hypervisor for some other hypervisor or microkernel, such as perhaps Hyper-V, KVM, or some more exotic one Thus, it makes little sense to compare Qubes with a hypervisor or microkernel project What makes sense is to compare the Xen hypervisor, as used in Qubes, with some other hypervisor or microkernel Ok, so how does Xen compare with other hypervisors or microkernels out there We think Xen is unique because it combines an elegant architecture type I, baremetal, hypervisor with a number of practical features, such as power management, support for Intel VT-d and driver domains, support for both para-virtualizaed, and fully-virtualized VMs, and many more, not found in eg academic microkernels hypervisor projects, that otherwise seem attractive from the architecture point of view 4 How is Qubes better than Google Chrome OS First, Chrome OS is not a general purpose OS Second, it's based on Linux with all its security limitation that are a result of using a monolithic kernel described above eg all the networking and USB stacks in the kernel without a possibility to deprivilige them Not being a traditional general purpose OS, Chrome is able to avoid many of the challenges of desktop computing, such as the need to define security domains, inter-domain file exchange as there is essentially no filesystem visible to the user , and others, which is good, of course But then again, Chrome OS is essentially just an environment to run the Chrome Browser, so the comparison to Qubes is a bit of a misunderstanding Technical aspects aside, there is always the privacy concern associated with running everything in a browser why would all my private data be managed and accessible to some 3rd party organizations and their administrators 5 How is Qubes better than your favorite commercial military-grade certified secure OS You must have heard about the super secure military-grade, formally verified, 100pourcents certified, and generally unbreakable operating systems made by companies such as Green Hills, Lynx Works, and others How do they compare to Qubes OS Really, I have no idea For a mere mortal like myself and perhaps not a US citizen , it seems impossible to get any more technical documentation of those systems anything beyond the marketing pseudo-technical gibberish , not to mention a trial copy to play with Thus, from my point of view, those systems are just a vaporware If you, my dear reader, are privileged enough to have access to such system, then good for you, but don't expect me to treat seriously a security product that is not available for a wider audience to touch and play with And the Chineese surely have the copies already to play with 6 How is Qubes different than Bromium's micro virtualization solution Many people asked recently about the Bromium's upcoming product and how it differs from Qubes OS Unfortunately there are few public information available on this product essentially there is one not-very-technical whitepaperand there are Ian Pratt's presentation slides from the recent XenSummit about u-Xen, apparently a hypervisor that is to be ultimately used in their upcoming product The whitepaper suggests that Bromium is based on a hosted type II hypervisor running within a normal Window OS, and that this hypervisor is used to spawn a new micro VM for each new task , where apparently the task might be something as granular as opening a new tab in a Web browser, which makes it somehow similar to Google Chrome's approach Clearly, the Bromium's main goal seem to be to automate the process of creating separation domains, which is in contrast with what we do on Qubes OS, where the user is required to define the domains explicitly The Pratt's slides provide also some technical insight into how Bromium intends to secure their hypervisor As just discussed above, a hosted hypervisor must normally trust the hosting OS, in this case Windows, which, for obvious reasons, is not a good idea from the security standpoint Pratt, however, clearly states that host can not interfere with the privacy or integrity of the hypervisor or other guests slide 8 This is a strong statement, so let's take a closer look at their approach to this problem The Bromium's idea of how to make their hypervisor and the VMs protected from a potentially malicious host OS is not really breakthrough the slides suggest to deprivilege the host into a VT-container I think the verb to bluepillis now an accepted term for such action , and to remove the host's access to the hypervisor pages via EPT , as well as protect DMA access from devices via VT-d, plus to make this all sensible, use DRTM scheme such as Intel TXT, to load such a hypervisor from within a potentially untrusted OS So, what's wrong with the idea of a load-on-the-fly-secure-VMM-system Isn't Ian Pratt correct that one could protect its memory and execution from the interference of the host Actually that is possible Intel TXT, VT-x, VT-d, and EPT give us means to achieve that although there are a number of catches here But he's missing one important point it's the untrusted OS that still owns and manages the input devices eg via USB stacks and drivers and, most importantly, the output via the GUI subsystem and drivers Ensuring that the host OS cannot interfere eg sniff the screen of trusted applications might be very difficult, or even impossible, in practice If I ever was to break the security of such a system, I would just follow the simple way 1 Infect the host eg via one of the many USB attacks remember they cannot have sandboxed USB driver domain, as they have only a type II hosted hypervisor ,2 Hook somewhere into the GUI subsystem and keep recoding all the interesting data from the screen or something like that There are also many other things that needs to be answered and which the publicly available documents are silent about, such as eg 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 7 How is Qubes different from Xen Client In many aspects, Xen Clientmight be the most similar product to Qubes OS Like Qubes, it is based on the Xen hypervisor and so it is also a standalone OS, that one must install instead of one's favorite system, and also, like Qubes, it is targeted for desktop systems, and also offers a possibility to run a few VMs at a time However, XenClient has been designed with a different goal in mind, namely as a Virtual Desktops To Go solution, while Qubes has been designed to provide seamless experience for secure multi-domain desktop system As a result, lots of focus in Qubes has been put on creating trusted GUI subsystem, support for advanced networking configurations, secure inter-VM clipboard and file sharing, secure method to reuse the same filesystem as a basis for the AppVMs, and also to optimize the AppVMs so they start almost instantly and take little memory, so that one could easily run many of them at the same time All those things seem to be missing from Xen Client as well as solid technical documentation about its design I surely have missed a few other products or approaches -- feel free to point them out in the comments, and I might write a continuation post one day http://www.secuobs.com/revue/news/399226.shtmlhttp://www.secuobs.com/revue/news/399226.shtml Secuobs.com : 2012-09-03 11:43:18 - The Invisible Things Lab's blog - After nearly three years of work, I have a pleasure to announce that Qubes 10 has finally been released To see the installation instructions and to get an ISO, please go to this page I would like to thank all the developers who have worked on this project Creating Qubes OS has been a great challenge, especially for such a small team as ours, but ultimately, I'm very glad with the final outcome it really is a stable and reasonably secure desktop OS In fact I cannot think of any more secure alternative I use the term reasonably secure , because when it comes to defensive security it's difficult to use definite statements secure , unbreakable , etc , unless one can formally prove the whole design and implementation to be 100pourcents secure Unfortunately, contrary to a common believe, there are no general purpose, desktop OSes, that would be formally proven to be secure At the very best, there are some partsthat are formally verified, such as some microkernels, but not whole OSes And what good is saying that our microkernel is formally verified, if we continue to use a bloated and buggy X server as our GUI subsystem After all, a GUI subsystem has access to all the user inputs and output, thus it is as much security sensitive, as is the the microkernel Or power management subsystem, or filesystem server, or trusted boot scheme, or a dozens of other elements, which just cannot be forgotten if one wants to talk about a truly secure OS As said before, I know of no general-purpose desktop OS that would be formally proven, and thus that could be called secure You can also read more about challenges with formal verification microkernels in this article, and especially in this comment from the seL4 project leader In Qubes OS we took a practical approach and we have tried to focus on all those sensitive parts of the OS, and to make them reasonably secure And, of course, in the first place, we tried to minimize the amount of those trusted parts, in which Qubes really stands out, I think So, we believe Qubes OS represents a reasonably secure OS In fact I'm not aware of any other solution currently on the market that would come close when it comes to secure desktop environment But then again, I'm biased, of course I wouldn't call Qubes OS safe , however, at least not at this stage By safe I mean a product that is safe to use , which also implies easy to use , not requiring special skills , and thus harmless in the hands of an inexperienced user I think that Apple iOS is a good example of such a safe OS it automatically puts each application into its own sandbox, essentially not relaying on the user to make any security decisions However, the isolation that each such sandbox provides is far from being secure, as various practical attacks have proven, and which is mostly a result of exposing too fat APIs to each sandbox, as I understand In Qubes OS, it's the user that is responsible for making all the security decisions how to partition her digital life into security domains, what networkand other permissions each domain might have, whether to open a given document in a Disposable VM, etc This provides for great flexibility for more advanced users, but the price to pay is that Qubes OS requires some skills and thinking to actually make the user's data more secure Generally Qubes OS is an advanced tool for implementing Security by Isolation approach on your desktop, using domains implemented as lightweight Xen VMs It tries to marry two contradictory goals how to make the isolation between domains as strong as possible, mainly due to clever architecture that minimizes the amount of trusted code, and how to make this isolation as seamless and easy as possible Again, how the user is going to take advantage of this isolation is totally left up to the user I realize this might be a tricky part for some users and some usage scenarios, yet, on the other hand, this seems to be the most flexible and powerful approach we could provide Thus people should realize that by mere fact of using Qubes OS they won't become automatically more secure it's how they are going to use it might make them significantly more secure A hypothetical exploit for your favourite web browser would work against Firefox running inside one of the Qubes VMs just as well as it worked for the same browser running on normal Linux The difference that Qubes makes, is that this attacked browser might be just your for-personal-use-only browser which is isolated from your for-work-use-only-browser, and for-banking-use-only-browser Finally, even though Qubes has been created by a reasonably skilled team of people, it should not be considered bug free In fact, over the last 3 years we already found 3 serious bugs attacks affecting Qubes OS one of them in the very code we created, and two other in Intel hardware Again, we tried as much as possible to limit the amount of code that is security sensitive in the first place, yet we are just humans So, I'm very curious to see others' attempts to break Qubes I think it might make for a very interesting research A good starting point for such research might be this page And I know there are individuals out there who apparently only been waiting for Qubes 10 to come out, to get some glory yet, it's not clear to me why to attack qemu, which is not part of the TCB in Qubes, but I guess great minds have their own mysteries In other words, please enjoy Qubes OS 10, hopefully it could make your digital life safer Please send all the technical questions regarding Qubes to the qubes-develmailing list Do not send them to me directly, nor post them in this blog's comments http://www.secuobs.com/revue/news/397291.shtmlhttp://www.secuobs.com/revue/news/397291.shtml Secuobs.com : 2012-07-21 16:16:32 - The Invisible Things Lab's blog - I would like to announce the release of Qubes RC1 The installation ISO and instructions can be found here IMAGE This release is expected to essentially be identical to the final 10 release, which will likely follow in the coming weeks, except for some minor, cosmetic fixes Comparing to the previous Beta 3 release, the major changes and improvements in this version include A much improved Qubes Manager, that now allows to configure and manage almost every aspect of the Qubes system using a simple and intuitive GUI All the VMs are now based on Fedora 17 template Cleaned up and improved command lines tools for both Dom0 and for the VMs Updated Dom0 and VM kernels are now based on 327-pvops kernel, which offer better hardware and power management support Convenient menu improvements, that include eg a handy icon for launching a Disposable Web browser in a Disposable VM Support for yum proxy , which smartly allows to update packages in a template VM or other updateable VM , without requiring to grant general HTTP access for this VM This has been a problem before, as the Fedora repos use hundreds of mirrored yum servers, and it wasn't possible to setup a single rule in the firewall VM to allow only access to the yum servers, and nothing else Now, this is possible, and the primary application is to prevent user mistakes, eg against using the temaplate VM for Web Browsing We also added support for an opt-in fullscreen mode for select VMs plus lots of other improvements and fixes under the hood As can be seen in the wiki, there has been over 200 tickets closed as part of the work on this release So, again, this is almost the final release, please test it and report any problems to the mailing list, so that we could fix them before Qubes 10 comes out officially http://www.secuobs.com/revue/news/388834.shtmlhttp://www.secuobs.com/revue/news/388834.shtml Secuobs.com : 2012-06-27 16:29:33 - The Invisible Things Lab's blog - About a year ago I wrote about Why the US password revolution won't work, where I pointed out that a massive move towards two-factor authentication will not solve any of the identity theft problems that users experience today Specifically, I wrote People don't understand that the compromised operating system can impersonate the user at will The compromised OS could have saved your PIN to this smart card when you used it previously even if you configured it not to do so and now, immediately, it could use the inserted card to authenticate as you to the bank and start issuing transactions on your behalf And you won't even notice this all, because in the meantime it will show you a faked screen of your banking account After all, it fully controls the screen The bottom line is that we cannot secure our digital lives, if our client operating systems could not be secured first But introduction of tokens won't make our operating systems any more secure This article sparked lots of controversy with many people, who considered it a fallacy to criticize two factor authentication Today, I came across the news about Operation High Roller, discovered recently by McAfee and Guardian Analytics They released a paper with some details about the attacks and the malware deployed Some interesting quotes All of the instances that involved High Roller malware could bypass complex multi-stage authentication Unlike recent attacks that collect simple form authentication data a security challenge question, a one-time token, or PIN this attack can get past the extensive physical something you have authentication required by swiping a card in a reader and typing the input into a field see Two-factor Authentication sidebar The attack asks the victim to supply the information required to get around the physical controls of smartcard reader plus pin pad entry to generate a one-time password or digital token Having collected all the information it requires for the entire transfer, the malware stalls the user and executes its transaction in the background using the legitimate digital token Multiple after-the-theft behaviors hide evidence of the transaction from the user For example, the client-side malware kills the links to printable statements It also searches for and erases confirmation emails and email copies of the statement Finally, it also changes the transactions, transaction values, and account balance in the statement displayed on the victim s screen so the amounts are what the account holder expects to see Defensive security is a difficult game, because one doesn't immediately see whether a given solution works or not This is in stark contrast to other engineering disciplines and to offensive security where one usually have immediate feedback on whether something works well or not Say you want to build a redundant long-range video downlink for your unmanned, remotely operated helicopter -- you can throw in lots of money buying various high-gain antennas, circular antennas, antenna trackers, diversity systems, etc, but then ultimately you can verify your creation immediately by going into a field and trying to fly a few miles away, and see whether you loose the vision usually in the middle of some life-threatening manoeuvre or not At least you can draw some lines of how good your solution is I can fly up to one mile away, but not more, unless there aren't that many trees around and the air is dry enough With security, especially with computer security, it is so different, because there is no immediate feedback This results in various vendors pitching their products as wonderful solutions that just solve all the worlds problems, even though what they're saying in those marketing materials might be pure nonsense BTW, congrats to Simon Crosby for apparently creating a Windows-hosted VMM in below 10k LOC The often made mistake is to say Perhaps there is a way to attack this solution, but then again, how much of the malware in the wild implements such attacks This is a classical thinking in our industry, and in my opinion, an inexcusable mistake Let me say it clearly It doesn't matter whether what the malware in the wild does -- it matters what it could potentially do So, if we can do a quick brainstorming session and point out potential attacks within 1 hour against some technology product X, then, if we don't see a solution how to prevent them generically, we should not bother and implement product X, because it will be defeated, sooner or later Let's not waste time on useless solutions, life's too short http://www.secuobs.com/revue/news/384113.shtmlhttp://www.secuobs.com/revue/news/384113.shtml Secuobs.com : 2012-03-03 13:06:49 - The Invisible Things Lab's blog - Ok, let's start with a screenshot IMAGE While the Qubes 10 branch iscurrently in the final development and testing, we have alreadystarted working on the Next Big Feature, which is a support for HVMdomains hardware, or VT-x virtualized domains This allows to runeg Windows VMs under Qubes You might be wondering what so specialabout this, if Xen has been supporting HVM domains, and specificallyWindows VMs for a long time, and Qubes uses Xen hypervisor, so whyhaven't we had Windows support since day one The are a couple of things that wedon't like about HVM support in Xen and also in other VMMs , whichinclude the need to run device emulator AKA qemu in Dom0, the needto use crappy VNC, or a similar protocol to access the VM'sframebuffer, or alternatively, the crazy idea from security point ofview, that is of using a pass-through graphics for a VM, the lack ofsupport for disaggregated architecture where backends, eg networkbackends, run in other domains than Dom0 In fact even the Xen stubdomain feature, introduced a few years ago, that wassupposed to be a solution allowing to move the qemu out of Dom0, inpractice turned out to be quite disappointing, as the qemu in thestub domain still requires an accompanying process of another qemu inDom0, somehow negating all the security benefits this architecture issupposed to bring And not to mention the omni present assumptionthat backends run always in Dom0, hardcoded in a few places in thestubdomain code So, we didn't like it and that's whyQubes had no Windows support for long time But this has now changed,as we have just finished the 1st stage implementation ofHVM support in Qubes, the way we like it, without any securitycompromises In our implementation we've completely eliminated allthe qemu remains from Dom0 it's running in a micro stub domain , thegraphics virtualization fully integrates with our very slim GUIdaemon we didn't have to modify our GUI daemon at all , using ourXen-optimized, zero-copy, minimalist GUI protocol, and the networking isalso fully integrated with the Qubes diaggregated networkingarchitecturethat uses isolated domains for all the networking stacks and driversOf course, there are still some rough edges, such as no clipboardsupport, and the virtualization is currently in a per-desktop mode, rather than in a per-window mode, which is used for PVdomains But, rest assured, we are working on those things rightnow This code is currently not public, andthe plan is to release it only after Qubes 10 release, either as anupgrade, or as Qubes 20 All the dom0 code for HVM support willlikely remain GPL, while any Windows-specific code agent code willlikely be proprietary http://www.secuobs.com/revue/news/361259.shtmlhttp://www.secuobs.com/revue/news/361259.shtml Secuobs.com : 2012-02-06 12:07:39 - The Invisible Things Lab's blog - A new ISO with the just released QubesBeta 3 is now available for download here Beta 3 fixes lots of annoying problemsdiscovered in Beta 2 and earlier releases, and also implements abunch of useful feature This includes the qvm-block tool and infrastructure for easy attachment of block devices to any AppVM,no matter which system VM is handling the actual USB controller So,this allows to have untrusted USB domain s , almost seamlesslyintegrated in the desktop system One can consider to use it in orderto prevent various USB attacks Thenext release the 10 will bring this feature to the Qubes GUImanager as well, making it easy to use for non-command-line userstoo Also, we have now introduced fullyautomatic Qubes build system, that allows to build all the Qubespackages, and also create the installation ISO, with just onecommand More information on this system and on how to use it can be found inthe wiki We have also updated to Fedora 15-basedtemplate as a default Unfortunately F16-based template would requiretoo much work to get all the Gnome 3 stuff working correctly The challenge here, is that we don't run a normal Windows and Desktop manager in every domain, in order to make the VMs light weight, and so we need to sometimes work around various problems this causes Finally, we have added two newQubes-specific applications A plugin for Thunderbird it isautomatically installed in the template , that allows for one clickopening of attachments in Disposable VMs, as well as one-click savingof the attachment to select VM And something we call splitGPG , that I will describe in a separate article later ThoseQubes-specific applications are based on our Qubes RPC, introduced in Beta 2 This is likely the last release beforethe final 10 , that is scheduled to follow soon TM The only major work for 10 is GUI manager improvements toexpose most of the Qubes functionality via clickable GUI, and commandline tools cleanup and documentation Plus testing and bugfixing Andthen, the next thing we will be working on will be support for HVMdomains, eg Windows This work is starting actually just about now, but code will be released only after Qubes 10 http://www.secuobs.com/revue/news/356131.shtmlhttp://www.secuobs.com/revue/news/356131.shtml Secuobs.com : 2012-01-21 18:16:00 - The Invisible Things Lab's blog - Several people asked me recently what Ithough about DeepSafeSo, below I present my opinion First, for any AV system or Host IPS,or Personal Firewall, etc to work effectively, there are three problems that must be addressed 1 How to protect the AV agent code and data from tampering from the rest of the OS 2 How can the AV agent get reliable access to sensitive pieces of the system memory and registers, and or provide reliable memory protection for the sensitive pieces of the OS 3 What are those sensitive pieces of memory that should be monitored or protected From reading various PR materials, itseems like the 1 above is the primary differentiation factor forDeepSafe DS So, let's consider this problem in the context of ega Windows OS In order to protect its code and data, DS uses, as itis heavily advertised, Intel VT-x virtualization technology Now,that sounds really secure -- after all what can be more secure than ahardware virtualization, right But VT-x including EPT is only aboutCPU virtualization, which in our case translates to protecting the DSmemory and registers from CPU-originating accesses But, as everyregular to this blog knows, there is also another method of accessingmemory on any PC system, and this is through DMA transactions fromdevices The OS so also the kernel malware is free to program oneof the many devices in the system to issue DMA reads or writes to anyphysical memory itwants Now, in order to protect some portionof the system memory DRAM, cache against DMA accesses, we have theIntel VT-d technology So, one would think that DS must be alsousing VT-d in order to protect itself Very well, let's assume then that theDeepSafe is not a total ripoff,and that it implements also VT-d protection for its agent, although Ihaven't found this mentioned in any of the public papers or pressmaterials I found on the web This, however, would be a bit complexto do correctly, because the OS so, also the kernel malware stillhas a full control over the chipset MCH , which is the entitythat controls the VT-d Now, in order toprevent the OS or the kernel malware from playing with the chipsetfor fun and profit, and eg disabling VT-d protection, DS would haveto virtualize the chipset If you look at some consumer VMMs, suchas VMware or Xen Qemu, you would see that they all virtualize thechipset for their guests of course , but that the chipset theyprovide this way is some kind of an ancient Pentium MCH I don'tthink any of the consumers would be especially happy if they foundout that after installing DS on their brand new 2012 laptop, Windowssuddenly see a Pentium-era chipset And this is not without areason chipsets, specifically MCHs, are one of the most complexdevices, perhaps only beaten by GPUs in this category There arevirtually hundreds of configuration registers exposed by the chipset,some of them control the VT-d, some other control system memory mapsand permissions, PCIe configuration, and many other things that Ieven have no idea about, and this all makes virtualizing the chipseta very challenging task So, it's either that McAfee and Intelfound some interesting way of how to securely virtualize the chipsetwhile preserving all of its very rich functionality, or thatthey don't bother with VT-d protection and chipset virtualizationat all, assuming that even without VT-d, DeepSafe is good enough and rises the bar anyway sarcasm intended Can somebody from McAfee or Intelconfirm in the comments below what does DP really do Anyway, let's assume they dohave VT-d protection and they do virtualize the chipsetsomehow Now, we're moving on to the 2 pointfrom the list of tasks above -- about the reliablememory access or reliable protection So, let say that the DS agent decidedthat some part of the system memory, eg the IDT table, is sensitiveand should be monitored protected So it sets up EPT traps to triggeran VT-x EPT intercept on any access to that memory or IDT baseregister , in order to find kernel malware that tried to modify IDTThat sounds really nice, but what if the malware uses DMA to modifyIDT DS would not be able to catch such access So far we consideredthe, hypothetical, use of VT-d only to protect the DS agent code One might think that DS is programmingVT-d to sandbox each and every device in the system so includingGPU, USB controllers, NICs, SATA, etc so they never beallowed to touch any of those sensitive parts of the system, such asIDT Let's assume they do it this way And here we've arrived to the lastpoint from the list at the beginning which of the system memoryconstitutes those sensitive pieces that should beprotected monitored IDT Sure What about all the code sections ofthe all the kernel modules Yes Are we fine now Well, no, becausethe malware can hook some pointers other than the well known IDTSome public NDIS data structure Ok, we can add those to theprotected areas But, what about some undocumented NDIS structures And this is just NDIS subsystem, one of the many subsystems in theWindows kernel When we think about it, it should be intuitivelyobvious that in a general purpose Operating System like Windows, itis not possible at least for 3rd party to make asatisfactory list of all the sensitive pieces of memory that shouldbe monitored protected, in order to detect all the systemcompromises Greg Hoglund, Jamie Butler, AlexTereshkin, and myself, have been researching this area actively inthe early years of this millennium In addition to the Alex's paperlinked above, you might also check out one of my last slides fromthisperiod I don't think anything has changedsince that time It was also the reason why I gave up on writingWindows compromise detectors, or forensic tools, and moved on toresearching other ways to secure OSes, which finally gave birth toQubes OS, many years later So, back to DS -- in order to provide asomehow satisfactory protection level for your general purpose OS,such as Windows, it would need to 1 Use VT-d to protect its own memory, 2 Virtualize the chipset, at least some sensitive parts of it, 3 Program VT-d permissions for each device to exclude all the sensitive areas in the system that should be protected, and also protect one device from DMAing into from another device memory eg NIC stealing GPU framebuffer, or inserting instructions to the GPU instruction buffer, or keystrokes to USB controller buffer Ideally, this could be done by programming VT-d to grant each device only access to its own DMA buffer, but as far as I know, this would be very hard to implement, if not impossible for a 3rd party, on a Windows OS in contrast to Linux, which mostly support this model Please correct me, if the recent Windows version allows for such use of VT-d 4 Finally, and the most hard thing to solve, how to define all the sensitive pieces of memory in the system that should be protected and or monitored Although this is a somehow more generic problem, not specific to DS, but applying to any A V, HIPS, or forensic tool So, is DeepSafe another piece of crap not worth any special attention, or has McAfeeand Intel came up with some novel methods, eg for chipsetvirtualization, 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 afterall DeepSafe seems to be just a new incarnation of my Bluepill http://www.secuobs.com/revue/news/353370.shtmlhttp://www.secuobs.com/revue/news/353370.shtml Secuobs.com : 2011-12-13 20:45:26 - The Invisible Things Lab's blog - Wouldn't it be nice if we couldactually own our data and programs in the cloud By owning hereI mean to have control over their confidentiality and integrity Whenit comes to confidentiality and integrity for the data,it's not much of a rocket since, as the classic crypto andsecure client systems is all that we need Ihave already wrote about it in an earlier post But itwould also be nice, if we could somehow get the same confidentialityand integrity assurance for our programsthat we upload for the execution in the cloud Forexample, a company might want take theirdatabase application, that deal with all sorts of corporate criticalsensitive data, and then upload and safely run this application on egAmazon's EC2, or maybe even to some China-based EC2-clone Currently there is really nothingthat could stop the provider, who has a full control over the kernelor the hypervisor under which our application or our VM executes, from reading the contents of our process' memory and stealingthe secrets from there This is all easy stuff to do from the technical point ofview, and this is also not just my own paranoia Plus,there are the usual concerns, such as is the infrastructure of thecloud provider really that safe and secure, as it is advertised Howdo we know nobody found an exploitable bug in the hypervisor and wasnot able to compromise other customer's VMs from within theattacker-hired VM Perhaps the same question applies if we didn't decided to outsource the apps to a 3rdparty cloud, but in case of a 3rdparty clouds we really don't know about what measures have beenapplied Eg does the physical server on which my VMs are hosted also used to host some foreign customers From China maybe Youget the point Sometimesall we really need is just integrity, eg if we wanted to host anopen source code revision system, eg a git repository or a fileserver Remember the kernelorg incident On a side note, I find the Jonathan Corbet's self-comforting remarkson how there was really nothing to worry about, to be strikinglynaive I could easily think of a few examples of how theattacker s could have exploited this incident, so that Linus co would never not soon find out But that's another story But, how can one protect a running process, or a VM, from apotentially compromised OS, or a hypervisor VMM Tosome extent, at least theoretically, Intel Trusted ExecutionTechnology TXT , could be used to implement such protectionIntel TXT can attest to a remote entity, in that case this would bethe cloud customer, about the hash of the hypervisor or kernel that has beenloaded on the platform This means it should be possible for the userto know that the cloud provider uses the unmodified Xen 411 binaryas the hypervisor and not some modified version, with a built-in FBI backdoor formemory inspection Ok, it's a poor example, because the Xenarchitecture and any other commercially used VMM allow the administrator who controls Dom0 or equivalent to essentiallyinspect and modify all the memory in the system, also that belongingto other VMs, and no special backdoors in the hypervisor are needed for this But let's assume hypothetically that Xen 50 would change thatarchitecture, and so theDom0 would not be able to access any other VM's memory anymore Additionally,if we also assumed that the Xen hypervisor was secure, so that it wasnot possible to exploit any flaw in the hypervior, then we should be fineOf course, assuming also there were also no flaws in the TXT implementation, and that the SMM was properly sandboxed, or that we trusted some partsof the BIOS these are really complex problems to solve in practice, but I knowthere is some work going on in this area, so there is some hope Such aTXT-bases solution, although a step forward, still requires us to trust the cloud provider abit First, TXT doesn't protect against bus-level physical attacks think of an attacker who replaces the DRAM dies with some kind ofDRAM emulator a device that looks like DRAM to the host, but onthe other end allows full inspection modification of its contents well, ok, this is still a bit tricky, because of the lack ofsynchronization, but doable Additionallyfor Remote Attestation to make any sense, we must somehow know thatwe talk to a real TPM, and not to some software-emulated TPMThe idea here is that only a real TPM would have access to aprivate key, called Endorsement Key, used for signing during RemoteAttestation procedure or used during the generation of the AIK key,that can be used alternatively for Remote Attestation But thenagain who generates and so owns the private endorsement keys Well,the TPM manufacturer, that can be some Asian company that we notnecessarily want to trust that much Now we see it would really be advantageous for customers, if Intel decidedto return to the practice of implementing TPM internally inside the chipset, as they did in the past for their Series 4 chipsets egQ45 This would also protect against the LCP bus-level attacksagainst TPM although somebody told me recently that TPM in currentsystems cannot be so easily attacked from LCP bus, because of someauthentication protocol being used there I really don't know, asphysical attacks have not been the area we ever looked atextensively any comments on that Butthen again, the problem of DRAM content sniffing always remains,although I would consider this to be a complex and expensive attackSo, it seems to me that most governments would be able to bypass suchTXT-ensured guarantees in order to tap the user's programsexecuting in the cloud provides that operate within theirjurisdictions But at least this could stop malicious companies fromstaring up fake cloud services with an intent to easily harvest somesensitive data from unsuspecting users 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 First,they could opt for adding an in-processor hardware mechanism forencrypting all the data that leave the processor, to ensure thateverything the is kept in the DRAM is encrypted and, of course, alsointegrity-protected , with some private key that never leave the processor This could be seen as an extension to the Intel TXT This would mean, however, we still needed to relay on 1 the hypervisor to not contain bugs, 2 the whole VMM architectureto properly protect VM's memory, specifically against the Dom0, 3 Intel TXT to not be buggy either, 4 SMM being properly sandboxed, oralternatively 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 bymoving the TPM back onto the chipset, as mentioned above , and finally, 7 on theencryption key used by the processor for data encryption to be safelykept in the processor That'sstill quite a lot of things to trust, and it requires quite a lot of work to make it practically really secure The other option is a bit more crazy, but also more powerful Theidea is that the processor might allow to create untrustedsupervisors or hypervisors Bringing this down to x86 nomenclature, it would mean that kernelmode 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 beensome academic work done in this areaOf course, there are many catches here, as this would requirespecifically written and designed applications And if we everconsidered to use this technology also for client systems how niceit would be if we could just get rid of some 200-300 kLOC of the Xenhypervisor from the TCB in Qubes OS , the challenges are evenbigger, mostly relating to safe and secure trusted output screen and, especially, input keyboard, mouse Ifthis worked out, then we would need to trust just one element theprocessor But we need to trust it anywayOf course, we also need to trust some software stack, eg thecompilers we use at home to build our application, and the librariesit uses, but that's somehow an unrelated issue What is important isthat we now would be able to choose that important software stackourselves, and don't care about all the other software used by thecloud provider As Iwrote above, the processor is this final element we always need torust In practice this comes down to also trusting the US government But we might imagine users consciously choosing egChina-based, or Russia-based cloud providers and require cryptographically to run their hosted programs on US-madeprocessors I guess this could provide reasonable politically-based safety And there is also ARM, with its licensable processor cores, where, I canimagine, the licensee eg an EU state would be able to put theirown private key, not known to any other government here I assume thelicensee also audits the processor RTL for any signs of backdoors I'm not sure if it would bepossible to hide such a private key from a foundry in Hong Kong, orsomewhere, but luckily there are also some foundries within the EU In anycase, it seems like we could make our cloud computing orders ofmagnitude safer and more secure than what is now Let's see whetherthe industry will follow this path http://www.secuobs.com/revue/news/346929.shtmlhttp://www.secuobs.com/revue/news/346929.shtml Secuobs.com : 2011-12-06 11:46:49 - The Invisible Things Lab's blog - 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 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 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 You can get the paper here Intel also published an advisory yesterday, which can be downloaded from their website here The advisory is peculiar in a few ways, however First, the advisory I'm referring to the revision 10 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 Second, the advisory assigns only an Important rating to this vulnerability, even though another Intel advisory, published some two years ago for a problem also reported by us, and which which was strictly a subset 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 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 eg 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 http://www.secuobs.com/revue/news/345549.shtmlhttp://www.secuobs.com/revue/news/345549.shtml Secuobs.com : 2011-09-28 17:22:16 - The Invisible Things Lab's blog - Today, I would like to showcase some of the cool things that one can do with the Qubes networking infrastructure, specifically with all the new features that have been brought by the just released Qubes Beta 2 This will cover the use of multiple Net VMs for creating isolated networks, the use of a Proxy VM for creating a transparent Tor Proxy VM, as well as demonstration of how to use a Standalone VM with manually assigned devices, to create a WiFi pen-testing VM, which surely represents the for fun aspect of this post Qubes Networking Intro From the networking point of view there are three types of VMs in Qubes Net VMs, that have networking devices assigned to them, such as eg a WiFi or Ethernet card Each Net VM contains a Xen network backend that is used to provide networking to all VMs that are connected to this Net VM Regular VMs AppVMs that use the networking provided by Net VMs so they have Xen network frontends that provide virtual interfaces that are backed by the backend in the corresponding Net VM Proxy VMs that combine both of the above to Net VMs they look like regular AppVMs, because they are consumers of the networking they provide, but to other AppVMs they act as if they were Net VMs themselves, allowing other VMs to connect to them Of course the Proxy VMs do not have directly assigned networking devices they use the networking provided by the Net VM that they connect to One can chain many Proxy VMs, as we will see below The virtual interfaces in client VMs are called ethX, and are provided by the xen_netfront kernel module, and the corresponding interfaces in the Net Proxy VM are called vifXY and are created by the xen_netback module Each Net and Proxy VM implements NAT, specifically masquerading, for all the connected VMs Additionally to this SNAT, each Net or Proxy VM provides also DNAT redirection for DNS resolutions, so that each VM behind a Proxy or Net VM thinks that it uses a DNS in the Net Proxy VM, but in fact all the DNS request are DNAT-ed by all the Proxy and Net VMs down the original DNS that is provided to the final Net VM This smart trick allows us to avoid running a DNS caching server in Proxy Net VMs Also, any VM-to-VM traffic, among the VMs connected to the same Net Proxy VM is blocked by default Additionally, each Proxy VM enforces system-wide firewaling rules, specifically the rules for all the directly connected VMs Those firewalling rules are centrally managed in Dom0 and exposed to each Proxy VM through Xen store One useful application of this firewalling mechanism is to limit certain VMs to only specific type of white-listed traffic to minimize likelihood of user mistakes A good example could be a work VM that might be limited to network connectivity only with the select corporate servers and denied all other traffic This way, when the user receives an email message with an embedded http link possibly leading to a malicious website and accidentally clicks on it, nothing wrong happens The current infrastructure doesn't support IPv6 routing, but we will likely add this support in the upcoming Beta 3 The default networking topology in Qubes OS When you proceed with the default installation of Qubes Beta 2, then your initial networking topology looks like on the diagram below IMAGE The default network configuration in Qubes So, by default there is one Net VM, called 'netvm', that is automatically assigned all the networking devices in the system There is also one Proxy VM, called 'firewallvm' that is directly connected to the default Net VM, and which provides networking to all other VMs in the system This Proxy VM is used for firewall rules enforcement Each such service VM consumes 200MB of RAM by default Network-isolated VMs For some VMs it might be desirable to completely disconnect them from any kind of networking access This can be easy done using the following command issued from Dom0's konsole dom0 qvm-prefs -s netvm none For example I have a 'vault' VM that I use for keeping my master PGP keys, and other secrets, and this machine is not connected to any network Using multiple Net VMs for physically isolated networks In some scenarios the machine might be connected to two or more physically separate networks eg safe corporate intranet, reachable via ethernet cable on the user's desk, and the unsafe and evil Internet, reachable via WiFi card It is easy to use more than one Net VMs in Qubes, and assign different networking devices to different Net VMs, and also decide which VMs are connected to which Net VMs The diagram below presents an exemplary such setup IMAGE A simple setup with two isolated networks, and one fully isolated domain 'vault' We could created such a setup using the following commands issued in Dom0 dom0 qvm-create netvm1 --net --label red dom0 qvm-create netvm2 --net --label yellow Currently qvm-create when used with the --net option automatically assigns all networking devices to the just created VM, so in the example above you would want to remove extra devices from each Net VM using qvm-pci -d, leaving only those you really want, eg dom0 qvm-pci -l netvm1 to get a list of currently assigned devices dom0 qvm-pci -d netvm1 02 000 Now we should create the Firewall VMs dom0 qvm-create firewallvm1 --proxy --label green dom0 qvm-create firewallvm2 --proxy --label green and connect them to proper Net VMs dom0 qvm-prefs firewallvm1 netvm netvm1 dom0 qvm-prefs firewallvm2 netvm netvm2 And now, for any other VM, just set the appropriate Net VM either firewallvm1 or firewallvm2, or 'none , to get it assigned to either of the isolated networks, eg dom0 qvm-prefs banking netvm firewallvm1 dom0 qvm-prefs xfiles netvm firewallvm2 dom0 qvm-prefs vault netvm none This configuration provides very strong isolation between the VMs belonging to network 1, and the VMs belonging to network 2 Specifically, this becomes significant if we fear about potential remotely exploitable bugs in the client code of the core TCP IP stack in this case the Net VM could potentially compromise all the connected VMs -- but the same problem applies to even physically separated machines that use the same network Setting up Tor Proxy using a Proxy VM Let's now play a bit with Proxy VMs and see how we can use it to create a simple Tor proxy VM Such a VM would provide anonymized networking to all its clients, so would allow to easily create VMs for anonymous Internet access The simple setup we would like to prepare is depicted on the figure below IMAGE The 'torvm' Proxy VM provides anonymized networking to 'anon-web' and 'anon-bitcoin' VMs All the traffic generated by the VMs behind 'torvm' is either fed into the Tor network, or discarded Furthermore, any app running in those VMs is not able to read any global system identifiers, such as the external IP, external MAC address, etc Our Tor proxy would forward only the Tor traffic, so we don't have to fear about some Tor-not-aware applications, or even intentionally malicious ones to compromise the privacy of our connection This is because such applications have no way to generate traffic to the outside world without going through our Tor proxy unless they could exploit a hypothetical vulnerability in the Tor process running in the Tor VM Also, the applications running in any VM behind the Tor proxy are not able to determine any globally identifiable IDs, such as the user's external IP address, the real MAC address used by real NICs, etc Interestingly just after writing the above paragraph, I discovered that one of our xenstore keys had wrong permissions and, as a result, any VM could read it and get to know the actual external IP the key is used by a Net VM to communicate the external IP configuration to the connected Proxy VMs, so they could know when to update the firewall configuration The fix for this problem is here, and the update qubes-core-dom0-1632 is now available for Dom0 just use qvm-dom0-update to get it installed So, this represents a rather strong setup for use with Tor Let's now have a look at how to practically create such a configuration, step by step First, let's create the VM that will become our Tor proxy dom0 qvm-create torvm --proxy --label green This will create a Proxy VM named 'torvm', based on the default template We will need to now start the template VM and install the Tor client there dom0 qvm-run -a fedora-14-x64 gnome-terminal Alternatively, if we didn't trust the Tor client rpm package to be non-malicious, specifically for its installation scripts to be non malicious, we could have based this on a different template, eg one used for less trusted VMs, or we could installed the Tor client in usr local, that is backed by the VM's private storage, but this would require compiling Tor from sources Now, in the just started template VM, lets install the Tor client and optionally the Vidalia graphical frontend fedora-14-x64 sudo yum install tor vidalia Let's now configure our torvm to properly start Tor proxying at boot dom0 qvm-run -a torvm gnome-terminal Now, we will create the following script for starting up the Tor transparent proxy and setting up traffic redirection using iptables torvm vim rw config start_Tor_proxysh and now paste the following into this file bin shkillall torQUBES_IP xenstore-read qubes_ip TOR_TRANS_PORT 9040 if X QUBES_IP X thenecho Error getting QUBES IP echo Not starting Tor, but setting the traffic redirection anyway to prevent leaks QUBES_IP 127001 else usr bin tor --SocksPort 0 --TransListenAddress QUBES_IP --TransPort TOR_TRANS_PORT --DNSListenAddress QUBES_IP --DNSPort 53 --RunAsDaemon 1 --ControlPort 9051 echo Error starting Tor fi echo 0 proc sys net ipv4 ip_forward sbin iptables -t nat -F sbin iptables -t nat -A PREROUTING -i vif -p udp --dport 53 -j DNAT --to-destination QUBES_IP 53 sbin iptables -t nat -A PREROUTING -i vif -p tcp -j DNAT --to-destination QUBES_IP TOR_TRANS_PORT sbin iptables -I INPUT 1 -i vif -p udp --dport 53 -j ACCEPT sbin iptables -I INPUT 2 -i vif -p tcp --dport 9040 -j ACCEPT sbin iptables -F FORWARDecho 1 proc sys net ipv4 ip_forward Except for the QUBES_IP xenstore-read qubes_ip line that reads the torvm's IP address, there is nothing Qubes-specific in the above listing It's just a standard way of setting up transparent Tor proxy It is important that this file be located in the rw directory, as this directory is backed by the VM's private storage and will survive VM reboots The VM's root file-system is read-only and all the changes to it are lost on VM shutdown VM gets an illusion of the root fs being writeable thanks to Copy-On-Write mechanism, but the actual COW backing device is cleared upon each VM shutdown We should also modify the rw config rclocal script, to ensure that our Tor proxy is automatically started -- just paste the following into this script bin sh Uncomment this if you would like to use a custom torrc file rm -f rw config log ln -sf rw config torrc etc Tor torrc chkconfig qubes_netwatcher offchkconfig qubes_firewall off rw config start_Tor_proxy Finally we should also provide a script that would restart our proxy in case the user dynamically switched the NetVM, which would result in the completely different routing This could be done by creating a script with predefined name qubes_ip_change_hook within rw config directory bin sh rw config start_Tor_proxy And that's all Now, shutdown the torvm dom0 qvm-run --shutdown --wait torvm From now on, every time you start the torvm or when Qubes starts it in response to start of some other VM that uses torvm as its Net VM , the Tor transparent proxy should be automatically started Let's test this by creating a VM that would be using the just created Tor proxy dom0 qvm-create anon-web --label black dom0 qvm-prefs -s anon-web netvm torvm Now, every time you start the anon-web VM eg by clicking on the Web browser icon in the anon-web's start menu , Qubes will also ensure that torvm is up and running, and this in turn would configure all the Tor proxying for this VM Fo additional control one might want to use Vidalia, the graphical front end for Tor this should be installed within the template VM that has been used for torvm We could easily start Vidalia by just typing dom0 qvm-run -a torvm vidalia We should however make sure to disable Start the Tor software when vidalia starts option in Settings General in Vidalia Otherwise, Vidalia might kill your original Tor that has transparent proxy open and start own without transparent proxy enabled IMAGE The web browser runs in the 'anon-web' VM that uses 'torvm' for networking access, and thus all the traffic generated by 'anon-web' is routed through the Tor network, or discarded if it's a different traffic than TCP or DNS Of course one case easily create more VMs that would be using torvm as their Net VM, and so would have anonymized network access The beauty of this solution is that in case one of my anonymized VM gets compromised, others do not Plus, the already mentioned benefit, that no matter whether apps in those VMs are buggy, or even intentionally malicious, they would not be able to leak out the user's external IP address Creating a WiFi pen-testing VM Finally let's have some fun and create a WiFi pen-testing VM The desired config is depicted below IMAGE Because we would like to use all sorts of l33t h4x0r t00lz pen-testing security software in this VM, it would make sense to create it as a Standalone VM, which means that it would get its own copy of the whole file-system as opposed to just the home directory, rw and usr local, as it is the case with regular Qubes VMs This would ease the installation of all the extra software we would need there, and also ensure that even if the install build scripts were malicious, the damages would be contained only to this very VM and nothing else Also, for some reason the standard Linux WiFi stack and drivers still don't support injection on all most of the WiFi cards out of the box, so we would need to patch the actual kernel drivers -- yet another reason to use a Standalone VM in this case So, let's create the VM first, and assign a WiFi card to it dom0 qvm-create wififun --standalone --label yellow dom0 qvm-prefs -s wififun memory 800 ensure at least this mem at startup dom0 qvm-prefs -s wififun kernel none use own copy of kernel and modules dom0 qvm-pci -a wififun You can easily find the BDF address of any device using the lspci command in Dom0 -- this would be something like eg 02 000 You should make sure that this WiFi card is not used by any other VM, specifically by your default Net VM called 'netvm' in a standard Qubes installation Ideally you could just use a dedicated Express Card-based WiFi card, leaving the built in WiFi assigned to your default Net VM Because it's a Standalone VM, Qubes will make a copy of the whole root filesystem, and thus it would eat about 5GB of your disk normal VMs would take only as much space as their private fs takes up Let's now start the VM dom0 qvm-run -a wififun gnome-terminal and then install the prerequisite software there, starting with downloading the reasonably new compat-wireless sources, together with the required injection patches, and then building and installing the new kernel modules All actions below are now executed within the VM This stuff here is really nothing Qubes- or Xen-specific -- one would do more or less the same on any Linux in order to get injection working wififun wget http linuxwirelessorg download compat-wireless-26 compat-wireless-2011-07-14tarbz2 wififun wget http patchesaircrack-ngorg channel-negative-one-maximpatch wififun wget http patchesaircrack-ngorg mac80211-2629-fix-tx-ctl-no-ack-retry-countpatch wififun wget http patchesaircrack-ngorg mac80211compat08082009wl_frag ack_v1patch wififun sudo yum install kernel-devel patch gcc wififun tar xjf compat-wireless-2011-07-14tarbz2 wififun cd compat-wireless-2011-07-14 wififun patch -p1 proc sys net ipv4 ip_forward Note that you don't need to add any explicit masquerading rules, as they are applied by default on Qubes VMs you can take a look at the nat table in the VM if you want to see by yourself Edit the etc dnsmasqconf, so that it contains at least the following interface at0dhcp-range 192168050,1921680150,12h and then start the dnsmasq daemon -- we will use it for providing DHCP to our fake AP the at0 interface will be created by airbase-ng and emulates the uplink of a traditional AP wififun etc initd dnsmasq start And finally the fake AP wififun airbase-ng -e free_wifi mon0 and on another console before any client connects, but after airbase-ng got started , configure the at0 interface make sure it matches what you wrote into dnsmasqconf wififun ifconfig at0 19216801 up you can also add an udev rule to that automatically and just to verify it really is working wififun tcpdump -i at0 and now, just wait for a client to connect to your AP What you do next is only limited by your imagination But hey, this article is about Qubes networking and not about 0wning client systems Here's an innocent example using Moxie's sslstrip amazing this attack still works so well at the end of 2011 IMAGE My 'wififun' VM in action using a simple sslstrip attack, that surprisingly still works pretty nice Please note that as your wififun VM is a regular Qubes VM, it is automatically connected to the default Net VM, which in turn provides networking to it That's why it is so easy to create a fully functioning fake AP When using custom driver domains, there are currently some catches you should be aware Catch 1 When you start a driver domain late after system boot, so after some days of uptime and extensive use of VMs, Xen might not be able to allocate enough continues in terms of MFNs memory for a driver domain And PV driver domains, unlike normal domains or HVM driver domains, do require MFN-continuous memory for their DMA buffers HVM domains do not need that, because IOMMU can create an illusion of this even though IOMMU is also used for PV driver domains, for protection, it doesn't actively translate bus addresses into GMFNs This is usually not a big problem in practice, because in most cases all the driver domains are started early at system boot, when there is still plenty of non-fragmented memory available However it might become a problem when one wishes to start eg the WiFi pen-testing at some later time The work around is to close as many VMs as possible before starting such driver domain, and then also reducing, for a moment, the amount of memory assigned to Dom0 dom0 xm mem-set 0 1600m and then starting the driver domain should be fine Now we can start all other domains, and that should no longer be problematic for the already running driver domain Catch 2 Some network cards, notably Express Cards, might not work well with the 304 pvops kernel that we use in all VMs by default In that case you might want to try to use the 26383 xenlinux kernel in your WiFi fun VM -- to do that, follow these steps dom0 sudo qvm-dom0-update kernel-qubes-vm-26383-10xenlinuxqubes dom0 cp var lib qubes vm-kernels 26383 var lib qubes appvms wififun kernels dom0 qvm-prefs wififun -s kernelopts swiotlb force And then, in the VM wififun sudo yum install kernel-devel-26383-10xenlinuxqubes And rebuild the compat-wireless, unload, install modules, and then load drivers again Summary As you can see, Qubes Beta 2 now offers a very advanced networking infrastructure that allows more advanced users to create very sophisticated configurations, allowing for pretty good isolation between various domains and networks Qubes leaves it up to the user or admin to figure out what would be the best configuration -- most users would be happy with the default simple setup with just one Net VM and one Firewall VM, while others would go for much more advanced setups IMAGE A bit more advanced networking setup The usbvm has a 3G modem assigned, and it is possible to dynamically switch between the Net VMs without restarting any other VMs http://www.secuobs.com/revue/news/331530.shtmlhttp://www.secuobs.com/revue/news/331530.shtml Secuobs.com : 2011-09-19 13:12:52 - The Invisible Things Lab's blog - I'm proud to announce that we have just released Qubes Beta 2 You can view installation instructions and download the ISO here We faced quite a few serious problems with this release that were caused by an upgrade to Xen 41 from Xen 34 that we used in Beta 1 But finally we managed to solve all those problems and all in all I'm very happy with this release It includes many performance optimizations compared to Beta 1 CPU- and memory-wise and also many bugfixes We also introduced a couple of new features Generic mechanism for inter-domain services with a centralized policy enforcement more Network-less update mechanism for Dom0 more VM management improvements easy device assignment for driver domains, dynamic netvm switching, flexible VM kernel configuration, etc see the new qvm-prefs utility Easy management of appmenus shortcuts in the Start Menu Update to Xen 41 that offers, among other things, better VT-d support and more lightweight management stack we have ported Qubes to use the new xl now, instead of the slow and heavy xend , and also to 2638-xenlinux kernel for Dom0, and to 304 pvops kernel for VMs better hardware compatibility, better power management I will write some more posts shortly that would present in detail some of the new features and what cool things one could do with them We have also created a dedicated wiki page that enumerates all the security-critical code for Qubes OS We hope this page would be useful for security researchers that might attempt to find weaknesses in Qubes OS either in our code or in the 3rd party code that we rely on Xen hypervisor, select Xen backends Whether your motives are noble gaining immortal fame, helping create a secure client OS , or not proving ITL wrong , we would appreciate your efforts And you might even get a job at ITL Speaking of which, I'm happy to announce that Marek Marczykowski, who has effectively become the key Qubes developer over the past few months, has now officially joined ITL http://www.secuobs.com/revue/news/329639.shtmlhttp://www.secuobs.com/revue/news/329639.shtml Secuobs.com : 2011-09-08 00:23:01 - The Invisible Things Lab's blog - Anti Evil Maid is an implementation of a TPM-based static trusted boot with a primary goal to prevent Evil Maid attacks The adjective trusted, in trusted boot, means that the goal of the mechanism is to somehow attest to a user that only desired trusted components have been loaded and executed during the system boot It's a common mistake to confuse it with what is sometimes called secure boot, whose purpure is to prevent any unauthorized component from executing Secure boot is problematic to implement in practice, because there must be a way to tell which components are authorized for execution This might be done using digital signatures and some kind of CA infrastructure, but this gets us into problems such as who should run the CA, what should be the policy for issuing certificates, etc The adjective static means that the whole chain of trust is anchored in a special code that executes before all other code on the platform, and which is kept in a non re-flashable memory, whose sole purpure is to make the initial measurement of the next component that is going to be executed, which is the BIOS code This special code, also known as Core Root of Trust for Measurement CRTM , might be part of the BIOS but kept on a special read-only memory, or implemented by some other entity that executes before the BIOS reset vector, such as eg Intel ME or the processor microcode even Once measured, the BIOS code is executed, and it is now its turn to measures the platform configuration, Option ROM code, and MBR Then the loader stored in the MBR , such as Trusted GRUB, takes over and measures its own next stages other than the MBR sector , and the hypervisor, kernel, and initramfs images that are to be loaded, together with their configuration eg kernel arguments As explained above, trusted boot can only retrospectively tell the user whether correct trusted software has booted or not, but cannot prevent any software from executing But how can it communicate anything reliably to the user, if it might have just been compromised This is possible thanks to the TPM unseal operation that releases secrets to software only if correct software has booted as indicated by correct hashes in select PCR registers So the idea is that if a user can see correct secret message or perhaps a photo being displayed on the screen, then it means that correct software must have booted, or otherwise the TPM would not release unseal the secret Of course we assume the adversary had no other way to sniff this secret and couldn't simply hardcode it into the Evil Maid more on this later Another way to look at it is to realize that Anti Evil Maid is all about authenticating machine to the user, as opposed to the usual case of authenticating the user to the machine OS login and password, decryption key, token, etc We proceed with booting the machine and entering sensitive information, only after we get confidence it is still our trusted machine and not some compromised one Installing Anti Evil Maid Anti Evil Maid should work for any Linux system that uses dracut initramfs, which includes Qubes, Fedora and probably many other distros You can find the Anti Evil Maid source code in a git repository here You can also download a tarball with sources and prebuilt rpm packages from here they all should be signed with the Qubes signing key Qubes Beta 2, that is coming soon, will have those RPMs already per-installed To install Anti Evil Maid, follow the instructions in the README file Some Practical considerations If you decided to use no password for your TPM SRK key so, you passed '-z' to tpm_takeownership, see the README , then you should definitely install Anti Evil Maid on a removable USB stick Otherwise, if you installed it on your disk boot partition, the attacker would be able to just boot your computer and note down the secret passphrase that will be displayed on the screen Then the attacker can compromise your BIOS MBR kernel images however she likes, and just hardcode the secret passphrase to make it look like if your system was fine If you decided to use custom TPM SRK password so, you did not pass -z to tpm_takeownership , then you can install Anti Evil Maid onto your regular boot partition The attacker would not be able to see your secret passphrase without knowing the SRK password Now, the attacker can try another Evil Maid attack to steal this password, but this attack is easy to spot and prevent see the discussion in the next section However, there is still a good argument to install Anti Evil Maid on a separate USB stick rather than on your built-in disk boot partition This is because you can use Anti Evil Maid as a provider of a keyfile to your LUKS disk encryption as an additional file unsealable by the TPM This way you could also stop adversary that is able to sniff your keystrokes eg using hidden camera, or electromagnetic leak , and capture your disk decryption passphrase see the discussion in the next section In any case it probably would be a good idea to make a backup stick that you might want to use in case you lose or somehow damage your primary stick In that case you should have a way to figure out if your system has been compromised in the meantime or not Use another stick, with another passphrase, and keep it in a vault for this occasion Finally, be aware that, depending on which PCRs you decided to seal your secrets to, you might be unable to see the secret even after you changed some minor thing in your BIOS config, such as eg the order of boot devices Every time you change something in your system that affects the boot process, you would need to reseal your secrets to new PCR values as described in the installation instructions Attacks prevented by Anti Evil Maid The classic Evil Maid attack is fully prevented If the attacker is able to steal your Anti Evil Maid stick, and the attacker gets access to your computer, then the attacker would be able to learn your secret passphrase by just booting from the stolen stick This is not fatal, because user should get alarmed seeing that the stick has been stolen, and use the backup stick to verify the system with a different secret messages, of course , and later create a new stick for every day use with a new secret message A variation of the above attack is when the attacker silently copies the content of the stick, so that the user cannot realize that someone got access to the stick Attacker then uses the copied stick to boot the user's computer and this way can learn the secret passphrase Now, the attacker can infect the computer with Evil Maid, and can also bypass Anti Evil Maid verification by just hardcoding the secret message into Evil Maid So, even though TPM would know that incorrect software has booted, and even though it would not unseal the secret, the user would have no way of knowing this as the secret would still be displayed on screen In order to protect against this attack, one might want to use a non-default SRK password see the installation instructions Now an extra SRK password would be needed to unseal any secret from the TPM in addition to PCRs being correct So the attacker, who doesn't know the SRK password, is now not able to see the secret message and cannot prepare the Evil Maid Attack doesn't know what secret passphrase to hardcode there The attacker might want to perform an additional Evil Maid attack targeted at capturing this SRK password, eg by infecting the user's stick This, however, could be immediately detected by the user, because the user would see that after entering the correct SRK password, there was no correct secret passphrase displayed The user should then assume the stick got compromised together with the SRK password, and should start the machine from the backup stick, verify that the backup secret is correct, and then create new AEM stick for daily usage If an attacker is able to capture the user's keystrokes hidden camera, electromagnetic leaks , the attacker doesn't need Evil Maid attack anymore, and so doesn't need to bother with compromising the system boot anymore This is because the attacker can just sniff the disk decryption password, and then steal the laptop and will get full access to all user data In order to prevent such a keystroke sniffing attack, one can use an additional sealed secret on the Anti Evil Maid stick that would be used as a keyfile for LUKS in addition to passphrase In this case the knowledge of the sniffed LUKS passphrase would not be enough for the attacker to decrypt the disk This has not been implemented, although would be a simple modification to dracut-antievilmaid module If you decided to use this approach, don't forget to also create a backup passphrase that doesn't need a keyfile, so that you don't lock yourself from access to your data in case you lose your stick, or upgrade your BIOS, or something You have been warned, anyway Attacks that are still possible An adversary that is able to both sniff your keystrokes hidden camera, electromagnetic leak and is also able to copy steal seize your Anti Evil Maid stick, can not be stopped If a non-democratic government is your adversary, perhaps because you're a freedom fighter in one of those dark countries, then you likely cannot ignore this type of attacks The only thing you can do, I think, is to use some kind of easy-to-destroy USB stick for keeping Anti Evil Maid A digestible USB stick, anyone Another type of attack that is not addressed by Anti Evil Maid is an attack that works by removing the gears from your laptop the motherboard and disk at the very least , putting there a fake board with a transmitter that connects back to the attacker's system via some radio link and proxies all the keyboard screen events and USB ports back to the original gears that execute now under supervision of the attacker Another way of thinking about this attack is as if we took the motherboard and disk away, but kept all the cables connecting them with the laptop's keyboard, screen, and other ports, such as USB yes, very long cables The attacker then waits until the user boots the machine, passes the machine-to-user authentications however sophisticated it was , and finally enters the disk decryption key In practice I wouldn't worry that much about such an attack, but just mentioning it here for completeness Finally, if our adversary is able to extract secret keys from the TPM somehow, eg using electron microscope, or via some secret backdoor in the TPM, or alternatively is able to install some hardware device on the motherboard that would be performing TPM reset without resetting the platform, then such an attacker would be able to install Evil Maid program and avoid its detection by SRTM Still, this doesn't automatically give access to the user data, as the attacker would need to obtain the decryption key first eg using Evil Maid attack Implementation Specific Attacks In the discussion above we assumed that the trusted boot has been correctly implemented This might not be true, especially in case of the BIOS In that case we would be talking about attacks against a particular implementation of your BIOS or TrustedGRUB , and not against Anti Evil Maid approach One typical problem might be related to how CRTM is implemented if it is kept in a regular BIOS reflashable memory, than the attacker who can find a way to reflash the BIOS which might be trivial in case your BIOS doesn't check digital signatures on updates would be able to install Evil Maid in the BIOS but pretend that all hashes are correct, because the attacker controls the root of trust Another possible implementation problem might be similar to the attack we used some years ago to reflash a secure Intel BIOS that verified digital signatures on updates by presenting a malformed input to the BIOS that caused a buffer overflow and allowed to execute arbitrary code within the BIOS For such an attack to work, however, the BIOS should not measure the input that is used as an attack vector I think this was the situation with the logo picture that was used in our attack Otherwise, even if there was a buffer overflow, the chain of trust would be broken and thus the attack detected In other words, the possibility of such an attack seems to be rather slim in practice What about Intel TXT Intel TXT takes an alternative approach to trusted boot It relies on a Dynamic instead of Static Root of Trust for Measurement DRTM vs SRTM , which is implemented by the SENTER instruction and special dynamic PCR registers that can be set to zero only by SENTER Intel TXT doesn't rely anymore on the BIOS or CRTM This offers a huge advantage that one doesn't need to trust the BIOS, nor the boot loader, and yet can still perform a trusted boot Amazing, huh Unfortunately, this amazing property doesn't hold in practice As we have demonstrated almost 3 years ago , it is not really true that Intel TXT can remove the BIOS away from the chain of trust This is because Intel TXT is prone to attacks through a compromised SMM, and anybody who managed to compromise the BIOS would be trivially able to also compromise the SMM because it is the BIOS that is supposed to provide the SMI handler Thus, if one compares SRTM with Intel TXT, then the conclusion is that Intel TXT cannot be more secure than SRTM This is because if an attacker can compromise the BIOS, then the attacker can also bypass Intel TXT via a SMM attack On the other hand, a BIOS compromise alone doesn't automatically allow to bypass SRTM, as it has been discussed in a paragraph above It really is a pity, because otherwise Intel TXT would be just a great technology Shame on you Intel, really Alternative approaches to mitigate Evil Maid Attacks Various people suggested other methods to prevent Evil Maid attacks, so lets quickly recap and discuss some of them The most straight forward approach suggested by most people, has been to disable booting from external devices in BIOS, together with locking the BIOS setup with an admin password There are two problems with such an approach First, all the BIOSes have a long history of so called default passwords AKA maintenance passwords You don't want to rely on the lack of BIOS default passwords when protecting your sensitive data, do you Second, even if your BIOS doesn't have a backdoor maintenance password , it is still possible to just take your disk away and connect to another laptop and infect its boot partition Another suggested approach has been to keep your boot partition on a separate USB stick This solution obviously doesn't take into account the fact that the attacker might install Evil Maid into your BIOS Many consumer laptop BIOSes do not require digital signatures on BIOS firmware updates my Sony Vaio Z, a rather high-end machine, is among them , making it simple to install Evil Maid there the most trivial attack is to make the BIOS always boot from the HDD instead of whatever other device the user wanted to boot from Finally, some people pointed out that many modern laptops comes with SATA controllers that offer ability to lock the disk so that it could only be used with a specific SATA controller Using this, combined with setting your BIOS to only boot from your internal disk, plus locking access to BIOS setup, should provide reasonable protection This solution, of course, doesn't solve the problem of a potential maintenance password in your BIOS Also being skeptical and paranoid as I am, I would not trust this mechanism to be really robust I would expect it would be fairly simple to unlock the disk so that it could be paired with another, unauthorized controller, and that this probably is a matter of NOP-ing a few instructions in the controller firmware In fact it seems like you can buy software to unlock this mechanism for some 50 And apparently and not very surprisingly some drives seems to continue on the 'default passwords' tradition FAQ Q Bitlocker implemented this already several years ago, right A No Q But, two-factor authentication can also be used to prevent Evil Maid, right A No Q Does it make any sense to use Anti Evil Maid without a full disk encryption A No Q Are you going to answer 'no' for each question I ask A No Q Why there are no negative indicators eg a big scary warning when the unseal process fails A The lack of negative indicators is intentional The user should keep in mind that if somebody compromised their computer, then the attacker would be able to display whatever she wants on the screen, and especially to skip displaying of any warning messages The only thing the attacker would not be able to display would be the secret message Thus, it would make no sense to use negative indicators, as they would likely not work in case of a real attack One solution here would be to use the unsealed secret as a keyfile for disk encryption as discussed above , which would make it impossible to decrypt the user disk and so generally proceed with the boot without successfully unsealing the secret from the TPM http://www.secuobs.com/revue/news/327608.shtmlhttp://www.secuobs.com/revue/news/327608.shtml Secuobs.com : 2011-08-30 23:48:32 - The Invisible Things Lab's blog - Here is a recent interview with me for Tom's Hardware, where I talk about Qubes, why virtualization alone does not automatically bring much security, and why we need it for secure systems anyway, and all that kind of stuff Nothing really new, but still might be of interest to some readers As for Qubes Beta 2 release -- it really is coming, but we've faced recently some very nasty, race-condition-related problems with new Xen we bravely switched to Xen 41 in Beta 2 that seem to occur on machines with very fast SSDs and we're currently trying to see if we can solve them, or should we instead revert back to Xen 34 that we used previously in Beta 1 Except for that, Beta 2 is mostly ready, so we should be releasing it within coming weeks http://www.secuobs.com/revue/news/326157.shtmlhttp://www.secuobs.com/revue/news/326157.shtml Secuobs.com : 2011-06-10 15:44:33 - The Invisible Things Lab's blog - A few days ago I had a privilege to give an opening keynote at the SSTIC conference in Rennes, France, which is believed by many to be the most important security conference in France You can find my slides here SSTIC seems to be a very interesting conference indeed, with a strong emphasis on system-level security, which is quite unusual these days where most conferences focuses on networking, apps, and web-apps What a pity all those interestingly-looking talks have been encoded in an obscure language used only by some 3pourcents of the population of the planet Anyway, it was a pleasure to talk to some ANSSI people I met before the conference one of the organizers of the event who really seemed to understand well the challenges we face with building secure operating systems, and generally seemed well versed in the topic Perhaps some other nations should learn from France, instead of proposing ridiculous and superficial means that can't really solve any real problem http://www.secuobs.com/revue/news/310428.shtmlhttp://www.secuobs.com/revue/news/310428.shtml Secuobs.com : 2011-06-03 17:22:00 - The Invisible Things Lab's blog - Remember our Xen 0wning Trilogy at Black Hat in summer 2008, specifically the presentation on Detecting Preventing the Xen Hypervisor Subversions One of the things we were discussing there was a proposal to include an additional restriction to Intel processors that would disallow execution of usermode pages from within supervisor mode ring0 Such a feature, we argued, apart from obviously making many ring3-to-ring0 exploits much harder, including the very Xen heap overflow exploit we presented in the slides, would also bring us closer to efficient runtime code integrity checkers for kernels and hypervisors, as discussed in the slides IMAGE Slide 97, Detecting and Preventing Xen Hypervisor Subversions, Black Hat USA, July, 2008 Fast forward 3 years On June 1st, 2011, an Intel engineer is submitting a patch for Xen to support a mysterious new processor feature called SMEP Supervisor Mode Execution Protection He writes the feature is not yet documented in SDM, but soon will be In fact, the May 2011 update of Intel SDM already contains the details IMAGE Intel SDM, vol 3a, May 2011, source intelcom Some other people spotted this feature earlier, because of another patch submitted by another Intel engineer to Linux kernel a few weeks ago Here's a good write up by Dan Rosenberg discussing how this patch makes writing Linux kernel exploits harder, and how it's still possible to write them The SMEP feature still doesn't seem to be present in the processors available on the market, including the latest Sand Bridge processors, but there's no question it's coming, now that the feature made it into SDM It is quite rewarding to see your idea implemented in a processor I guess this is how physicists feel when they introduce a new particle as part of a new quantum model, and later discover evidences to support the existence of this very particle in the wild http://www.secuobs.com/revue/news/309018.shtmlhttp://www.secuobs.com/revue/news/309018.shtml Secuobs.com : 2011-06-01 01:28:48 - The Invisible Things Lab's blog - When we think about USB Security there are lots of things that come to mind First there are all the physical attacks that could be conducted with the help of USB devices These are generally not so interesting, because if one includes physical attacks in the threat model, then it really opens up lots of possibilities of various attacks, and generally a physical attacker always wins Still, there are a few very cheap and easy physical attacks that one would like to avoid, or make harder, such as the Evil Maid Attacks or the Cold Boot Attacks Strictly speaking these are not problems inherent to USB itself, but rather with lack of Trusted Boot, or OS not cleaning properly secrets from memory upon shutdown They are just made simple thanks to bootable USB sticks Much more interesting USB-related physical attacks are those that take advantage of the specifics of the USB standard One example here would be a malicious USB device that exposes intentionally malformed info about itself in order to exploit a potential flaw in a USB Host Controller driver that processes this info upon each new USB device connect Or a malicious USB device that would trick the OS Windows at least into downloading a known buggy USB driver or even an intentionally malicious driver, legally submitted to WHQL by the attacker and then exploit the driver Another class of physical attacks made possible by the USB specification are malicious USB devices that pretend to be a keyboard or mouse The input devices, such as keyboard, are actually the most security sensitive devices, because an attacker who controls the keyboard can do everything the user can do, which basically means can do everything, at least with regards to the user's data Finally, the USB, as the names stands, is a bus interconnect, which means all the USB devices sharing the same USB controller are capable of sniffing and spoofing signals on the bus This is one of the key differences between USB and PCI Express standards, where the latter uses a peer-to-peer interconnect architecture Ok, so these all above were physical attacks Let's now look at, much more fatal, software attacks The infamous class of attacks exploiting various autorun or auto-preview behaviors is the most known example, but also the easiest, at least in theory, to protect against Much more interesting are software attacks that attempt to exploit potential flaws in the USB stacks similarly like the physical attacks mentioned above, just that this time not requiring any hardware-level modifications to the USB device Exposing a malformed partition table is a great example of such an attack Even if we have all the autorun mechanisms disabled, still, when we're inserting a storage medium the OS always attempts to parse the partition table in order to eg create devices symbolizing each partition volume eg dev sdbX devices Now, this is really a problematic attack, because the malformed partition table can be written onto a fully legitimate USB stick by malware Imagine eg you have two physically separated machines air-gapped , belonging to two different security domains, and you want to transfer files from one to another You insert the USB stick into the first machine, copy files, and then insert the stick to the second machine If the first machine was compromised, it could have altered the partition table on the USB stick, and now when this stick is inserted into the other machine its malformed partition table might exploit a buffer overflow in the code used by the second OS to parse the stick's partition information Air-gapped systems, huh We avoid this attack vector in Qubes by using a special inter-domain file copy mechanism that doesn't require any metadata parsing A variation of the above attack would be to expose a malicious file system metadata, but this time the target OS would have to actually mount the partition for the attack to work and, of course, there would have to be bugs in the OS file system parsing code, although these seem to be quite common on most OSes Having quickly summarized the USB security-related threats, let's now think about how we could design an OS to mitigate most of those attacks, and at the very least the software-based attacks This is, in fact, precisely the challenge we've been facing in Qubes, so the divagations below necessarily focus mostly on the Qubes architecture First we should realize that USB devices, unlike PCI Express devices, cannot be independently delegated to different domains VMs This is because IOMMU technologies, such as Intel VT-d, operate only on PCIe device granularity This means we can only delegate a whole USB controller to a domain, including all of the USB devices connected to this controller hub Imagine now two internal devices, both connected via internal USB bus a keyboard, and a 3G wireless modem Chances are high that you will have those two devices connected to the same USB controller usually one controller is used for all the internal devices, like those I just mentioned, plus camera, fingerprint reader, etc, and the other controller is used for all the externally visible USB connectors at least this is true for modern systems Intel Series 5 chipsets and newer We would like to be able to delegate the 3G modem to the NetVM an untrusted domain on Qubes where all the networking drivers and stacks are kept it's considered untrusted because its compromise is equivalent to a compromise of a WiFi network or home router, or some other router, and any reasonable person always assumes that the network is compromised, and deals with that using crypto, such as SSL or SSH But assigning the USB controller, to which the 3G modem is connected to, to the NetVM, would also assign the USB keyboard to the NetVM And this is precisely what we don't want to do, because control over the keyboard is equivalent to the control over the whole system Currently, in Qubes Beta 1, we keep all the USB controllers assigned to Dom0 This, however, causes two annoyances First, the user cannot use any of the USB-connected networking devices, such as 3G modems because there is no networking in Dom0 Second, if somebody connects a USB disk and later delegates it to some domain this could easily be done via block-attach mechanism, supported by the same backend that handles storage virtualization for domains , and this domain turns out to be compromised, it might alter eg the stick's partition table and later attack Dom0 as explained above We can eliminate the second problem by modifying the Dom0's kernel to not parse the partition table of any removable devices automatically, and instead expect some kind of explicit consent from user to actually do that we still must allow to mount USB disks in Dom0 to allow easy backups of all domains at once To allow the use of USB-connected networking devices in NetVM, we could use a PVUSB backend that can virtualize single USB devices without moving the whole USB controller to the domain But that would require introducing a whole lot of new code to Dom0 code that would be directly reachable from VMs in other words that would be processing lots of untrusted input coming from untrusted domains So another option is to delegate all the non-security-critical USB controllers, ie those controllers that don't have any security-sensitive USB devices connected, such as keyboard, to a dedicated USB domain, and later share the USB devices via PVUSB backend from this USB domain This time, the extra PVUSB backend runs in the USB domain, not in Dom0, so we don't worry that much about potential bugs in this backend Of course, this way you cannot delegate the USB controller to which the keyboard, and potentially also other security-critical devices, such as camera, are connected to, which in practice rules out the integrated3G modem Fortunately many modern laptops do not use USB-connected keyboard and touchpad they use PS 2-connected keyboards instead , and the face camera can be easily disabled with a piece of sticker although that sucks, because it means we cannot really use the camera With this approach a dedicated USB domain you can now delegate your 3G modem to the NetVM, and other USB devices, such as removable disks to other domains, eg for file exchange This seems the most reasonable setup, although it requires that either 1 your laptop doesn't have USB-connected keyboard, or 2 you don't use internal USB devices connected to the same controller that your USB keyboard touchpad from other domains than Dom0 in practice no 3G modem in NetVM As we can see proper handling of USB devices is quite a challenge for OS architects It might have been much less of a challenge if the engineers designing the USB, chipsets, and motherboards were a bit more security-conscious Even such simple practice as never mixing security critical devices keyboard, touchpad, camera, fingerprint reader , with non-security ones 3G modem , onto the same USB controller, would help tremendously Or ability to somehow dynamically configure their connectivity, eg in BIOS http://www.secuobs.com/revue/news/308347.shtmlhttp://www.secuobs.com/revue/news/308347.shtml Secuobs.com : 2011-05-28 15:17:14 - The Invisible Things Lab's blog - Everybody loves The Cloud these days, and it is not hard to understand why When every person owns computers devices , the cloud is really hard to beat when it comes to syncing all your digital life back and forth between all those devices, and also sharing with your family members, friends, and colleagues at work From task lists, through calendars, through health fitness data, to work-related documents And I'm not even mentioning all the unencrypted email that is out there One doesn't need to be especially smart or security conscious to realize how much this might be a threat to security and privacy How much easier would it be to attack somebody's laptop if I knew precisely in which hotel and when he or she is planning to stay How much more expensive would my health and life insurance be, if they could get a look at my health and fitness progress Etc But we're willing to sacrifice our privacy and security in exchange for easy of syncing and sharing of our data We decide to trust The Cloud What specifically does that mean First, it means we trust the particular cloud-based service vendor, such as the provides of our training monitoring app and service We trust that this vendor is 1 non-malicious and ethical, and so is not going to sell our private data to some other entity, eg insurance company, and 2 that the software written by this vendor is somehow secure, so it would not be easy for an attacker to break into their cloud service and download all the user's data and then sell to health insurance companies Next, we trust the cloud infrastructure provider, such as Amazon EC2 We trust that the cloud provider is 1 non-malicious and ethical, and that they won't really read the memory of the virtual machine on which the previously mentioned cloud-service is running and won't make it available to a local government officials, eg in China , and 2 that they secured their infrastructure properly eg it wouldn't be easy for one customer to escape from a VM and read all the memory of the VMs belonging to other customers Finally we trust all the infrastructure that is in the middle between us and the service provider, such as eg the networking protocols, are safe to use eg we trust all the engineers working in any of the ISP we use won't sniff spoof our communication, eg by using some fake or quasi-fake SSL certs So, that's a hell of trusting And the stake is high Do we really need to make such a sacrifice Do we really need to hand in all our private data to all those organizations Of course we don't First, notice that in majority of cases, the cloud is only used basically as a on-line storage No processing, just dump storage Indeed, what kind of server-side processing does your task list or calender require Or your freestyle swimming results Or your conference slides None And we know for very long how to safely keep secrets on untrusted storage, don't we This is achieved via encryption and digital signatures for integrity authenticity So, the idea is very simple let's encrypt all the data before we send them to the cloud The point here is, the encryption must be done be the app that is running on our client device Not in the cloud, of course Ok, so let's say I have my calendar records encrypted in the cloud, how do I share it with my other devices and other people, such as my partner and colleagues at work Very simple you encrypt each record with a random symmetric key and then, for every other device or person who you want to grant access to your calendar you make the symmetric key available to this person, by encrypting it with their public key if you're paranoid, you can even verify fingerprints using some out-band communication channel, such as phone, to ensure the cloud service provider didn't do MITM attack on you What if you want to share only some events or some details with some group of people eg only your availability info Very simple just encrypt those records you want to share in non-full access with some other symmetric key and publish only this key to those people devices you want to grant such non-full access Implementing the above would require writing new end-user apps, or plugins for existing apps such as Outlook , so that they do encryption decryption signing verification before sending the data out to the cloud But what stops the malicious vendor from offering apps that would be leaking out our secrets, eg the keys Well, nothing actually But this time, the vendor would need to explicitly build in some kind of backdoor into the app The same could be done with any other vendor, and any other, non-cloud-based app After all, how do we know that MS Word, which is not cloud-based yet, is not sending out fragments of our texts to Agent Smith Note how different this is from a situation when the vendor already owns all our data, unencrypted, brought legitimately to their servers, and all they need to do is to read them from their own disks No need to plant and distribute any backdoors In practice few vendors would be risking their reputation and would be willing to build in a backdoor into an app that is then made available to customers Because every backdoor in such client-exposed code will sooner or later be found You would really not believe what great lengths all those young people aimed with disassembler and debugger would go to, to win an economy class ticket to the middle of desert in the hottest summer season, just to be able to deliver a presentation on how evil stupid a company X is One problem is, however, with accessing our encrypted cloud over a Web Browser In contrast to apps, the web browser content is much less identifiable An app can have a digital signature everybody know its an App v 11, published by X As explained above it would be rather stupid for X to plant a backdoor into such an app But a Web-delivered Javascript is much more tentative, and it's very possible for X to eg deliver various versions of scripts to different customers Digital signature on client-side scripts, paired with ability to whitelist allowed client-side-scripts, would likely solve this problem So, why we still haven't got client-side-encrypted cloud-services The question is rhetoric, of course Most vendors actually loves the idea of having unlimited access to their customers data Do you think Google would be happy to give up an opportunity to data mine all your data This might affect their ad business, health research, or just Secret Plan To 0wn The World After our dead body, I can almost hear them yelling After all they have just came up with Chrome OS to bring even more data into their data mining machine To sum it up, there is no technical reason we must entrust all those people with our most private data Sooner or later somebody will start selling client-side-encrypted cloud services, and I would be the first person to sign up for it Hopefully it will happen sooner than later to late This post also hopefully shows, again, one more aspect that we can, relatively easy, move most of the IT infrastructure out of the TCB Trusted Computing Base, used as metaphor here In other words, we can design our systems and services so that we don't need to trust a whole lot of things, including servers and the networking infrastructure except for its reliability, but not for its security But, there always remains one element that we must trust these are our client devices If they are compromised, the attacker can steal everything Strangely most people still don't get it, or get it backwards Just the fact that information is not stored on the iPad but kept safe on the corporate network , doesn't change anything Really If the attacker owns your iPad, then she also can do anything that the legitimate user could do from this iPad So if you could get to the company's secret trade data from your iPad's Receiver, so would be able to do the malware attacker http://www.secuobs.com/revue/news/307758.shtmlhttp://www.secuobs.com/revue/news/307758.shtml Secuobs.com : 2011-05-21 20:53:57 - The Invisible Things Lab's blog - Most of the desktop OSes today, such as Windows or Mac, expose and encourage a File-oriented UI model You pick a file in the file manager, click it, and then the file manager automagically determines the best app to handle the file, starts the app, and passes the file to it Back in the MS-DOS days we used a different model an app-oriented model you started an app first, eg Word Perfect, or Lotus 1-2-3, and then you opened a file from within the app Norton Commander and similar programs somehow changed that later Interestingly this very same app-oriented model is now becoming popular again thanks to systems such as iOS and Android There is no such thing as a global File Explorer or Finder on an iPad Only the apps One must first pick an app, and then it's the application's responsibility to expose an option for opening one of your files , if the app supports it eg the calendar or task list apps would always open your default calendar or task list without asking for anything I actually like this app-oriented model a lot It's much less confusing to the user Just think about all those attacks in the past where an attacker could prepare a file with some innocently-looking extension but which in fact was an MZ executable Or how many times people are not even aware which app they use One might argue that user should not be distracted by such unimportant things as what app he or she uses for her work, but I disagree Apparently Apple, and millions of iPhone and iPad users, disagree too But the main reason why I like this app-oriented model is because it just fits greatly into the Security by Isolation philosophy Just think about it if it's possible to get users to consciously select an app, and we now know it is possible thanks to the millions of app-oriented devices sold, then it should be not much more difficult to get them to also consciously select the domain or area, such as work , or personal , which they wish to use Just imagine that instead of one Mail app, you would have two apps and two icons Mail Work , and Mail Personal There are some technicalities here such as eg how to isolate apps between each other Do we need to build another layer of isolation in a form of VMs to isolate Mail Work from Mail Personal , or should the new OSes and the new APIs be designed in such a way, that they were thin and secure, and allow for very good isolation between processes without using virtualization In Qubes we must use this additional layer of abstraction virtualization , because we want to use Linux apps and in the future also Windows apps , and they require huge POSIX X API and Win32 API to work correctly And those APIs are not easily isolate-able So we use VMs as API providers Same with isolating networking drivers and stacks we need Linux kernel API to get those drivers and stacks running, so that's why we use a Linux-based NetVM for isolating networking For this reason we expect users to explicitly define domains, such as work , personal , etc This is because we cannot afford to run every single app in a separate AppVM more precisely we cannot afford to create a working copy of this huge POSIX X API for each app But we could very well imagine a well constructed API for apps that would just be easily isolate-able I'm not saying iOS or Android has such an API , and so there would be no need to define domains explicitly Still, we would need a possibility to define more than one instance of each app such as the previously mentioned Mail Work and Mail Personal The app-oriented model seems to be the future And so seems the Security by Isolation philosophy http://www.secuobs.com/revue/news/306368.shtmlhttp://www.secuobs.com/revue/news/306368.shtml Secuobs.com : 2011-05-13 19:16:46 - The Invisible Things Lab's blog - Today we publish a new paper which is a result of our several month long in-depth evaluation of Intel VT-d technology To quote the abstract We discuss three software attacks that might allow for escaping from a VT-d-protected driver domain in a virtualization system We then focus on one of those attacks, and demonstrate practical and reliable code execution exploit against a Xen system Finally, we discuss how new hardware from Intel offers a potential for protection against our attacks in the form of Interrupt Remapping for client systems available only on the very latest Sandy Bridge processors But we also discuss how this protection could be circumvented on a Xen system under certain circumstances I think the attack is likely the most complex and surprising out of all the things we have presented so far Parts of it are even funny if you share our weird sense of humor , such as the use of ICMP ping to generate MSIs The paper also covers the vendors' response You can download the paper here http://www.secuobs.com/revue/news/304659.shtmlhttp://www.secuobs.com/revue/news/304659.shtml Secuobs.com : 2011-04-23 17:32:13 - The Invisible Things Lab's blog - There certainly is one thing that most Linux users don't realize about their Linux systems this is the lack of GUI-level isolation, and how it essentially nullifies all the desktop security I wrote about it a few times, I spoke about it a few times, yet I still come across people who don't realize it all the time So, let me stress this one more time if you have two GUI applications, eg an OpenOffice Word Processor, and a stupid Tetris game, both of which granted access to your screen your X server , then there is no isolation between those two apps Even if they run as different user accounts Even if they are somehow sandboxed by SELinux or whatever None, zero, null, nil The X server architecture, designed long time ago by some happy hippies who just thought all the people apps are good and non-malicious, simply allows any GUI application to control any other one No bugs, no exploits, no tricks, are required This is all by design One application can sniff or inject keystrokes to another one, can take snapshots of the screen occupied by windows belonging to another one, etc If you don't believe me, I suggest you do a simple experiment Open a terminal window, as normal user, and run xinput list, which is a standard diagnostic program for Xorg on Fedora you will likely need to install it first yum install xorg-x11-apps xinput list It will show you all the pointer and keyboard devices that your Xorg knows about Note the ID of the device listed as AT keyboard and then run as normal user xinput test id It should now start displaying the scancodes for all the keys you press on the keyboard If it doesn't, it means you used a wrong device ID Now, for the best, start another terminal window, and switch to root eg using su, or sudo Notice how the xinput running as user is able to sniff all your keystrokes, including root password for su , and then all the keystrokes you enter in your root session Start some GUI app as root, or as different user, again notice how your xinput can sniff all the keystrokes you enter to this other app Yes, I can understand what is happening in your mind and heart right now Don't worry, others have also passed through it Feel free to hate me, throw out insults at me, etc I don't mind, really I just won't moderate them When you calm down, continue reading In Qubes the above problem doesn't exist, because each domain each AppVM has it own local, isolated, dummy X server The main X server, that runs in Dom0 and that handles the real display is never exposed to any of the AppVMs directly AppVMs cannot connect to it via the X protocol For details see this technical overview You can repeat the same experiment in Qubes You just need to use the ID of the qubesdev device, as shown by xinput list should be 7 Run the xinput in one of your domains, eg in the red one Because we actually use the same device for both mouse and keystrokes, you should now see both the key scancodes, as well as all the mouse events Notice how your xinput is able to sniff all the events that are destined for other apps belonging to the same domain where you run xinput, and how it is unable to sniff anything targeted to other domains, or Dom0 BTW, Windows is the only one mainstream OS I'm aware of, that actually attempts to implement some form of GUI-level isolation, starting from Windows Vista See eg this ancient article I wrote in the days when I used Vista at my primary laptop Of course, it's still easy to bypass this isolation, because of the huge interface that is exposed to each GUI client that also includes GPU API Nevertheless, they at least attempt to prevent this at the architecture level http://www.secuobs.com/revue/news/300423.shtmlhttp://www.secuobs.com/revue/news/300423.shtml Secuobs.com : 2011-04-16 15:06:20 - The Invisible Things Lab's blog - So, I've been reading this article this morning on how the US private and public institutions are going to revolutionize the way we authenticate on the web The ground breaking idea, also illustrated on this NIST animation, is to use 3rd party authorities that would first verify your identity somehow Can we see your id , What is your Mam's maiden name , etc , and then would issue you some kind of a token that you would later use for authentication on the web A token would be eg a smart card, or a USB stick probably they just mean a smart card with USB connector, whatever , or even a phone application The idea is that the user will not have to remember all those passwords for all the various websites, which apparently is a problem in practice, because most users never heard about password manager apps, and so they actually try to remember all those passwords, or even try to use the same one all over the place Using one password for more than one website is obviously wrong and people should be told not to do that But an easy way to solve this is to just get people to use password managers But the key problem that they try to solve, which is identity theft, is just not gonna be solved by this password revolution This is because if somebody has compromised my laptop, then it really doesn't matter if I use passwords, or smart cards, or whatever other multi-factor authentication mechanism -- none of them will help if the attacker controls my operating system Most people cannot just get it -- this is because they lack understanding of how computers and operating systems work They don't understand that the operating system can impersonate the user at will This is because the operating system fully controls the keyboard, the mouse, and the screen So, imagine you use your super-secure smart card token for authentication to your bank So, before you log into your bank account, and perhaps before you make any transaction on the banking website, you must insert your smart card somewhere eg into smart card reader, or into USB port, etc Before you insert your token, no one can impersonate you on the bank website So far, so good But then, once you inserted your token, it's all lost The compromised OS could have saved your PIN to this card when you used it previously even if you configured it not to do so and now, immediately, it could use the inserted card to authenticate as you to the bank and start issuing transactions on your behalf And you won't even notice this all, because in the meantime it will show you a faked screen of your banking account After all, it fully controls the screen The bottom line is that we cannot secure our digital lives, if our client operating systems could not be secured first And today, the operating systems we use on our laptops, such as Windows, or Mac, or Ubuntu, are just trivial to be compromised by the attackers After all, if that wasn't true we wouldn't have all those problems with identity theft But introduction of tokens won't make our operating systems any more secure What we need instead are technologies that allow to build next-generation trusted operating systems Technologies such as Intel TXT or VT-d And we need OS vendors to actually start using them You can say I'm biased, because of our work on Qubes OS But then, consider this -- perhaps we would never invest so much money and resources into this project, if we believed there are other ways to bring security to our digital life http://www.secuobs.com/revue/news/298901.shtmlhttp://www.secuobs.com/revue/news/298901.shtml Secuobs.com : 2011-04-12 09:35:33 - The Invisible Things Lab's blog - I'm very proud to announce that we have just released Qubes Beta 1 Some new features that have come into this release include Installer finally , Improved template sharing mechanism service VMs can now be based on a common template, and you can now easily create many net- and proxy- VMs template upgrades now don't require shutting down all the VMs Standalone VMs, convenient for development, as well as for installing the least trusted software, Built in, easy to use firewall VM s , Seamless integration of virtualized tray icons check the screen shots Redesigned file-copy between domains easier, more secure , Default template based on Fedora 14 x64 Reasonably complete User Guide and many other improvements and bug fixes To download the installation ISO go to this page You can also install Qubes on an external USB disk - this might be a convenient option if you want to just try it out, without the need to sacrifice your laptop This release is very stable, but we feel that it still requires some more polish, mostly with regards to user interface We're planning to release at least one more beta, in about 2 months, where we will focus mostly on UI improvements, and also on upgrading Xen and kernel in Dom0 to allow for better hardware support The final Qubes 10 is planned after the summer holidays Once we reach this milestone, further work will likely fork into two branches The commercial branch which will focus on adding various extensions on top of Qubes 1 One specific commercial extension that we think would be a killer is support for Windows-based domains AppVMs , The open source branch that will continue on implementing even more revolutionary architecture and features, such as untrusted storage domains, safe GPU multiplexing, trusted boot, etc In the end this should lead to Qubes 20 sometime in 2012 or 2013 Cross your fingers http://www.secuobs.com/revue/news/297741.shtmlhttp://www.secuobs.com/revue/news/297741.shtml Secuobs.com : 2011-03-13 14:59:30 - The Invisible Things Lab's blog - The diagram below illustrates how I have decomposed my digital life into security domains This is a quite sophisticated scheme and most users would probably want something simpler, but I think it's still interesting to discuss it The domains are implemented as lightweight AppVMs on Qubes OS The diagram also shows what type of networking connectivity each domain is allowed Let's discuss this diagram bit by bit The three basic domains are work the green label , personal the yellow label , and red for doing all the untrusted, insensitive things these are marked on the diagram with bold frames A quick digression on domain labels colors in Qubes OS each domain, apart form having a distinct name, is also assigned a label, which basically is one of the several per-defined colors These colors, which are used for drawing window decorations by the trusted Window Manager color frames , are supposed to be user friendly, easy noticeable, indicators of how trusted a given window is It's totally up to the user how he or she interprets these colors For me, it has been somehow obvious to associate the red color with something that is untrusted and dangerous the red light -- stop danger , green with something that is safe and trusted, while yellow and orange with something in the middle I have also extended this scheme, to also include blue, and black, which I interpret as indicating progressively more trusted domains than green, with black being something ultimately trusted Back to my domains the work domain is where I have access to my work email, where I keep my work PGP keys, where I prepare reports, slides, papers, etc I also keep various contracts and NDAs here yes, these are PDFs, but received from trusted parties via encrypted and signed email otherwise I open them in Disposable VMs The work domain has only network access to my wok email server SMTP IMAP4 over SSL , and nothing more For other work-related tasks that require some Web access, such as editing Qubes Wiki, or accepting LinkedIn invites, or downloading cool pictures from fotoliacom for my presentations, or specs and manuals from intelcom, for all this I use work-pub domain, which I have assigned the yellow label, meaning I consider it only somehow trusted, and I would certainly never put my PGP keys there, or any work-related confidential information The personal domain is where all my non-work related stuff, such as personal email and calendar, holiday photos, videos, etc, are held It doesn't really have access to the Web, but if I was into social networking I would then probably allow HTTPS to something like Facebook Being somehow on the paranoid side, I also have a special very-personal domain, which I use for the communication with my partner when I'm away from home We use PGP, of course, and I have a separate PGP keys for this purpose While we don't discuss any secret and sensitive stuff there, we still prefer to keep our intimate conversations private I use shopping for accessing all the internet e-commerce sites Basically what defines this domain is access to my credit card numbers and my personal address for shipping Because I don't really have a dedicated corporate credit card, I do all the shopping in this domain, from groceries, through sports equipment, on hotel plane reservations ending If I had separate business credit cards, then I would probably split my shopping domain into personal-shopping and work-shopping I also have banking domain, which I use only for managing my bank account which again combines both my personal and company accounts I also have a few specialized work-related domains, that I rarely use The work-admin domain is used to manage almost all of the ITL servers, such as our webserver, Qubes repo wiki servers, email server and DNS management, etc This domain is allowed only SSH traffic to those server, and HTTPS to a few Web-based management servers The work-blog is used to manage this very blog you're reading now The reason why it is separate from work-admin or work, is because I'm over paranoid, and because I fear that if somebody compromises the blogger service, and subsequently exploits a bug in my browser that I use for editing my blog, than I don't want this person to be able to also get admin access to all the ITL servers Similarly, if somebody somehow compromised eg the Amazon Web Management Console, and then exploited my browser in work-admin, then I would like at least to retain access to my blog If I used twitter, I would probably also manage it from this work-blog domain, unless it was a personal twitter account, in which case I would run it from personal The qubes-dev domain is used for all the Qubes development, merging other developers' branches after I verify signatures on their tags, of course , building RPMs ISOs yes, Qubes Beta 1 will ship as a DVD ISO , and finally signing them Because the signing keys are there, this domain is very sensitive This domain is allowed only SSH network access to our Qubes git server Again, even if somebody compromised this Git server, it still would not be a big problem for us, because we sign and verify all the tags in each others repos unless somebody could also modify the SSH Git daemons running there so that they subsequently exploit a hypothetical bug in my git client software when I connect to the server I also decided to keep all the accounting-related stuff in a separate domain whenever I get an invoice I copy it to the accounting domain The rationale for this is that I trust those PDFs much less than I trust the PDFs I keep in my work domain Once a year I move the old stuff from my work domain, such as old email spools, old contracts and NDAs, to the work-archives domain This is to minimize the potential impact of the potential attack on my work domain my work domain could be attacked eg by exploiting a hypothetical bug in Thunderbird's protocol handshake using a MITM attack, or a hypothetical bug in GPG The vault domain is an ultimately trusted one where I generate and keep all my passwords using keepass and master GPG keys Of course, this vault domain has no networking access Most of those passwords, such as the email server access password is also kept in the specific domains which uses them, such as the work domain, and more specifically in the Thunderbird client there is absolutely no point in not allowing eg Thunderbird to remember the password if it got compromised it would just steal it the next time I manually enter it And finally, there is the previously mentioned red domain I have tried to call it junk or random in the past, but I think red is still a better name after all The red domain is totally untrusted if it gets compromised, I don't care I would just recreate it within seconds I don't even back it up Basically I do there everything that doesn't fit into other domains, and which doesn't require me to provide any sensitive information I don't differentiate between work-related and personal-related surfing even I don't care about anonymity for all those tasks I do there If I was concerned about anonymity, I would create a separate anonymous domain, and proxy all the traffic through a tor proxy from there Now, this all looks nice and easy but there is one thing that complicates the above picture Data flows between the domains The diagram below shows the same domains, but additionally with arrows symbolizing typical data flows between them You can see that most of the usual data flows are from more trusted domains to less trusted domains eg copy and pasting a URL that I receive via email in my work domain, so that I could open it in my untrusted browser in red, or moving invoices from my work domain where I receive them via email to the accounting domain But there are, unfortunately, also some transfers from less trusted domains to more trusted ones One example is copy and pasting an interesting URL that I just stumbled upon when surfing in the red domain, and that I would like to share with a college at work, or a friend, and so I need to copy and paste it to my email client in either work colleague or personal friend domain Now, copying data from less trusted domains to more trusted ones presents a significant problem While one could think that pasting an URL into Thunderbird email editor is a pretty harmless operation, it's still is an untrusted input and we don't really know what the red domain really pasted into its local clipboard, and so what we will paste into the work domain's Thunderbird email editor perhaps 64kB of some junk that will overflow some undo buffer in the editor And even more scary is the example with copying the cool-looking graphics file from the Web into my work domain so that I could use it in my presentation slides eg an xkcd Attacks originating through malicious JPEGs or other graphics format, and exploiting bugs in rendering code have been known for more than a decade But this problem how to handle data flows from less trusted systems to more trusted ones is not easily solvable in practice, unfortunately Some people who design and build high-security systems for use by military and government takes a somehow opposite approach they say they are not concerned about less-trusted-to-more-trusted data transfers as long as they could assure there is no way to perform a transfer in the opposite direction So, if we could build a system that guarantees that a more trusted domain can never transfer data to a less trusted domain even if both of those domains are compromised , then they are happy to allow one-way up transfers In practice this means we need to eliminate all the covert channels between two cooperating domains The word cooperating is a key word here, and which makes this whole idea not practical at all, IMHO Elimination of the covert channels between cooperating domains is indeed required in this scheme, because the assumption is that the data transfer from the less trusted domain could have indeed compromised the more trusted domain But this, at least, should not result in any data leak back to the originating domain, and later to the less-classified network, which this less-trusted domain is presumably connected to One of the assumptions here is that the user of such a system is connected to more than one, isolated networks Even in that case, elimination of all the covert channels between domains or at least minimizing their bandwith to something unusable what is unusable, really is a big challenge, and can probably only could be done when we're ready to significantly sacrifice the system's performance smart scheduling tricks are needed to minimize temporal covert channels I would like to make it clear that we are not interested in eliminating cooperative covert channels between domains in Qubes any time in the near future, and perhaps in the long term as well I just don't believe into such approach, and I also don't like that this approach does nothing to preserve the integrity of the more-trusted domain it only focuses on the isolation aspect So, perhaps the attacker might not be able to leak secrets back to the less trusted domain, but he or she can do everything else in this more trusted domain What good is isolation, if we don't maintain integrity An alternative solution to handling the less-trusted-to-more-trusted data transfers, is to have trusted converters or verifiers that could handle specific file types, such as JPEGs, and ensure we get a non-malicious file in the destination domain While this might remind the bad-old A V technology, it is something different Here, the trusted converters would likely be some programs written in a safe language, running in another trusted domain, rather than a big ugly A V with a huge database of signatures of bad patterns of what might appear in a JPEG file The obvious problem with such an approach is that somebody must write those converters, and write them for all file types that we wish to allow to be transferred to more trusted domains Perhaps doable in the longer-term, and perhaps we will do it in some future version of Qubes Right now we are ignoring this problem, and we say that all less-trusted-to-more-trusted transfers are to be done on the user's own risk You're welcome to submit trusted converters for your favorite file type s in the meantime Copying files between domains Speaking of copying files between domains, there is another security catch here If we imagined two physically separated machines that share no common network resources, the only way to move files between those two air-gaped machines would be via something like a USB stick or a CDROM or DVD disc But inserting a USB drive or CDROM into a machine triggers a whole lot of actions from parsing device-provided information, loading required drivers for USB , parsing the driver's partition table, mounting and finally parsing the filesystem Each of this stage requires the machine's OS to perform a lot of untrusted input processing, and the potential attack space here is quite large So, even if we could limit ourselves to copy only harmless files between machines domains perhaps they were somehow verified by a trusted party in-between, as discussed above , still there is a huge opportunity that the originating domain could compromise the target domain In Qubes Alpha we have been using a similar file copy mechanism, using a virtual stick for file copy between domains In Qubes Beta 1 we will provide a new scheme based on same shared memory channel that we use for GUI virtualization the technical details of this solution will be available soon in our wiki The most sensitive element in this new scheme is the un-cpio-like utility that runs in the target domain and unpacks the incoming blob into the pre-defined directory tree eg home user incoming from- domainname We believe we can write pretty safe un-cpio-like utility, in contrast to secure all the previously mentioned elements USB device parsing, partition parsing, fs parsing The Qubes Beta 1 is planned to be released at the end of March, BTW Partitioning enforcement and easy of use For any security partitioning scheme to make sense in real life, it is necessary to have some enforcement mechanism that would ensure that the user doesn't mistakenly bypass it Specifically for this purpose we have come up with special, previously-mentioned firewalling support in Qubes Beta 1, that I will cover in a separate article soon Anther thing is to make the partitioning easy to use For instance, I would like to be able to setup a hint in the policy, that when I click on an URL in an email I received in my work domain that it should be automatically opened in the red domain's default Web browser Currently we don't do that in Qubes, but we're thinking about doing it in the near future Summary Partitioning one's digital life into security domains is certainly not an easy process and requires some thinking This process is also very user-specific The partitioning scheme that I've come up for myself is quite sophisticated, and most people would probably want something much simpler In case of corporate deployments, the scheme would be designed by CIO or IT admins, and enforced on users automatically Much bigger problem are home and small business users, who would need to come up with the partitioning themselves Perhaps in future versions of Qubes we will provide some ready to use templates for select typical groups of users http://www.secuobs.com/revue/news/291305.shtmlhttp://www.secuobs.com/revue/news/291305.shtml Secuobs.com : 2011-03-08 15:54:29 - The Invisible Things Lab's blog - I just realized yesterday that my wallet has disappeared, with all my credit cards, Polish ID card, and driver's license inside Most likely somebody stole it No strange transactions have been observed on my credit card accounts yet, but these are generally not much of a concern, thanks to credit card insurance What is more troubling, is that perhaps some other woman is currently using my stolen ID and the driver's license doing nasty things on my account Apparently there is little one can do in Poland EU in order to invalidate a stolen ID card While there is an inter-bank Polish-wide database of stolen ID cards, it is being used only by banks, so it can only prevent other people from applying for small loans for bigger loans, one would need more documents But there are so many other things one could do, such as renting a car and then committing a crime with it , signing up a deal with a mobile carrier and then committing a cyber crime using this phone, or just making a really huge bill , or perhaps buying an SSL cert With apparently no better option left, I decided to write this blog post -- hopefully somebody will find it, eg before issuing a Class 2 SSL cert to the fake Joanna Rutkowska Here are the numbers of my lost stolen documents AFS739530 5058 Luckily I have had my ID details written down somewhere, and the driver's license number I extracted from my Hertz profile A scene at a police department in Warsaw Hi, I would like to report my wallet being lost or stolen Madam, was your wallet stolen, or have you lost it Officer, how could I possibly know this If I lost it, do you really think I would remember the very moment of losing it Madam, you must be sure whether it was a crime or not A scene on the hotline, calling my mobile provider note that I decided to use the word stolen this time Hi, my documents have been stolen -- I would like that you indicate my ID card as invalid in your system that you hopefully share with other telcom operators You should report such an incident to the police, Madam Right, but I guess that neither you, nor any other mobile provides in Poland will consult a Police database before signing up a contract with a strange person who might be using my stolen documents, correct Oh, but we will not sign a contract with a strange person who uses your documents Only with you And how would you know it was not me, if that person was similarly aged and looking, and was using my stolen ID and driver's license http://www.secuobs.com/revue/news/290138.shtmlhttp://www.secuobs.com/revue/news/290138.shtml Secuobs.com : 2010-12-06 20:20:54 - The Invisible Things Lab's blog - It's been a bit quiet on the Qubes development front for the last 2 months The reason for this was that Rafal and myself got fully engaged in a new commercial research project After all, we do need to make money somehow, so that we could later spend them on funding Qubes development But this new engagement is actually closely related to what we do with Qubes ie how new hardware technologies allow to build more secure OSes , so it's not like we're abandoning Qubes, as the experience we get with this research project will surely be useful for us when designing and implementing the Qubes 20 architecture In order to continue with Qubes, we've decided to hire some Linux programmers, while Rafal and I will continue with our research project over the coming months We've decided to start a cooperation with another Polish computer outfit, TLS Technologies, who specializes in advanced systems design and implementation There are a couple of people people from TLS engaged in Qubes, and you will soon meet them on qubes-devel, in our wiki, and of course, you will see their contributions in our git repos The plan is to have Beta 1 released sometime in January 2010 The two important features that will be implemented first, and that will make it into Beta 1 apart for the long-awaited installer are Firewall VMs, and support for templates for service VMs Stay tuned for more details soon If everything goes smoothly, then we should expect Qubes 10 sometime at the end of Q1 2011 http://www.secuobs.com/revue/news/269705.shtmlhttp://www.secuobs.com/revue/news/269705.shtml Secuobs.com : 2010-10-06 18:01:42 - The Invisible Things Lab's blog - We have just uploaded the new packages for the Qubes Alpha 3 milestone A lot of under the hood work went into this release, including Support for fast-booting Disposable VM see also implementation description here Dynamic memory balancing between AppVMs Redesigned networking and NetVM support for VT-d system Reasonably stable S3 sleep support suspend-to-RAM , that works even with a NetVM Improved GUI virtualization all known bugs fixed finally Disposable VMs are really a killer feature IMO The screenshot below shows the user's experience The user righ-clicks on a PDF file, chooses Open in Disposable VM , and then waits 1 2 3 4 seconds assuming a reasonably modern laptop and the document automagically opens in a fresh new Disposable VM If you make some changes to the document eg if it was a PDF form, and you edited it , those changes will propagate back to the original file in the original AppVM So, within 4-5 seconds, Qubes creates a new VM, boots it up actually refreshes from a savefile , copies the file in question to the VM, and finally opens the application that is a registered MIME handler for this type of documents, eg a PDF viewer We're pretty confident this time could be further decreased down to some 2 seconds, or maybe even less This is planned for some later Beta release Dynamic memory balancing allows to better utilize system physical memory by moving it between running AppVMs in realtime, according to the VM's real needs This allows to run more VMs, compared to a scheme with static memory allocation, and also dramatically eliminates system hiccups, that otherwise occur often in a static scheme when one of the VMs is short of memory and initiates swapping The screenshot above shows the memory usage on my 6GB laptop when writing this blog post As you can see I can easily run a dozen of AppVMs most users will not need that many, but I'm a bit more paranoid I guess and could probably even start a few more if there was such a need eg open some Disposable VMs Of course, this all depends on the actual type of workload the user runs in each VM - most of my AppVMs run just one or two applications, usually a Web browser Firefox , but some, eg the work, and personal AppVMs run much more memory-hungry applications such as Open Office, or Picasa Photo Browser I very rarely see more than 1 GB of memory allocated to a single VM, though Generally speaking, the new memory management in Qubes works pretty nice Currently, the biggest slow-down factor for Qubes is somehow poor disk performance, most likely caused by the joint impact of the Xen backend, Linux dm, and kcryptd we use the simplest possible Xen block backend for security reasons, will move to more sophisticated backends when we introduce untrusted storage domain in Qubes 20 Now, most of the under-the-hood work for Qubes 10 seems to be complete, and now it time for all the polishing of the user experience, which will be the main focus of the upcoming Beta development Just reminding that we're currently looking to hire developers for this effort The Installation instructions can be found here Enjoy http://www.secuobs.com/revue/news/254755.shtmlhttp://www.secuobs.com/revue/news/254755.shtml Secuobs.com : 2010-09-28 16:01:30 - The Invisible Things Lab's blog - We're looking to hire one or two full time developers, who will be working on the open source version of Qubes OS, with the primary task of advancing it from Alpha to Beta stage, and then finally to a production quality version We're looking to hire developers, not necessarily security researchers Specifically we expect the following from candidates Many years of experience with Linux GNU development, including system-level and kernel-level Linux development, documented by the actual projects, Familiarity with virtualization technologies, and specifically with Xen hypervisor, Basic understanding of the Qubes architecture and excitement about the project Product-oriented approach polishing, testing, packaging, understanding of user needs , Good communication skills in written English In return we offer the following benefits Decent, full-time salary, Opportunity to be part of a renown security team, Opportunity to work on an exciting product, Work on a GPLed project with all the benefits it gives to the developer visibility, rights to the code If you're interested in joining our team, please send a message to joanna at invisiblethingslabcom Please do not send typical resumes don't write about schools you finished, certificates you obtained, driving license, scuba trainings, etc We are only interested in a short bio keep it below 100 words please , and links to your past or current projects Include your geographic location While it would be great if you were based in Warsaw or somewhere in Poland , as it would allow for regular face-to-face meetings, this is not a critical factor ITL doesn't have a physical office, and everybody work from their apartments, so there is no need to relocate to Warsaw, in case you happened to be based somewhere else http://www.secuobs.com/revue/news/252433.shtmlhttp://www.secuobs.com/revue/news/252433.shtml Secuobs.com : 2010-09-17 01:08:14 - The Invisible Things Lab's blog - A couple of months ago, while working on Qubes GUI virtualization, Rafal has come up with an interesting privilege escalation attack on Linux a user-to-root escalation , that exploits a bug in well, actually it doesn't exploit any concrete bug, which makes it so much more interesting The attack allows a unpriviliged user process that has access to the X server so, any GUI application to unconditionally escalate to root but again, it doesn't take advantage of any bug in the X server In other words any GUI application think eg sandboxed PDF viewer , if compromised eg via malicious PDF document can bypass all the Linux fancy security mechanisms, and escalate to root, and compromise the whole system The attack allows even to escape from the SELinux's sandbox -X jail To make it worse, the attack has been possible for at least several years, most likely since the introduction of kernel 26 You can find the details of the attack, as well as the discussion of possible solutions, including the one that has eventually been implemented, in the Rafal's paper One important aspect the attack demonstrates, is how difficult it is to bring security to a desktop platform, where one of the biggest challenges is to let applications talk to the GUI layer eg X server in case of Linux , which usually involves a very fat GUI protocol think X protocol, or Win32 GUI API and a very complex GUI server, but at the same time keep things secure This was one of the key priories for us when designing Qubes OS architecture So, we believe Qubes is much more secure than other sandboxing mechanisms, such as BSD jails, or SELinux-based sandboxes, because it not only eliminates kernel-level exploits, but also dramatically slims down GUI-level attacks The kernel-level patch has been implemented last week by Linus Torvalds, and pushed upstream into recent stable kernels RedHat has also released an advisory for this attack, where they rated its severity as high ps Congrats to Brad Spengler for some good guessing http://www.secuobs.com/revue/news/246901.shtmlhttp://www.secuobs.com/revue/news/246901.shtml Secuobs.com : 2010-09-17 01:08:14 - The Invisible Things Lab's blog - Back in the '80s, there was an operating system called MS-DOS This ancient OS, some readers might not even remember it today, had a very simple security model every application had access to all the user files and other applications Today, over two decades later, overwhelming majority of people still use the very same security model Why Because on any modern, mainstream OS, be that Linux, Mac, or Windows, all the user applications still have full access to all the user's files, and can manipulate all the other user's applications Does it mean we haven't progressed anywhere from the MS-DOS age Not quite Modern OSes do have various anti-exploitation mechanisms, such as ASLR, NX, guard pages well, Linux has it since last week at least , and even some more But in my opinion there has been too much focus on anti-exploitation, and on bug finding, and on patching, of course , while almost nothing has been done on the OS architecture level Does anybody know why Linux Desktops offer ability to create different user accounts What a stupid question, I hear you saying - different accounts allow to run some applications isolated from user's other applications Really No The X server, by design, allows any GUI application to mess with all the other GUI applications being displayed by the same X server on the same desktop So, what good it is to have a random_web_browsing user, if the Firefox run under this user account would still be able to sniff or inject keystrokes to all my other GUI applications, take screenshots of them, etc Yes, I know, the user accounts allows also to theoretically share a single desktop computer among more than one physical users also known as people , but, come on, these days it's that a single person has many computers, and not the other way around One might argue that the progress in the anti-exploitation, and also safe languages, would make it nearly impossible to eg exploit a Web browser in the next few years, so there would be no need to have a random_web_browsing user in the first place But, we need isolation not only to protect ourselves when somebody exploits one of our application eg a Web Browser, or a PDF viewer , but also, and perhaps most importantly, to protect from maliciously written applications Take summer holiday example imagine you're a scuba diver - now, being also a decently geeky person, no doubt you will want to have some dive log manager application to store the history of your dives on a computer There are a dozen of such applications on the web, so all you need to do is to pick one you know, the one with the nicest screenshots , and well you need to install it on your laptop now But, hey, why this little, made by nobody-knows-who, dive application should be given unlimited access to all your personal files, work email, bank account, and god-know-what-else-you-keep-on-your-laptop Anti-exploitation technology would do exactly nothing to prevent your files in this case Aha, it would be so nice if we could just create a user diving , and run the app under this account In the future, you could throw in some advanced deco planning application into the same account, still separated from all the other applications But, sorry, that would not work, because the X server doesn't provide isolation on the GUI-level So, again, why should anybody bother creating any additional user accounts on a Linux Desktop Windows Vista made a little step forward in this area by introducing integrity levels, that, at least theoretically, were supposed to prevent GUI applications from messing with each other But they didn't scale well IIRC there were just 3 or 4 integrity levels available , and it still isn't really clear if Microsoft treats them seriously So, why do we have user accounts on Linux Desktops and Macs is beyond me I guess Mac's X server doesn't implement any GUI-level isolation either - if I'm wrong, please point me out to the appropriate reference And we haven't even touched the problems that might arise from the attacker exploiting a bug in the over-complex GUI server API, or in the big fat kernel with hundreds of drivers In order for those attacks to become really interesting like the Rafal's attack we presented yesterday , the user would have to already be using eg different X servers and switch between them using Ctrl-Shift-Fn , or some sandboxing mechanisms, such as SELinux sandbox, or, in case of Vista, a scheme similar to this one http://www.secuobs.com/revue/news/246900.shtmlhttp://www.secuobs.com/revue/news/246900.shtml Secuobs.com : 2010-09-17 01:08:14 - The Invisible Things Lab's blog - The work on Qubes OS has been extremely exciting and also very challenging for us While most of the work we have been doing so far relates to solving various technical, under-the-hood challenges, the more important goals in the long-term are related more to mitigating the so called human factor , ie making the system not only easy to use, but tolerant to user absentmindedness This includes eg ensuring the user uses a correct AppVM eg do the banking in the banking AppVM, and not in the random web browsing AppVM, and also not the other way around don't do random surfing in the banking AppVM , and generally making the whole isolation between AppVMs as seamless as possible, but without sacrificing the security at the same time This is becoming very important, as the technical level of security in Qubes is already very high, and so the human factor might easily become a low hanging fruit for the attacker In contrast to other OSes But for Qubes to become something more than just an interesting OS for Linux geeks and security enthusiasts, it is also critical to have better application support Right now Qubes lets users run Linux apps, because each AppVM is Linux-based But, and let's not be afraid to admit this Linux sucks when it comes to application support Take Open Office as an example - it not only looks like MS Office 97, but is also terribly user-unfriendly, especially their presentation program, the Impress Why is it so difficult to make it look and behave more like Apple Keynote There is only one way to provide better application support to Qubes make it support Windows-based, or Mac-based, AppVMs Just imagine that being able to run most of your Windows or Mac applications, but at the same time benefit from the Qubes strong isolation and seamless integration on one common desktop In order to implement support for Windows-based AppVMs or alternatively Mac-based AppVM we would need to engage significant resources 5 very skilled developers, working full time for 1 year , and so we're currently looking for an investor that would be able to provide funding for such an endeavor The idea is to create a dedicated spin-off company that would focus entirely on Qubes and Qubes Pro, and in the future will make a profit from selling Qubes Pro licenses Qubes Pro will become a commercial product, still based on the open source Qubes, but adding support for Windows-based or Mac-based AppVMs I would be happy to discuss the details and business plan via email with interested potential investors Speaking about the future of Qubes next week I will speak at the European Trusted Infrastructure Summer School, where I will talk about some general stuff like why we need secure desktop systems and why trusted computing might be a way to go, but will also dive a little bit into some new things we plan for Qubes 20, such as storage domain and split I O graphics model The conference features some very reputable speakers in system-level security field, such as David Grawrock the father of Intel TXT and TPM , and Loic Duflot our venerable competitor in the filed of offensive system-level research , so I consider a honour to deliver an opening keynote there Check the agenda here I will have my Qubes laptop with me, of course, so if anybody is interested to see Qubes OS live including Disposable VMs , I would be happy to do a quick demo on the spot http://www.secuobs.com/revue/news/246899.shtmlhttp://www.secuobs.com/revue/news/246899.shtml Secuobs.com : 2010-09-17 01:08:14 - The Invisible Things Lab's blog - Why do we need secure desktop systems Why support from hardware is necessary to build secure desktop OSes Does virtualization make things more, or less complex Why Dynamic RTM Intel TXT is better than Static RTM Can we have untrusted GUI domain subsystem I tried to cover those questions in my recent keynote at ETISS, and you can grab the slides here Particularly, the slide 18 presents the idealistic view of an OS that could be achieved through the use of hardware virtualization and trusted boot technologies It might look very similar to many other pictures of virtualized systems one can see these days, but what makes it special is that all the dark gray boxes represent untrusted domains so, their compromise is not security-critical, except for the potential of a denial-of-service No OS currently implements this architecture, even Qubes We still have Storage and GUI subsystem in Dom0 so they are both trusted , although we already know we think how to implement the untrusted storage domain this is described in detail in the arch spec , and the main reason we don't have it now is that TXT market adoption is so poor, that very few people could make use of it The GUI subsystem is, however, a much bigger challenge When we think about, it should really feel impossible to have an untrusted GUI subsystem, because the GUI subsystem really sees all the pixmaps that are to be displayed to the user, so also all the confidential emails, documents, etc The GUI is different in nature than the networking subsystem, where we can use encrypted protocols to prevent the netvm from sniffing or meaningfully intercepting the application-generated traffic, or the storage subsystem, where we can use fs-encryption and trusted boot technologies to keep the storage domain off from reading or modifying the files used by apps in a meaningful ways We cannot really encrypt the pixmaps in the apps, or AppVMs , because for this to work we would need to have graphics cards that would be able to do the decryption and key exchange note how this is different from the case of an untrusted storage domain, where there is no need for internal hardware encryption , and the idea of putting, essentially an HTTPS webserver on your GPU is doubtful at best, because it would essentially move the target from the GUI domain to the GPU, and there is really no reason why lots-of-code in the GPU were any harder to attack than lots-of-code in the GUI domain So we came out recently with an idea of a Split I O model that is also presented in my slides, where we separate the user input keyboard, mouse , and keep it still in dom0 trusted domain , from the output GUI, audio , which is moved into an untrusted GUI domain We obviously need to make sure that the GUI domain cannot talk to other domains, to make sure it cannot leak out the secrets that it sees while processing the various pixmaps For this we need to have the hypervisor ensure that all the inter-domain shared pages mapped into the GUI domain are read-only for the GUI domain, and this would imply that we need the GUI protocol, exposed by the GUI domain to other AppVMs, to be unidirectional There are more challenges though, eg how to keep the bandwith of timing covert channels, such as those through the CPU caches, between the GUI domain and other AppVMs on a reasonably low level please note the distinction between a covert channel, which require cooperation of two domains, and a side-channel, which requires just one domain to be malicious - the latter are much more of a theoretical problem, and are of a concern only in some very high security military systems, while the former are easy to implement in practice usually, and present a practical problem in this very scenario Another problem, that was immediately pointed out by the ETISS audience, is that an attacker, who compromised the GUI domain, can manipulate the pixmaps that are being processed in the GUI subsystem to present false picture to the user remember, the attacker should have no way to send them out anywhere This includes attacks such as button relabeling OK becomes Cancel and the other way around , content manipulation 1,000,000 instead of 100 , and vice-versa , security labels spoofing red -labeled windows becoming green -labeled , and so on It's an open question how practical these attacks are, at least when we consider automated attacks, as they require ability to extract some semantics from the pixmaps where is the button, where is the decoration , as well as understanding the user's actions, intentions, and behavior just automatically relabeling my Friefox label to green would be a poor attack, as I would immediately realize something is going wrong Nevertheless this is a problem, and I'm not sure how this could be solved with the current hardware architecture But do we really need untrusted GUI domain That depends Currently in Qubes the GUI subsystem is located in dom0, and thus it is fully trusted, and this also means that a potential compromise of the GUI subsystem is considered fatal We try to make an attack on GUI as hard as possible, and this is the reason we have designed and implemented special, very simple GUI protocol that is exposed to other AppVMs instead of eg using the X protocol or VNC But if we wanted to add some more features , such as 3D hardware acceleration for the apps 3D acceleration is already available to the Window Manager in Qubes, but not for the apps , then we would not be able to keep the GUI protocol so simple anymore, and this might result in introducing exploitable fatal bugs So, in that case it would be great to have untrusted GUI domain, because we would be able to provide feature-rich GUI protocols, with all the OpenGL-ish like things, without worrying that somebody might exploit the GUI backend We would also not need to worry about putting all the various 3rd party software in the GUI domain, such as KDE, Xorg, and various 3rd party GPU drivers, like eg NVIDIA's closed source ones, and that some of it might be malicious So, generally, yes, we would like to have untrusted GUI domain - we can live without it, but then we will not have all the fancy 3D acceleration for games, and also need to carefully choose and verify the GUI-related software which is lots of software But perhaps in the next 5 years everybody will have a computer with a few dozens of cores, and also the CPU-to-DRAM bandwidth will be orders of magnitude faster than today, and so there will be no longer a need to offload graphic intensive work to a specialized GPU, because one of our 64 cores will happily do the work Wouldn't that be a nicer architecture, also for many other reasons eg better utilization of power circuit real estate In that case nobody will need OpenGL, and so there will be no need for a richer GUI protocol than what is already implemented in Qubes It's quite exciting to see what will happen and what we will come up for Qubes BTW, some people might confuse X server de-privileging efforts, ie making the X server run without root privileges, which is being done in some Linux distros and BSDs, with what had been described in this article, namely making the GUI subsystem untrusted Please note that a de-priviliged X server doesn't really solve any major security problems related to GUI subsystem, as whoever controls 0wns the X server depriviliged or not can steal or manipulate all the data that this X server is processing displaying Apparently there are some reasons why people want to run Xorg as non-root, but in case of typical desktop OSes this provides little security benefit unless you want to run a few X servers with different user accounts, and on different vt's, which most people would never do anyway http://www.secuobs.com/revue/news/246898.shtmlhttp://www.secuobs.com/revue/news/246898.shtml Secuobs.com : 2010-09-17 01:08:14 - The Invisible Things Lab's blog - I'm constantly being asked about it, and so I thought I would write a handy blog post, so I could just referrer to it in the future, when yet anther person asks me if I think the use of Thin Clients is a game-changer to desktop security It is not Thin Clients do not improve your desktop security in any way, and that's because 1 You still run a regular full-blown OS, such as Widows and all the regular applications, such as those buggy PDF readers, Web browsers, etc - it's just you run them all on some corporate server, rather on your laptop The fact that you run the OS on the corporate server, doesn't make it any less prone to compromises, compared to if you run it locally on your laptop 2 A compromise of your laptop, even if it's just a dump terminal, is still fatal This is because if your laptop's kernel or MBR, or BIOS, or some PCI device's firmware, or GPU is compromised, the attacker can intercept steal spoof all the data that you work on remotely, because it is still your laptop that processes the input keystrokes, mouse events and output pixels So, an Evil Maid attack on your laptop when you use it as a Thin Client, would be just as devastating, as it is otherwise and don't fool yourselves that crypto tokens can help We really need secure end-user systems, even if we just want to use them as dump terminals only There is really no way we could skip this step and eg focus only on infrastructure, or services security http://www.secuobs.com/revue/news/246897.shtmlhttp://www.secuobs.com/revue/news/246897.shtml Secuobs.com : 2010-07-01 17:56:06 - The Invisible Things Lab's blog - The Alpha 2 is out New screenshots are here http://www.secuobs.com/revue/news/236911.shtmlhttp://www.secuobs.com/revue/news/236911.shtml Secuobs.com : 2010-06-02 02:37:32 - The Invisible Things Lab's blog - While we're still busy with some last few tickets left for Qubes Alpha 2 milestone, Rafal has already started working on a new feature for Qubes Beta 1 on Disposable VMs I think this is really gonna be a killer feature, and I wanted to say a few words about it Disposable VMs will be very lightweight VMs that can be created and booted in a very short time, say 1s, with a sole purpose of hosting only one application, eg a PDF viewer, or a Media Player To understand why Disposable VMs are important, imagine the following situation -- you receive an email from a customer that contains a PDF attachment, say an invoice or a contract Obviously you're opening and reading the message in an email client running in your work AppVM or work-email AppVM, if you're paranoid , just because it is a work-related correspondence, arriving at your professional email address for many reasons it is good to use different email addresses for job-related activities and for personal life However, chances of somebody compromising your email client by just sending you a maliciously crafted message that would exploit your body or subject parsers are very small, if you have disabled full HTML parser for message bodies which I think most security-concious people do anyway Perhaps a more effective attack vector would be for somebody to 0wn your email server first, and then try to exploit IMAP POP SMTP protocol parser in your email client But hey, in that case, they already would get access to all your emails on the corporate server, without exploiting your email client well, they could however gain access to your PGP keys this way -- if this bothers you, you might want to use smartcards for PGP keys There is also a possibility to do a Man-In-The-Middle attack and try to exploit SSL protocol early parsers, but this could be prevented using a separate VPN AppVM in Qubes But now you would like to open this PDF that a customer just sent you It's quite reasonable to be afraid that the PDF might be malicious and might try to exploit your PDF viewer, and then try to steal your emails or other things you keep in the work AppVM or work-email AppVM It doesn't matter if you trust the sender, as the sender's OS might very well be compromised by some malware and might be infecting all outgoing PDFs without the user consent You could try opening the PDF in one of your non-sensitive VMs, eg the random VM that you use for causal Web browsing, to make sure that even if the PDF is malicious, that it won't get access to any sensitive data But what if the PDF is not malicious, and what if it contains some confidential data In that case you might throw the baby out with the bath water your random VM might have been already compromised and now it would be able to steal the secrets from your PDF file A disposable VM is an ideal solution here You create a clean, disposable VM, just for the purpose of viewing the PDF Then, once you're done, you just throw it away If the PDF was malicious it could done harm only to its own disposable VM, that doesn't contain anything except this very PDF At the same time, the disposable VM is always started in a clean state, so there is no way somebody could steal the document Only the document can steal itself That all sounds easy, but to make it practical we need a very efficient implementation of disposable VMs, and a good system integration, so the experience was seamless to the user Eg the user should only be required to right-click on a file and choose Open in a Disposable VM , and Qubes should take care about everything else creating the VM, starting it, copying the file to the VM, and starting a MIME-associated application for this type of file eg PDF in the VM And this all in time below 1s Basic support for Disposable VMs is planned for Beta 1, which is scheduled sometime at the end of the summer holidays But I can tell that's just the beginning The ultimate goal, from the user's point of view, would be to make Qubes OS to look and behave just like a regular mainstream OS like Linux, or Windows, or even Mac, but still with all the strong security that Qubes architecture provides, deployed behind the scene Seamless support for Disposable VM is one of the first steps to achieve this goal Special credits go to Matt Piotrowski, who just left Berkeley University, and whose recently published thesis was a direct inspiration to implement disposable VMs in Qubes While we did mention one-time VMs in our architecture document back in January see chapter 46 , it really was Matt's paper that convinced me we should really have them in Qubes Virtics, a proof-of-concept implementation written by Matt, shares lots of similarities with Qubes, like eg architecture and implementation of the GUI virtualiztion There are also differences though, and I refer readers to the Matt's paper for more details http://www.secuobs.com/revue/news/227700.shtmlhttp://www.secuobs.com/revue/news/227700.shtml Secuobs.com : 2010-05-03 18:52:38 - The Invisible Things Lab's blog - You must have heard about it before formally verified microkernels that offer 100pourcents security Why don't we use such a microkernel in Qubes then The difference between a micro-kernel and a type I hypervisor is blurry Especially in case of a type I hypervisor used for running para-virtualized VMs, such as Xen used in Qubes So I would call Xen a micro-kernel in this case, although it can also run fully-virtualized VMs, in which case it should be called a hypervisor I think In order to formally prove some property of any piece of code, you need to first assume certain things One such thing is the correctness of a compiler, so that you can be sure that all the properties you proved for the source code, still hold true for the binary generated from this source code But let's say it's a feasible assumption -- we do have mature compilers indeed Another important assumption you need, and this is especially important in proving kernels microkernels hypervisors, is the model of the hardware your kernel interacts with Not necessarily all the hardware, but at least the CPU eg MMU, mode transitions, etc and the Chipset While the CPUs are rather well understood today, and their architecture we're talking IA32 here doesn't change so dramatically from season to season The chipsets, however, are a whole different story If you take a spec for any modern chipset, let's say only the MCH part, the one closer to the processor on Core i5 i7 even integrated on the same die , there are virtually hundreds of configuration registers there Those registers are used for all sorts of different purposes -- they configure DRAM parameters, PCIe bridges, various system memory map characteristics eg the memory reclaiming feature , access to the infamous SMM memory, and finally VT-d and TXT configuration So, how are all those details modeled in microkernels formal verification process Well, as far as I'm aware, they are not They are simply ignored The nice way of saying this in academic papers is to say that we trust the hardware This, however, might be incorrectly understood by readers to mean we don't consider physical attacks But this is not equal And I will give a practical example in a moment I can bet that even the chipset manufactures think eg Intel do not have formal models for their chipsets again, I will give a good example to support this thesis below But why are the chipsets so important Perhaps they are configured safe by default on power on, so even if we don't model all the configuration registers, and their effects on the system, and if we won't be playing with them, maybe it's safe to assume all will be fine then Well, it might be that way, if we could have secure microkernels without IOMMU VT-d and without some trusted boot mechanism But we need IOMMU Without IOMMU there is no security benefit of having a microkernel vs having a good-old monolithic kernel Let me repeat this statement again there is no point in building a microkernel-based system, if we don't correctly use IOMMU to sandbox all the drivers Now, setting up IOMMU VT-d permissions require programming the chipset's registers, and is by no means a trivial task see the the Intel VT-d spec to get an impression, if you don't believe me Correctly setting up IOMMU is one of the most security-critical tasks to be done by a hypervisor microkernel, and so it would be logical to expect that they also formally prove that this part is done flawlessly The next thing is the trusted boot I will argue that without proper trusted boot implementation, the system cannot be made secure And I'm not talking about physical attacks, like Evil Maid I'm talking about true, remote, software attacks If you haven't read it already, please go back and read my very recent post on Remotely Attacking Network Cards Building on Loic's and Yves-Alexis' recent research, I describe there a scenario how we could take their attack further to compromise even such a securely designed system as Qubes And this could be possible, because of a flaw in TXT implementation And, indeed, we demonstrated an attack on Intel Trusted Execution Technology that exploits one such flaw before Let's quickly sketch the whole attack in points 1 The attacker attacks a flaw in the network card processing code Loic and Yves-Alexis 2 The attacker replaces the NIC's firmware in EEPROM to survive the reboot Loic and Yves-Alexis 3 The new firmware attacks the system trusted boot via a flaw in Intel TXT ITL If the system uses SRTM instead, it's even easier -- see the previous post ITL If you have new SINIT module that patched our attack, there is still an avenue to attack TXT via SMM ITL 4 The microkernel hypervisor gets compromised with a rootkit and the attacker gets full control over the system o And this is the practical example I mentioned above I'm sure readers understand that this is just one example, of what could go wrong on the hardware level and be reachable to a software-only attacker Don't ignore hardware security Even for software attacks A good question to ask is would a system with a formally verified microkernel also be vulnerable to such an attack And the answer is yes Yes, unless we could model and prove correctness of the whole chipset and the CPU But nobody can do that today, because it is impossible to build such a model If it was, I'm pretty sure Intel would already have such a model and they would not release an SINIT module with this stupid implementation bug we found and exploited in our attack So, we see an example of a practical attack that could be used to fully compromise a well designed system, even if it had a formally verified microkernel hypervisor Compromise it remotely, over the network So, are all those whole microkernel hypervisor formal verification attempts just a waste of time Are they only good for academics so that they could write more papers for conferences Or for some companies to use them in marketing Perhaps the formal verification of system software will never be able to catch up with the pace of hardware development By the time people will learn how to build models and how to solve them for hardware used today, the hardware manufactures, in the meantime, will present a few new generations of the hardware For which the academics will need another 5 years to catch up, and so on Perhaps the industry will take a different approach Perhaps in the coming years we will get hardware that would allow us to create untrusted hypervisors kernels that would not be able to read write usermode pages Hey Howard This is currently not possible with the hardware we have, but, hey, why would a hypervisor need access to the Firefox pages And how this all will affect Qubes Well, the Qubes project is not about building a hypervisor or a microkernel Qubes is about how to take a secure hypervisor microkernel, and how to build the rest of the system in a secure, and easy to use, way, using the isolation properties that this hypervisor microkernel is expected to provide So, whatever kernels we will have in the future better formally verified, eg including the hardware in the model , or based on some exciting new hardware features, still Qubes architecture would make perfect sense, I think http://www.secuobs.com/revue/news/218255.shtmlhttp://www.secuobs.com/revue/news/218255.shtml Secuobs.com : 2010-05-01 17:23:59 - The Invisible Things Lab's blog - If you have been following my research over the last several years even in the days before ITL , you will undoubtedly notice how much I have changed the profile over that time Several years ago, myself and Alex Tereshkin who later became ITL employee 1 , were known mostly as rootkit researchers It was back in the days when the word rootkit was not as much well known as it is today It became well known sometime in the late 2005, and I remember when I was applying for a US Visa that year, the immigration officer in the Warsaw embassy asked me what I did professionally and when I replied that I was a security researcher specializing in rootkits, he was very happy to tell me that he just read about those rootkits somewhere, although he was not very much worried about them, because he was a Mac user But then, in the coming years, we decided to explore other areas, like virtualization, trusted computing, chipset security, and even touched on the CPU security briefly Many valuable contributions in those areas have come from Rafal Wojtczuk, who joined our team some two years ago And then, finally, we became ready to actually build something meaningful Not just yet another nonsense trivial-to-break security product , but something that have had a potential to really improve user's security And so, the Qubes project idea has been born, and soon it became ITL's highest priority project So, these days we don't do any reverse engineering or malware analysis any more We'd rather design systems so they be immune to rootkits by design eg by significant TCB reduction , rather then analyze each and every new rootkit sample caught in the wild and try to come up with a detector for it Of course, this all doesn't mean we're giving up on our offensive research There is still a chance you will hear about some new attacks from us But this would surely be limited only to the attacks that we consider relevant in an environment that is already designed with security in mind, like Qubes So, eg an attack against VT-d, or some CPU exploit, or a Xen exploit, might be extremely interesting But don't expect to see any research on how to eg compromise Windows 7 or Mac kernel or break out of their primitive sandboxes -- these systems are so badly designed from a security standpoint, that coming up with a yet-another attack against them makes little sense from a scientific point of view Naturally, I'm all excited about this all that I've been exploring new areas, and that my work has eventually started becoming meaningful But that is, of course, only mine subjective opinion Specifically, this turned out not be the case for Alex, who simply enjoys reverse engineering and compiler hacking just for the sake of doing it Alex did some excellent job on metamorphic code generators, that are years ahead of what you can read at public conferences Unfortunately, with the current new course we took at ITL, Alex started getting less and less chances to apply his skills, and faced a decision whether to stay at ITL and do other things, ie other than reversing or compiler hacking, or to quit and continue doing what he has always liked to do The reader has probably figured out by now that Alex decided to quit ITL I fully understand his decision and wish him all the best in his new adventures You should still be able to reach Alex using his old ITL's email address alex , or directly via his new email alextereshkin at gmailcom http://www.secuobs.com/revue/news/217970.shtmlhttp://www.secuobs.com/revue/news/217970.shtml Secuobs.com : 2010-04-30 16:18:13 - The Invisible Things Lab's blog - I've finally found some time to study Loic Duflot's and Yves-Alexis Perez's recent presentation from the last month on remotely attacking network cards You can get the slides here In short, they're exploiting a buffer overflow in the network card's firmware by sending malicious packets to the card, and then they gain full control over the card's firmware, so they can eg issue DMA to from the host memory, effectively fully controlling the host that's another example of Ring -3 rootkit I would say The buffer overflow is in some exotic management protocol that I think is disabled by default, but that's irrelevant implemented by the NIC's firmware the NIC has its own RISC processor, and memory, and stack, which they overflow, etc I like this research very much, because it demonstrates several important things First, it shows that it is definitely a good idea to isolate sandbox all the OS networking code using IOMMU VT-d And this is exactly what we do in Qubes Second, the attack provides a real-world example of why Static Root for Trust Measurement SRTM is inferior to Dynamic RTM DRTM , eg Intel TXT To understand why, let's make the following assumptions 1 The OS VMM properly uses IOMMU to isolate the network card s , just like eg Qubes does 2 Once the attacker got control over the NIC firmware, the attacker can also modify the persistent storage EEPROM where this firmware is kept This has been confirmed by Loic in a private email exchange 3 The system implements trusted boot via SRTM, ie using just BIOS and TPM, without Intel TXT Now, the attacker can modify the firmware in the EEPROM and this will allow the attacker to survive the platform reboot The card's firmware will start executing early in the boot process, definitely before the OS VMM gets loaded Now, the compromised NIC, because it is capable of doing DMA to the host memory, can compromise the image of the VMM in a short time window between the time it got measured and loaded by the trusted OS loader, eg Trusted GRUB, but still before the time VMM had a chance to setup proper IOMMU VT-d protections for itself Of course, in practice, it might be tricky for the compromised NIC firmware to precisely know this time window when it should send a compromising DMA write request If the DMA was issued too early, then the trusted OS loader would calculate a wrong hash and put a wrong value into a PCR register, which would later prevent the system from completing the boot, and prevent the attack If the DMA was issued too late, the IOMMU VT-d protections would already be in-place, and the attack would again be unsuccessful But, hey, much harder obstacles have been worked around by smart exploit writes in the past, so don't comfort yourself that the attack is hard If it's possible, it means this technology is flawed, period And this is where DRTM, AKA Intel TXT, shows its advantage over simple SRTM When you load a hypervisor using TXT, the SENTER instruction would first apply the VT-d protections around the hypervsior image, then do the measurements, and only then load it, with VT-d protections still in-place The above is the theory A few months ago we demonstrated an attack against this scheme, but the attack was exploiting a flaw in the TXT implementation, not in its design, so it didn't render TXT useless as a technology A much bigger problem with Intel TXT is, that Intel still has done nothing to prevent SMM-based attacks against TXT This is what we demonstrated about 15 years ago Our research stressed that TXT without protection from SMM is essentially useless Intel then promised to come up with a spec on how to write an STM, and how TXT should work with STM when to measure load it, etc , but nothing has been released by Intel for all this time AFAIK Now, without STM which is supposed to provide protection from potentially compromised SMM , the TXT cannot really prevent Loic and friends from owning the system, even if it uses such a securely designed OS as Qubes This is because Loic would be able to modify eg the MBR while the system boots thanks to DMA ability of the infected NIC firmware , and then attack an SMM from this MBR I can bet lots of money Loic co would easily find a few other SMM exploits in any recent BIOS if they only wanted to , and then having infected the SMM, they will be able to compromise TXT-loaded hypervisor, and finally compromise the whole system I know there are some people from various governments reading this blog If you really want to have secure systems, consider pushing on Intel to finally do something about the SMM-based attacks against TXT Beware, Intel will try to tell you that, using TXT LCP you can seal your secrets to only trusted SMM images and would try to convince you it's a way to prevent SMM attacks on TXT It is not Only true SMM sandboxing is a proper way to address this problem Anyway, congrats to Loic and colleagues for yet another very interesting and meaningful system-level research http://www.secuobs.com/revue/news/217696.shtmlhttp://www.secuobs.com/revue/news/217696.shtml Secuobs.com : 2010-04-07 14:18:58 - The Invisible Things Lab's blog - For the last 6 months we have been busy with a new project Qubes Qubes is an open source OS based on Xen, X, and Linux, designed to provide strong isolation for desktop computing The link to the project website is at the end of the post The system is currently in the alpha stage, but if you're determined it's actually usable For example I have switched to Qubes around a month ago, and two weeks ago I even decided to wipe and reinstall my Mac Book, which used to be my primary laptop previously Now I use my old Mac Book only for making the slides Apple Keynote really has no competition and Web page for Qubes And I use Qubes for pretty much all the other daily tasks, from work, shopping, banking, random browsing, to Qubes development itself it takes part in the qubes AppVM Just remember to make backups regularly if you decided to use Qubes for anything else than testing and development So, enough of introduction, you will find lots of details including a 40-page PDF describing the system architecture at the Qubes project website Enjoy http qubes-osorg http://www.secuobs.com/revue/news/209740.shtmlhttp://www.secuobs.com/revue/news/209740.shtml Secuobs.com : 2010-01-16 13:35:49 - The Invisible Things Lab's blog - It s interesting how many people don t realize what are the priorities in computer security There are many fields to secure server security, web applications security, network security, and finally desktop security Over the last years I met SO many people that always expressed surprise why I would like to focus on desktop systems security They usually argue that today, as everybody knows, it is the Network that is what computing is all about and that we should focus on securing infrastructure, and forget about the desktops, which are always to be insecure The network is the computer, as somebody said What those people forget about, is that it is always the desktop that ultimately gets access to all the user s secretes -- all the passwords, all the keys, all the corporate documents, all the nude holiday pictures, all the secret love letters, all the credit card numbers, and many more However secure were all the services remote servers and network protocols that we use, if our desktop gets compromised it s all lost The recent incident with Google is just yet another example of that Our desktop systems are the most crucial piece of the whole puzzle It s funny how many people think that by using some thin client solution on their desktops they can solve the problem Of course they cannot Just the fact that your OS executes on a server, rather then on your hardware, doesn t make it any less prone to all the attacks that were otherwise possible when the software executed on your system The attempts to secure desktops have been failing for so many years While recently there is some attempt to minimize likelihood of remote attacks via Web browsers or generally to focus on application security , this is still just the tip of the iceberg -- there are so many other attack avenue that none of the popular OSes even tries to address, that I consider myself a brave person not to say stupid that I actually use my laptop everyday and keep some sensitive information on it Ok, so that s a nice piece of complaining you say, but what are we, at ITL, gonna do about it Well, we just gonna sit and patiently wait for better OSes to appear some day Oh, hell, we won t Happy New Year 9933 F096 8820 0E23 1AF4 078D 8BDB D97D BDEA 9E9D http://www.secuobs.com/revue/news/182367.shtmlhttp://www.secuobs.com/revue/news/182367.shtml Secuobs.com : 2009-12-21 21:04:22 - The Invisible Things Lab's blog - Earlier this year our team has presented an attack against Intel TXT that exploited a design problem with SMM mode being over privileged on PC platforms and able to interfere with the SENTER instruction The Intel response was two-fold to patch the SMM implementation bugs we used for the attack this patch was for both the NVACPI SMM attacks, as well as for the SMM caching attack , and also to start intensify working on STM specification, that is, we heard, planned to be published sometime in the near future STM is a thin hypervisor concept that is supposed to provide protection against potentially malicious SMMs Today we present a totally different attack that allows an attacker to trick the SENTER instruction into misconfiguring the VT-d engine, so that it doesn t protect the newly loaded hypervisor or kernel This attack exploits an implementation flaw in a SINIT AC module This new attack also allows for full TXT circumvention, using a software-only attack This attack doesn't require any SMM bugs to succeed and is totally independent from the previous one The press release is here The full paper is here The advisory published by Intel today can be found here Enjoy http://www.secuobs.com/revue/news/174650.shtmlhttp://www.secuobs.com/revue/news/174650.shtml Secuobs.com : 2009-10-16 04:54:00 - The Invisible Things Lab's blog - From time to time it s good to take a break from all the ultra-low-level stuff, like eg chipset or TXT hacking, and do something simple, yet still important Recently Alex and I got some spare time and we implemented the Evil Maid Attack against TrueCrypt system disk encryption in a form of a small bootable USB stick image that allows to perform the attack in an easy plug-and-play way The whole infection process takes about 1 minute, and it s well suited to be used by hotel maids The Attack Let s quickly recap the Evil Maid Attack The scenario we consider is when somebody left an encrypted laptop eg in a hotel room Let s assume the laptop uses full disk encryption like eg this provided by TrueCrypt or PGP Whole Disk Encryption Many people believe, including some well known security experts, that it is advisable to fully power down your laptop when you use full disk encryption in order to prevent attacks via FireWire PCMCIA or Coldboot attacks So, let s assume we have a reasonably paranoid user, that uses a full disk encryption on his or her laptop, and also powers it down every time they leave it alone in a hotel room, or somewhere else Now, this is where our Evil Maid stick comes into play All the attacker needs to do is to sneak into the user s hotel room and boot the laptop from the Evil Maid USB Stick After some 1-2 minutes, the target laptop s gets infected with Evil Maid Sniffer that will record the disk encryption passphrase when the user enters it next time As any smart user might have guessed already, this part is ideally suited to be performed by hotel maids, or people pretending to be them So, after our victim gets back to the hotel room and powers up his or her laptop, the passphrase will be recorded and eg stored somewhere on the disk, or maybe transmitted over the network not implemented in current version Now we can safely steal confiscate the user s laptop, as we know how to decrypt it End of story Quick Start Download the USB image here In order to burn the Evil Maid use the following commands on Linux you need to be root to do dd dd if evilmaidusbimg of dev sdX Where dev sdX should be replaced with the device representing your USB stick, eg dev sdb Please be careful, as choosing a wrong device might result in damaging your hard disk or other media Also, make sure to use the device representing the whole disk eg dev sdb , rather than a disk partition eg dev sdb1 On Windows you would need to get a dd-like program, eg this one, and the command would look more or less like this one depending on the actual dd implementation you use dd if evilmaidusbimg of Device HarddiskX Partition0 bs 1M where HarddiskX should be replaced with the actual device the represents your stick After preparing the Evil Maid USB stick, you re ready to test it against some TrueCrypt-encrypted laptop more technically a laptop that uses TrueCrypt system disk encryption Just boot the laptop from the stick, confirm you want to run the tool press E and the TrueCrypt loader on your laptop should be infected Now, Evil Maid will be logging the passphrases provided during the boot time To retrieve the recorded passphrase just boot again from the Evil Maid USB -- it should detect that the target is already infected and display the sniffed password The current implementation of Evil Maid always stores the last passphrase entered, assuming this is the correct one, in case the user entered the passphrase incorrectly at earlier attempts NOTE It s probably illegal to use Evil Maid to obtain password from other people without their consent You should always obtain permission from other people before testing Evil Maid against their laptops CAUTION The provided USB image and source code should be considered proof-of-concept only Use this code at your own risk, and never run it against a production system Invisible Things Lab cannot be held responsible for any potential damages this code or its derivates might cause How the Evil Maid USB works The provided implementation is extremely simple It first reads the first 63 sectors of the primary disk dev sda and checks looking at the first sector if the code there looks like a valid TrueCrypt loader If it does, the rest of the code is unpacked using gzip and hooked Evil Maid hooks the TC s function that asks user for the passphrase, so that the hook records whatever passphrase is provided to this function We also take care about adjusting some fields in the MBR, like the boot loader size and its checksum After the hooking is done, the loader is packed again and written back to the disk You can get the source code for the Evil Maid infector here Possible Workarounds So, how should we protect against such Evil Maid attacks There are a few approaches 1 Protect your laptop when you leave it alone Several months ago I had a discussion with one of the TrueCrypt developers about possible means of preventing the Evil Maid Attack, perhaps using TPM see below Our dialog went like this reproduced here with permission from the TrueCrypt developer TrueCrypt Developer We generally disregard janitor attacks since they inherently make the machine untrusted We never consider the feasibility of hardware attacks we simply have to assume the worst After an attacker has worked with your hardware, you have to stop using it for sensitive data It is impossible for TPM to prevent hardware attacks for example, using hardware key loggers, which are readily available to average Joe users in computer shops, etc Joanna Rutkowska And how can you determine that the attacker have or have not worked with your hardware Do you carry your laptop with you all the time TrueCrypt Developer Given the scope of our product, how the user ensures physical security is not our problem Anyway, to answer your question as a side note , you could use eg a proper safety case with a proper lock or, when you cannot have it with you, store it in a good strongbox Joanna Rutkowska If I could arrange for a proper lock or an impenetrable strongbox, than why in the world should I need encryption TrueCrypt Developer Your question was And how can you determine that the attacker has or has not worked with your hardware My answer was a good safety case or strongbox with a good lock If you use it, then you will notice that the attacker has accessed your notebook inside as the case or strongbox will be damaged and it cannot be replaced because you had the correct key with you If the safety case or strongbox can be opened without getting damaged unusable, then it's not a good safety case or strongbox - That's a fair point, but this means that for the security of our data we must relay on the infeasibility to open our strongbox lock in a clean way, ie without visually damaging it Plus it means we need to carry a good strongbox with us to any travel we go I think we need a better solution Note that TrueCrypt authors do mention the possibility of physical attacks in the documentation If an attacker can physically access the computer hardware and you use it after the attacker has physically accessed it, then TrueCrypt may become unable to secure data on the computer This is because the attacker may modify the hardware or attach a malicious hardware component to it such as a hardware keystroke logger that will capture the password or encryption key eg when you mount a TrueCrypt volume or otherwise compromise the security of the computer However, they do not explicitly warn users of a possibility of something as simple and cheap as the Evil Maid Attack Sure, they write or otherwise compromise the security of the computer , which does indeed cover eg the Evil Maid Attack, but my bet is that very few users would realize what it really means The examples of physical attacks given in the documentation, eg modifying the hardware or attaching a malicious hardware, is something that most users would disregard as too expensive an attack to be afraid of But note that our Evil Maid attack is an example of a physical attack, that doesn t require any software modification and is extremely cheap Of course it is a valid point, that if we allow a possibility of a physical attack, then the attacker can eg install a hardware keylogger But doing that is really not so easy as we discuss in the next paragraph On the other hand, spending two minutes to boot the machine from an Evil Maid USB stick is just trivial and is very cheap the price of the USB stick, plus the tip for the maid 2 The Trusted Computing Approach As explained a few months ago on this blog, a reasonably good solution against Evil Maid attack seems to be to take advantage of either static or dynamic root of trust offered by TPM The first approach SRTM is what has been implemented in Vista Bitlocker However Bitlocker doesn t try to authenticate to the user eg via displaying a custom picture shot by the user, with the picture decrypted using a key unsealed from a TPM , so it s still possible to create a similar attack against Bitlocker, but with a bit different user experience Namely the Evil Maid for Bitlocker would have to display a fake Bitlocker prompt that could be identical to the real Bitlocker prompt , but after obtaining a correct password from the user Evil Maid would not be able to pass the execution to the real Bitlocker code, as the SRTM chain will be broken Instead, Evil Maid would have to pretend that the password was wrong, uninstall itself, and then reboot the platform Thus, a Bitlocker user that is confident that he or she entered the correct password, but the OS didn t boot correctly, should destroy the laptop The dynamic root of trust approach DRTM is possible thanks to Intel TXT technology, but currently there is no full disk encryption software that would make use of it One can try to implement it using Intel s tboot and some Linux disk encryption, eg LUKS Please also note that even if we assume somebody cracked the TPM chip eg using an electron microscope, or NSA backdoor , that doesn t mean this person can automatically get access to the encrypted disk contents This is not the case, as the TPM is used only for ensuring trusted boot After cracking the TPM, the attacker would still have to mount an Evil Maid attack in order to obtain the passphrase or key Without TPM this attack is always possible Are those trusted computing-based approaches 100pourcents foolproof Of course not As signalized in the previous paragraph, if an attacker was able to mount a hardware-based keylogger into your laptop which is non-trivial, but possible , then the attacker would be able to capture your passphrase regardless of the trusted boot A user can prevent such an attack by using two-factor authentication RSA challenge-response implemented in a USB token or eg one-time passwords, so that there is no benefit for the attacker to capture the keystrokes But the attacker might go to the extreme and eg replace the DRAM, or even the CPU with malicious DRAM or CPU that would sniff and store the decryption key for later access We re talking here about attack that very few entities can probably afford think NSA , but nevertheless they are theoretically possible Note that an attack with inserting a malicious PCI device that would try to sniff the key using DMA can be prevented using TXT VT-d technology However, just because the NSA can theoretically replace your CPU with a malicious one, doesn t mean TPM-based solutions are useless As for the great majority of other people that do not happen to be on the Terrorist Top 10, these represent a reasonable solution that could prevent Evil Maid attacks, and, when combined with a proper two-factor authentication, also simple hardware based attacks, eg keylogger, cameras, remote keystroke sniffing using laser, etc I really cannot think of a more reasonable solution here 3 The Poor Man s Solution Personally I would love to see TrueCrypt implementing TPM-based trusted boot for its loader, but, well, what can I do Keep bothering TrueCrypt developers with Evil Maid attacks and hope they will eventually consider to use TPM So, in the meantime we have come up with a temporarily poor man s solution that we use at our lab We call it Disk Hasher It s a bootable Linux-based USB stick that can be configured in quite a flexible way to calculate hashes of selected disk sectors and partitions The correct hashes are stored also on the stick of course everything is encrypted with a custom laptop-specific passphrase We use this stick to verify the unencrypted portions of our laptops typically the first 63 sectors of sda, and also the whole boot partition in case of Linux-based laptops where we use LUKS dm-crypt Of course there are many problems with such a solution Eg somebody who can get access to my Disk Hasher USB eg when I m in a swimming pool , can infect it in such a way that it would report correct hashes, even though the disk of my laptop would be evilmaided Another problem with Disk Hasher solution is that it only looks at the disk, but cannot validate eg the BIOS So if the attacker found a way to bypass the BIOS reflashing protection on my laptop, then he or she can install a rootkit there that would sniff my passphrase or the decryption key in case I used one time passwords Nevertheless, our Disk Hasher stick seems like a reasonable solution and we use it often internally at ITL to validate our laptops In fact this is the most we can do, if we want to use TrueCrypt, PGP WDE, or LUKS dm-crypt FAQ Q Is this Evil Maid Attack some l33t new h4ck Nope, the concept behind the Evil Maid Attack is neither new, nor l33t in any way Q So, why did you write it Because we believe it demonstrates an important problem, and we would like more attention to be paid in the industry to solving it Q I m using two-factor authentication, am I protected against EM While a two-factor authentication or one time passwords are generally a good idea eg they can prevent various keylogger attacks , they alone do not provide protection from Evil Maid-like attacks, because the attacker might modify his or her sniffer to look for the final decryption key that would be calculated after the 2-factor authentication completes Q How is Evil Maid different from Stoned-Bootkit The Stoned Bootkit, released a few months ago by an individual describing himself as Software Dev Guru in Vienna , is also claimed to be capable of bypassing TrueCrypt , which we take to mean a capability to sniff TC's passphrases or keys Still, the biggest difference between Stoned Bootkit and Evil Maid USB is that in case of our attack you don t need to start the victim's OS in order to install Evil Maid, all you need to do is to boot from a USB stick, wait some 1 minute for the minimal Linux to start, and then press E , wait some 2 more seconds, and you re done With the Stoned Bootkit, according to the author s description, you need to get admin access to the target OS in order to install it, so you either need to know the Windows admin password first, or use some exploit to get the installer executing on the target OS Alternatively, you can install it from a bootable Windows CD, but this, according to the author, works only against unencrypted volumes, so no use in case of TrueCrypt compromise Q I've disabled boot from USB in BIOS and my BIOS is password protected, am I protected against EM No Taking out your HDD, hooking it up to a USB enclosure case and later installing it back to your laptop increases the attack time by some 5-15 minutes at most A maid has to carry her own laptop to do this though Q What about using a HDD with built-in hardware-based encryption We haven t tested such encryption systems, so we don t know There are many open questions here how is the passphrase obtained from the user Using software stored on the disk or in the BIOS If on the disk, is this portion of disk made read-only If so, does it mean it is non-updatable Even if it is truly read-only, if the attacker can reflash the BIOS, then he or she can install a passphrase sniffer there in the BIOS Of course that would make the attack non-trivial and much more expensive than the original Evil Maid USB we presented here Q Which TrueCrypt versions are supported by the current Evil Maid USB We have tested our Evil Maid USB against TrueCrypt versions 60a - 62a the latest version currently available Of course, if the shape of the TrueCrypt loader changed dramatically in the future, then Evil Maid USB would require updating Q Why did you choose TrueCrypt and not some other product Because we believe TrueCrypt is a great product, we use it often in our lab, and we would love to see it getting some better protection against such attacks Q Why there is no TPM support in TrueCrypt The TrueCrypt Foundation published official generalized response to TPM-related feature requests here Acknowledgments Thanks to the ennead truecryptorg for all the polemics we had which allowed me to better gather my thoughts on the topic The same thanks to Alex and Rafal, for all the polemics I have had with them it's customary for ITL to spend a lot of time finding bugs in each other's reasoning IMAGE http://www.secuobs.com/revue/news/151071.shtmlhttp://www.secuobs.com/revue/news/151071.shtml Secuobs.com : 2009-09-22 20:15:16 - The Invisible Things Lab's blog - Last week I was invited to Hillsboro to speak at the Intel's internal conference on security My presentation title was A Quest To The Core Thoughts on present and future attacks on system core technologies , and my goal was to somehow make a quick summary of the recent research our team has done over the last 12 months or so, and explain why we're so keen on hacking the low-level system components, while all the rest of the world is excited about browser and flash player bugs The slides converted to PDF can be found here As you will see, I decided to remove most of the slides from the Future chapter One reason for that was that we didn't want to hint Loic our competition as to some of our new toys we're working on The other reason was that, I think, the value of presenting only thoughts about attacks, ie unproven thoughts, or, should I even say, feelings about future attacks, has little research value, and while I can understand such information being important to Intel, I don't see how others could benefit from them I must say it was nice and interesting to meet in person with various Intel architects, ie the people that actually design and create our basic universe we all operate in You can always change the OS or even write your own , but still you must stick to the rules, or laws , of the platform unless you can break them IMAGE http://www.secuobs.com/revue/news/143298.shtmlhttp://www.secuobs.com/revue/news/143298.shtml Secuobs.com : 2009-09-02 17:03:35 - The Invisible Things Lab's blog - Every once in a while it s healthy to reinstall your system I know, I know, it s almost a heresy to say that, but that s reality in the world where our systems are totally unverifiable In fact I don t even attempt to verify if my Mac laptop has been compromised in any way most system files are not signed anyway But sometimes, you got this feeling that something might be wrong and you decide to reinstall to start your digital life all over again So, every time I re install a Mac-based system, I end up cursing horribly at Apple s architects Why Because in the Apple World they seem to totally ignore the concept of files integrity, to such extent that it s virtually impossible to get any assurance that the programs I install are in any way authentic ie not tampered by some 3rd party, eg by somebody controlling my Internet connection Take any Apple installer package, eg Thunderbird In most cases an installer package on Mac is a dmg file, that represents an installation disk image Now, when you open such a file under Mac, the OS will never display any information about if this file is somehow signed eg by who or not In fact, I m pretty sure it s never signed What you end up with, is a dmg file that you just downloaded over plaintext HTTP and you have absolutely no way of verifying if it is the original file the vendor really published And you re just about to grant admin privileges to the installer program that is inside this file -- after all it s an installer, so must got root privileges, right well, not quite maybe Beautiful Interestingly, this very same Thunderbird installer, but for Windows, is correctly signed, and Windows, correctly, displays that information together with the ability to examine the certificate and allows the user to make a choice of whether to allow it to run or not Sure, the certificate doesn t guarantee that Mozilla didn t put a nasty backdoor in there, nor that the file was not compromised due to Mozilla s internal server compromise Or that the certificate the private key wasn t somehow stolen from Mozilla, or that the issuing authority didn t make a mistake and maybe issued this certificate to some random guy, who just happened to be named Mozilla But the certificate provides liability If it indeed turns out that this very Thunderbird installer was somehow malicious, I could take this signed file to the court and sue either Mozilla, or the certification authority for all the damages it might have done to me Without the certificate I cannot do that, because I and nobody cannot know if the file was tampered while being downloaded eg malicious ISP or maybe because my system was already compromised But in case of Apple, we have no such choice -- we need to take the risk every time we download a program from the Internet We must bet the security of our whole system, that at this very moment nobody is tampering with out unsecured HTTP connection, and also that nobody compromised the vendor s Web Server, and, of course, we hope that the vendor didn t put any malicious code into its product as we could not sue them for it So that sucks That sucks terribly Without ability to check the integrity of programs we want to install, we cannot build any solid foundations It s funny how people divagate whether Apple implemented ASLR correctly in Snow Leopard, or not Or whether NX is bypassable It s meaningless to dive into such advanced topics, if we cannot even assure that at the day 0 our system is clean We need to start building our systems from the ground up, and not starting from the roof Ability to assure the software we install is not tampered seems like a reasonable very first step Sure it could be compromised 5 minutes later, and to protect against this we should have other mechanisms, like eg mentioned above ASLR and NX And Apple should not blame the vendors for such a situation Vendors would never pay 300 for a certificate , blah, blah , as it is just enough to have a look at the Windows versions of the same products, and that most of them do have signed installers gee, even open-source TrueCrypt, has a signed installer for Windows One should say that a few vendors, seeing this problem on Mac, do publish PGP signatures for their installation files This includes eg PGP Desktop for Mac, KeePassX, TrueCrypt for Mac, and a few others But these are just exceptions and I wonder how many users will be disciplined and savvy enough to correctly verify those PGP signatures in general it requires you to download the vendor keys many months before, keep it in your ring, to minimize possibility that somebody alters both the installer files and the keys you download Some other vendors offer pseudo-integrity by displaying MD5 SHA1 sums on their websites That would make some sense only if the website on which the hashes are displayed was itself SSL-protected still the file signature is a better option , as otherwise we can be sure that the attacker that is tampering with the installer file, will also take care about adjusting the hash on the website But of course this never is the case -- have a look eg at the VMWare download page for the Mac Fusion one need to register first Very smart, VMWare Needles to say, the VMWare Workstation installer for Windows is properly signed BTW, anybody checked if the Apple updates are digitally signed somehow All I wrote here in this post is just trivial It should be just obvious for every decently educated software engineer Believe me it s really is much more fun for me to write about things like new attacks on chipsets or virtualization But I have this little hope that maybe somebody at Apple will read this little post and fix their OS Because I really like Apple products for their aesthetics IMAGE http://www.secuobs.com/revue/news/137004.shtmlhttp://www.secuobs.com/revue/news/137004.shtml Secuobs.com : 2009-08-26 23:15:39 - The Invisible Things Lab's blog - Today I got an advertising email from GlobalSign where I previously bought a code signing certificate for Vista kernel drivers some years ago highlighting their new type of certificates for signing of Adobe PDF files It made me curious, because, frankly, I've been recently more and more missing this feature After a quick online research it turned out that this whole Adobe Certified Documents Services CDS seem to be nothing new, as apparently even Adobe Reader 60 had support for verifying those CDS certificates The certificates are also available from other popular certification authorities like eg Entrust and Verisign, and a couple of others So, I immediately felt stupid that I haven't been aware of such a great feature, which apparently is out there for a few years now Why I thought it was so great a feature Consider the following scenario At our Invisible Things Lab resources page we offer a handful of files to download slides and some proof of concept code The website is served over a plaintext HTTP This means that if you're downloading anything over a public WiFi hotel, airport lounge, etc you never know if the PDF you actually get has not been infected somewhere in the middle, eg by a guy in the lobby that is messing with the hotel WiFi So, one might argue that I should have paid a few hundred bucks and get an SSL certificate for my website and start serving it over HTTPS But here's the problem I, as zillions of other small businesses and individuals, host my website on some 5-dollar-a-month one-of-the-thousands hosting provider I have zero knowledge about what people work there and if they can be trusted, and I also know nothing and have zero impact on how secure or not, for that matter the server is Same applies to my cell phone carrier, ISP, etc, BTW Now, the SSL certificate for the website knows nothing about how the files on my website should look like, in particular if they are compromised or not All the SSL certificate does is to give assurance to the remote client that he or she downloaded the actual files that were on the server in the moment of downloading whether they were the original ones authored by me, or perhaps maliciously modified by somebody who got access to the server So, the solution with an SSL certificate would work only if I trusted my web server, which could be assumed only if I run my own dedicated server That, however, would be an overkill for a small company like ITL, especially that our business is not based on our web presence in fact the website is maintained mainly for other researchers and students, who can easily download our papers and code from there, and also for the reporters so they can eg download a press release from there Surprisingly, the website has never been compromised, probably because it doesn't present an interesting target for any skilled person or maybe exceptionally skilled people work at the hosting provider But I cannot know for sure, as I don't constantly monitor all the hashes of all the files, as this would require well a dedicated server that would be running an SHA1 calculating script in a loop for 24 7 Of course, zillions of other websites works this very same way and present the very same problems Now, ability to sign PDFs would be just a great solution here, because I could sign all those files with my certificate, and then all the people downloading stuff from ITL could know they are getting original PDFs that were created on one of the ITL members desktop computers, no matter how compromised the web server or the network connection is For the same reasons, I would welcome if others started doing the same, as currently I simply must assume every PDF I download from the net and PDFs account for the majority of file downloads I do to be potentially malicious So, I always open them in my Red or Yellow VM depending on the source of the download , and only if it looks good very fuzzy term, I know , I might decide to move it to my host desktop it's easier to work with PDFs on your host, and actually you should use your host desktop for something Yes, I know, Kostya Kortchinsky, or Rafal, can sometimes escape from VMWare, but still I believe that today the best isolation I can get on a desktop, without sacrificing much convince, is via a type II hypervisor It's horribly inelegant, but well, that's life So, I read some more about this Adobe CDS, being all excited about it, and ready to spend a few hundred euros on a certificate, only to realize that it doesn't look as good as I thought First disappointment comes from the fact that you must create a PDF using Adobe Acrobat software not the Reader, but the commercial one I've created all my PDFs using either Office in the past or iWork today , and none of them seem to offer a way to digitally sign the PDF I would like to get a simple tool, say pdfsignexe, that I could use to sign any PDF I have, no matter how I generated it Also, not surprisingly, the Mac native PDF viewer Preview doesn't seem to recognize the digital signature, and I bet some Linux PDF viewers do not as well Worst of all, even the Acrobat Reader 9, that I tested under Windows, and that correctly displayed all the CDS information, does one unbelievably stupid thing it parses and renders the whole PDF before displaying the signature info So, if you downloaded a malicious PDF, Acrobat Reader will happily open it and parse, without asking you a question of whether you would like to open it as it is perhaps unsigned At least I was unable to find an option that would force it to do that So, if this PDF contained an exploit for the reader, it surely would get executed Compare this with the correct behavior of Vista UAC where it presents the executable signature details before executing it You can see how your software works with Adobe PDF signatures, eg by looking at this exemplary file signed by GlobalSign So, Adobe CDS, in the form they are today, seem to be pretty useless, as far as protection from potentially malicious PDFs is considered they surely have other positive applications, eg to certify about authenticity of eg a diploma But wouldn't it be great to have such a file signing mechanism globally adopted and not only for PDFs, but for any sort of files, including ZIPs, tgz's, heck, even plain text files And have our main OSes generically recognize those signatures and display unified prompts of whether we want to allow an application to to open the file or not Perhaps, in some situations, we could even define policies for specific applications This seems easy to do from the technical point of view we just need to hook oh, God, did I say hook high-level OS API's like eg open or CreateFile What about PGP and possibility of using this for signing any sort of files Well, we use PGP a lot at ITL, but mainly for securing peer-to-peer communication eg between us and our clients There really is no good way to publish one's PGP key the concept of Web of Trust might be good for some closed groups of people, but not for publishing files to the world And, of course, the first thing that an attacker who subverted PDFs on our website will do is to also subvert the PGP key displayed on the website I also tried once to publish a PGP key to a key server, but got discouraged immediately after I noticed it didn't use SSL for submission BTW, anybody knows if the key servers today use SSL If not, how the trust is established Maybe email clients, eg Thunderbird, come with built in PGP keys for select key servers So, I guess that was the main point of writing this post to express how madly I would welcome a generic, OS-based, non-obligatory, signature verification for files, based on PKI Ah, before a dozen of people jumps to the comment box to tell me that digital signatures do not assure non-maliciousness of anything please don't do that, because I actually know that In fact, it is not possible to assure non-maliciousness of pretty much anything, especially without strictly defining an ethical system we would like to use first What the signatures provide is the liability, so that I know who to sue, in case my naked holiday pictures got leaked to the public because of some malicious PDF exploiting my system In that case I can sue either the actual person who signed the PDF if this person is identifiable or the certification authority who issued the certificate to a wrong unidentifiable person IMAGE http://www.secuobs.com/revue/news/134896.shtmlhttp://www.secuobs.com/revue/news/134896.shtml Secuobs.com : 2009-08-25 18:43:28 - The Invisible Things Lab's blog - We've just published the proof of concept code for the Alex's and Rafal's Ring -3 Rootkits talk, presented last month at the Black Hat conference in Vegas You can download the code from our website here It's highly recommended that one re reads the slides before playing with the code In short, the code demonstrates injection of an arbitrary ARC4 code into a vPro-compatible chipset AMT ME memory using the chipset memory reclaiming attack Check the README and the slides for more information The actual ARC4 code we distribute here is very simple it sets a DMA write transaction to the host memory every ca 15 seconds in order to write the ITL string at the predefined physical addresses increased by 4 with every iteration Of course one can do DMA read as well The ability to do DMA from the ARC4 code to from the host memory is, in fact, all that is necessary to write a sophisticated rootkit or any sort of malware, from funny jokers to sophisticated secret sniffers Your imagination and good pattern searching is the only limit here The OS, nor any software running on the host OS, cannot access our rootkit code, unless, of course, it used the same remapping attack we used to insert our code there But the rootkit might even cut off this way by locking down the remapping registers, so fixing the vulnerability on the fly, after exploiting it of course it would be insane for any AV to use our remapping attack in order to scan ME space, but just for completeness An OS might attempt to protect itself from DMA accesses from the rootkit in the chipset by carefully setting VT-d protections Xen 33 34, for example, sets VT-d protections in such a way that our rootkit cannot access the Xen hypervisor memory We can, however, access all the other parts of the system which includes all the domains memory ie where all the interesting data are located Still, it should be possible to modify Xen so that it set VT-d mappings in such a strict way, that the AMT code and the AMT rootkit could not access any useful information in any of the domains This, in fact, would be a good idea anyway, as it would also prevent any sort of hardware-based backdoors except for the backdoors in the CPU An AMT rootkit can, however, get around such a savvy OS because it can modify the OS's VT-d initialization code before it sets the VT-d protections Alternatively, if the protections are set before the rootkit was activated, the rootkit can force the system to reboot and boot it from the AMT Virtual CDROM In fact AMT has been designed to be able to do exactly that , which would contain rootkit agent code that would modify the OS VMM to-be-loaded image, so that it doesn't setup VT-d properly Of course, the proper solution against such an attack would be to use eg Intel TXT to assure trusted boot of the system In theory this should work In practice, as you might recall, we have already shown how to bypass Intel TXT This TXT bypass attack still works on most all hardware, as there is still no STM available in the wild all that is needed for the attack is to have a working SMM attack, and last month we showed 2 such attacks see the slides for the BIOS talk Intel has released a patch a day before our presentation at Black Hat This is a cumulative patch that is also targeting a few other, unrelated, problems, like eg the SMM caching attack also reported by Loic , the SMM nvacpi attack, and the Q45 BIOS reflashing attack for which the code will be also published shortly Some of you might remember that Intel has patched this very remapping bug last year, after our Xen 0wning Trilogy presentations, where we used the very same bug to get around Xen hypervisor protections However, Intel forgot about one small detail namely it was perfectly possible for malware to downgrade BIOS to the previous, pre-Black-Hat-2008 version, without any user consent after all this old BIO file was also digitally signed by Intel So, with just one additional reboot but without a user intervention needed malware could still use the old remapping bug, this time to get access to the AMT memory The recent patch mentioned above solves this problem by displaying a prompt during reflash boot, if reflashing to an older version of BIOS So now it requires user intervention a physical presence This downgrade protection works, however, only if we have administrator password enabled in BIOS We could get into the AMT memory on Q35, however, even if the downgrade attack was not possible In that case we could use our BIOS reflashing exploit the other Black Hat presentation However, this situation looks differently on Intel latest Q45 chipsets that also have AMT As explained in the presentation, we were unable to get access to the AMT memory on those chipsets, even though we can reflash the BIOS there, and consequently, even though we can get rid of all the chipset locks eg the remapping locks Still, the remapping doesn't seem to work for this one memory range, where the AMT code resides This suggest Intel added some additional hardware to the Q45 chipset and other Series 4 chipsets to prevent this very type of attacks But we're not giving up on Q45 yet, and we will be trying other attacks, as soon as we recover from the holiday laziness Finally, the nice picture of the Q35 chipset MCH , where our rootkit lives The ARC4 processor is somewhere inside IMAGE http://www.secuobs.com/revue/news/134269.shtmlhttp://www.secuobs.com/revue/news/134269.shtml Secuobs.com : 2009-07-31 04:59:11 - The Invisible Things Lab's blog - The wait is over The slides are here The press release is here Unless you're a chipset BIOS engineer kind of person, I strongly recommend reading the press release first, before opening the slides So, the Ring -3 Rootkit presentation is about vPro AMT chipset compromises The Attacking Intel BIOS presentation is about exploiting a heap overflow in BIOS environment in order to bypass reflashing protection, that otherwise allows only Intel-signed updates to be flashed We will publish the code some time after get back from Vegas Enjoy ps Let me remind my dear readers that all the files hosted on the ITL website are not digitally signed and are served over a plaintext connection HTTP In addition, the ITL's website is hosted on a 3rd party provider's server, on which we have totally no control which is the reason why we don't buy an SSL certificate for the website Never trust unsigned files that you download from the Internet ITL cannot be liable for any damages caused by the files downloaded from our website, unless they are digitally signed IMAGE http://www.secuobs.com/revue/news/126818.shtmlhttp://www.secuobs.com/revue/news/126818.shtml Secuobs.com : 2009-07-17 02:39:08 - The Invisible Things Lab's blog - Alan Dang from Tom's Hardware did an interview with me I talk there about quite a lot of things, many of which I would probably write about on this blog sooner or later or already had , so I thought it might be of interest to the readers of this blog IMAGE http://www.secuobs.com/revue/news/121677.shtmlhttp://www.secuobs.com/revue/news/121677.shtml Secuobs.com : 2009-06-12 15:00:06 - The Invisible Things Lab's blog - VM escapes, hypervisor compromises via "classic" rootkits, as well asBluepill-like rootkits, hypervisor protection strategies, SMMattacks, TXT bypassing, and more — these are some of the topics thatwill be covered by our brand new training on VirtualizationInSecurity at the upcoming Black Hat USAThe training offers quite a unique chance, I think, to absorb theresults of 1+ year of the research done by our team within just 2days This will be provided via detailed lectures and unique hands-onexercisesUnlike our previous training on stealth malware that will also beoffered this year, BTW, this time we will offer attendees a bit ofhope : We will be stressing that some of the new hardwaretechnologies Intel TXT, VT, TPM, if used properly, have potential todramatically increase security of our computer systems Sure, we willbe showing attacks against those technologies eg TXT, butnevertheless we will be stressing that this is the proper way to go inthe long runInterestingly, I'm not aware of any similar training of this kind,that would be covering the security issues related to virtualizationsystems and bare metal hypervisors Hope we will not get into troubleswith the Antitrust Commission for monopolizing this field ;The training brochure something for your boss is hereThe detailed agenda spanning 2 full days can be downloaded hereThe Black Hat signup page is hereIMAGEhttp://www.secuobs.com/revue/news/108998.shtmlhttp://www.secuobs.com/revue/news/108998.shtml Secuobs.com : 2009-06-09 16:56:55 - The Invisible Things Lab's blog - If you think SMM rootkits or PCI backdoors is low-level, then you shouldcertainly see our talks in Vegas — ITL is going to define what doesthe "low-level" adjective really mean at the end of the decade ;In case you haven't noticed it at the Black Hat website yet — Alex andRafal will be giving two presentations in Vegas:1 Introducing Ring -3 Rootkits description2 Attacking Intel® BIOS descriptionLet me stress that we have been in touch with Intel for quite sometime about the above attacks, and that Intel is planning to releaseappropriate fixes a few weeks before our presentations at Black HatThere is more than just this coming at this year's Black Hat — mostnotably we will also be debuting with our Virtualization InSecurityTraining I will write a separate post about this training containinga detailed agenda in the coming days, so stay tunedQuite excitingIMAGEhttp://www.secuobs.com/revue/news/107486.shtmlhttp://www.secuobs.com/revue/news/107486.shtml Secuobs.com : 2009-06-02 03:15:26 - The Invisible Things Lab's blog - I've recently exchanged a few emails with Loic Duflot about CPU-basedbackdoors It turned out that he recently wrote a paper abouthypothetical CPU-backdoors and also implemented some proof-of-conceptones using QEMU for he doesn't happen to own a private CPU productionline The paper can be bought here Loic is an academic, and so hemust follow some of the strange customs in the academic world, one ofthem being that papers are not freely published, but rather being soldon a publisher website… Heck, even we, the ultimately commercializedresearchers, still publish our papers and code for freeLet me stress that what Loic writes about in the paper are onlyhypothetical backdoors, ie no actual backdoors have been found onany real CPU ever, AFAIK What he does is he considers how Intel orAMD could implement a backdoor, and then he simulate this process byusing QEMU and implementing those backdoors inside QEMULoic also focuses on local privilege escalation backdoors only Youshould however not underestimate a good local privilege escalation —such things could be used to break out of any virtual machine, likeVMWare, or potentially even out of a software VMs like eg Java VMThe backdoors Loic considers are somewhat similar in principle to thesimple pseudo-code one-liner backdoor I used in my previous post abouthardware backdoors, only more complicated in the actualimplementation, as he took care about a few important details, that Inaturally didn't concern BTW, the main message of my previous postabout was how cool technology this VT-d is, being able to preventPCI-based backdoors, and not about how doomed we are because of Intel-or AMD-induced potential backdoorsSome people believe that processor backdoors do not exist in reality,because if they did, the competing CPU makers would be able to findthem in each others' products, and later would likely cause a "leak"to the public about such backdoors think: Black PR Here people makean assumption that AMD or Intel is technically capable of reversingeach others processors, which seems to be a natural consequence ofthem being able to produce themI don't think I fully agree with such an assumption though Just thefact that you are capable of designing and producing a CPU, doesn'tmean you can also reverse engineer it Just the fact that Adobe canwrite a few hundred megabyte application, doesn't mean they areautomatically capable of also reverse engineering similar applicationsof that size Even if we assumed that it is technically feasible touse some electron microscope to scan and map all the electronicelements from the processor, there is still a problem of interpretingof how all those hundreds of millions of transistors actually workAnyway, a few more thoughts about properties of a hypotheticalbackdoors that Intel or AMD might use be usingFirst, I think that in such a backdoor scenario everything besides the"trigger" would be encrypted The trigger is something that you mustexecute first, in order to activate the backdoor eg the CMPinstruction with particular, ie magic, values of some registers, sayEAX, EBX, ECX, EDX Only then the backdoor gets activated and egthe processor auto-magically escalates into Ring 0 Loic considersthis in more detail in his paper So, my point is that all theattacker's code that executes afterwards, think of it as of ashellcode for the backdoor, that is specific for the OS, is fetched bythe processor in an encrypted form and decrypted only internallyinside the CPU That should be trivial to implement, while at the sametime should complicate any potential forensic analysis afterwards — itwould be highly non-trivial to understand what the backdoor actuallyhave doneAnother crucial thing for a processor backdoor, I think, should besome sort of an anti-reply attack protection Normally, if a smartadmin had been recording all the network traffic, and also all theexecutables that ever got executed on the host, chances are that he orshe would catch the triggering code and the shellcode which might beencrypted, but still So, no matter how subtle the trigger is, it isstill quite possible that a curious admin will eventually find outthat some tetrisexe somehow managed to breakout of a hardware VM anddid something strange, eg installed a rootkit in a hypervisor orsome Java code somehow was able to send over all our DOCX files fromour home directoryEventually the curious admin will find out that strange CPUinstruction the trigger after which all the strange things hadhappened Now, if the admin was able to take this code and replicateit, post it to Daily Dave, then, assuming his message would passthrough the Moderator Hi Dave, he would effectively compromise theprocessor vendor's reputationAn anti-replay mechanism could ideally be some sort of achallenge-response protocol used in a trigger So, instead having youalways to put 0xdeadbeaf, 0xbabecafe, and 0x41414141 into EAX, EBX andEDX and execute some magic instruction say CMP, you would have toput a magic that is a result of some crypto operation, taking currentdate and magic key as input:Magic = MAGIC Date, IntelSecretKeyThe obvious problem is how the processor can obtain current date Itwould have to talk to the south-bridge at best, which is 1nontrivial, and 2 observable on a bus, and 3 spoof'ableA much better idea would be to equip a processor with some sort of aneeprom memory, say big enough to hold one 64-bit or maybe 128-bitvalue Each processor would get a different value flashed there whenleaving the factory Now, in order to trigger the backdoor, theprocessor vendor or backdoor operator, think: NSA would have to dothe following:1 First execute some code that would read this unique value stored ineeprom for the particular target processor, and send this back tothem,2 Now, they could generate the actual magic for the trigger:Magic = MAGIC UniqeValueInEeprom, IntelSecretKey3 and send the actual code to execute the backdoor and shellcode,with the correct trigger embedded, based on the magic valueNow, the point is that the processor will automatically increment theunique number stored in the eeprom, so the same backdoor-exploitingcode would not work twice for the same processor while at the sametime it would be easy for NSA to send another exploit, as they knowwhat the next value in the eeprom should be Also, such a customizedexploit would not work on any other CPU, as the assumption was thateach CPU gets a different value at the factory, so again it would notbe possible to replicate the attack and proved that the particularcode has ever done something wrongSo, the moment I learn that processors have built-in eeprom memory, Iwill start thinking seriously there are backdoors out there :One thing that bothers me with all those divagations abouthypothetical backdoors in processors is that I find them prettyuseless in at the end of the day After all, by talking about thosebackdoors, and how they might be created, we do not make it any easierto protect against them, as there simply is no possible defense hereAlso this doesn't make it any easier for us to build such backdoorsif we wanted to become the bad guys for a change It might only beof an interest to Intel or AMD, or whatever else processor maker, butI somewhat feel they have already spent much more time thinking aboutit, and chances are they probably can only laugh at what we are sayinghere, seeing how unsophisticated our proposed backdoors are So, myDear Reader, I think you've been just wasting time reading this post; Sorry for tricking you into this and I hope to write something morepractical next time :IMAGEhttp://www.secuobs.com/revue/news/104617.shtmlhttp://www.secuobs.com/revue/news/104617.shtml Secuobs.com : 2009-05-28 03:13:28 - The Invisible Things Lab's blog - Here are the slides about Trusted Computing I used for my presentationsat the EuSecWest today, and at the Confidence conference last weekAs this was supposed to be a keynote, the slides are much lesstechnical then our other slides, and also there are no new attackspresented there Still, I hope they might be useful as some sort of an"alternative" introduction to Trusted Computing :A cool presentation I saw today was about PCI-based backdoors byChristophe Devine and Guillaume Vissian They basically took ageneral-purpose FPGA programmable PC-card AKA PCMCIA, flashed itwith an FPGA "program" that implemented a simple state machine Thepurpose of the state machine was to wait until its DMA engine getsinitialized and then to modify certain bytes in the host memory, thathappened to be part of the winlogonexe process IIRC they changed XORAL, AL into MOV AL, 1, or something like that, at the end of somepassword verification function inside the winlogonexe process Theslides should be available soon on the conference website I also hopethey will publish all the source code needed to flash your ownpersonal "winlogon unlocker"The live demo was really impressive — they showed a winlogon screen,tried to login a few times with wrong passwords, of course all theattempts failed, then they inserted their magic, $300 worth, PC-card,and… 2 seconds later they could log in using any password they wantedWhile not necessary being a breakthrough, as everybody has known suchthings could be done for years, I think it is still important thatsomebody eventually implemented this, discussed the technical detailsFPGA-related, and also showed how to implement it with a cheapgeneric "reflashable" hardware without using a soldering ironOf course I have also discussed in my presentation how to preventPCI-based backdoors like the one discussed here using VT-d, but thisdefense is currently only available if you use Xen 33 or later, andalso requires that you manually create driver domain partitions andcome up with a reasonable scheme for assigning devices to driverdomains All in all 999% of users are not and will not be anytimesoon protected against such attacks Oh, wait, there is actually arelatively simple software-based workaround besides putting a glueinto your PC-card slot, which is not a very subtle one… I wonder whoelse will find out :IMAGEhttp://www.secuobs.com/revue/news/102537.shtmlhttp://www.secuobs.com/revue/news/102537.shtml Secuobs.com : 2009-03-25 15:34:58 - The Invisible Things Lab's blog - So, you're a decent paranoid person, running only open source software onyour box: Linux, GNU, etc You have the feeling you could, if you onlywanted to, review every single line of code of course you willprobably never do this, but anyway You might be even more paranoidand also try running an open source BIOS You feel satisfied andcannot understand all those stupid people running closed sourcesystems like eg Windows RightBut here's where you are stuck — you still must trust your hardwareTrust that your hardware vendor has not eg built in a backdoor intoyour network card micro-controller…So, if we buy a laptop from vendor X, that might be based in somenot-fully-democratic country, how do we know they didn't put backdoorsthere And not only to spy on Americans, also to spy on their owncitizens When was the last time you reverse-engineered all the PCIdevices on your motherboardScared GoodEnters the game-changer: IOMMU known as VT-d on Intel With properOS/VMM design, this technology can address the very problem of most ofthe hardware backdoors A good example of a practical system thatallows for that is Xen 33, which supports VT-d and allows you to movedrivers into a separate, unprivileged driver domains This way eachPCI device can be limited to DMA only to the memory region occupied byits own driverThe network card's microcontroller can still compromise the networkcard driver, but nothing else Assuming we are using only encryptedcommunication, there is not much an attacker can gain by compromisingthis network card driver, besides doing a DoS Similarly for the diskdriver — if we use full disk encryption which is a good idea anyway,there is not much an attacker can gain from compromising the low-leveldisk driverObviously the design of such a system especially used for desktopcomputing is not trivial ans needs to be thoroughly thought out Butit is possible today, thanks to those new virtualizationtechnologiesIt seems than, that we could protect ourselves against potentiallymalicious hardware With one exception however… we still need to trustthe CPU and also the memory controller AKA northbridge AKA chipset,that implements that IOMMUOn AMD systems, the memory controller has long been integrated intothe processor Also Intel's recent Nehalem processors integrate thememory controller on the same dieThis all means we need to trust only one vendor Intel or AMD andonly one component, ie The Processor But should we blindly trustthem After all it would be trivial for Intel or AMD to build in abackdoor into their processor Even something as simple as:if rax == MAGIC_1 etet rcx == MAGIC_2 jmp rbxJust a few more gates in the CPU I guess there are apparently alreadyabout 780 million gates on Core i7, so a few more should not make muchdifference, and no performance penalty Exploitable remotely on mostsystems and any more complex program I guess Yet, totallyundetectable for anybody without an electron microscope and tons ofskills and knowledgeAnd this is just the simplest example that comes to mind within just afew minutes I'm sure one could come up with something even moreuniversal and reliable The fact is — if you are the CPU vendor, it istrivial for you to build in an effective backdoorIt's funny how various people, eg European government institutions,are afraid of using closed source software, eg Windows, because theyare afraid of Microsoft putting backdoors there Yet, they are notconcerned about using processors made by some other US companies Itis significantly more risky for Microsoft to put a backdoor into itssoftware, where even a skilled teenager equipped with IDA Pro can findit, than it is for Intel or AMD, where effectively nobody can find itSo, I wonder whether various government and large corporate customersfrom outside the US will start asking Intel and AMD to provide themwith the exact blueprints of their processors After all they alreadyrequire Microsoft to provide them with the source code under an NDA,right So, why not the "source code" for the processorUnfortunately there is nothing that could stop a processor vendor toprovide its customers with a different blueprints than those that areused to actually "burn" the processors So, the additional requirementwould be needed that they also allow to audit their manufacturingprocess Another solution would be to hire some group of independentresearchers, equip them with an electron microscope and let themreverse engineer some randomly chosen processors… Hmmm, I even know ateam that would love to do that ;A quick summary in case you get lost already:1 On most systems we are not protected against hardware backdoors,eg in the network card controller2 New technologies, eg Intel VT-d, can allow to protect againstpotentially malicious hardware requires specially designed OS,eg specially configured Xen…3 … except for the potential backdoors in the processor4 If we don't trust Microsoft, why should we trust Intel or AMDBTW, in May I will be speaking at the Confidence conference in Krakow,Poland This is gonna be a keynote, so don't expect new attacks to berevealed, but rather some more philosophical stuff about trustedcomputing why it is not evil and problems like the one discussedtoday See you thereIMAGEhttp://www.secuobs.com/revue/news/75062.shtmlhttp://www.secuobs.com/revue/news/75062.shtml Secuobs.com : 2009-03-20 18:05:00 - The Invisible Things Lab's blog - A few reporters asked me if our recent paper on SMM attacking via CPUcache poisoning means the sky is really falling nowInterestingly, not many people seem to have noticed that this is the3rd attack against SMM our team has found in the last 10 months OMG:oBut anyway, does the fact we can easily compromise the SMM today, andwrite SMM-based malware, does that mean the sky is falling for theaverage computer userNo The sky has actually fallen many years ago… Default users withadmin privileges, monolithic kernels everywhere, most softwareunsigned and downloadable over plaintext HTTP — these are the mainreasons we cannot trust our systems today And those pathetic attemptsto fix it, eg via restricting admin users on Vista, but stillrequiring full admin rights to install any piece of stupid softwareOr selling people illusion of security via A/V programs, that cannoteven protect themselves properly…It's also funny how so many people focus on solving the securityproblems by "Security by Correctness" or "Security by Obscurity"approaches — patches, patches, NX and ASLR — all good, but it is notgonna work as an ultimate protection if it could, it would worked outalreadyOn the other hand, there are some emerging technologies out there thatcould allow us to implement effective "Security by Isolation"approach Such technologies as VT-x/AMD-V, VT-d/IOMMU or Intel TXT andTPMSo we, at ITL, focus on analyzing those new technologies, even thoughalmost nobody uses them today Because those technologies couldactually make the difference Unlike A/V programs or Patch Tuesdays,those technologies can change the level of sophistication required forthe attacker dramaticallyThe attacks we focus on are important for those new technologies —eg today Intel TXT is pretty much useless without protection fromSMM attacks And currently there is no such protection, which sucksSMM rootkits sound sexy, but, frankly, the bad guys are doing justfine using traditional kernel mode malware due to the fact that A/Vis not effective Of course, SMM rootkits are just yet anotherannoyance for the traditional A/V programs, which is good, but theymight not be the most important consequence of SMM attacksSo, should the average Joe Dow care about our SMM attacks AbsolutelynotIMAGEhttp://www.secuobs.com/revue/news/73177.shtmlhttp://www.secuobs.com/revue/news/73177.shtml Secuobs.com : 2009-03-19 18:25:15 - The Invisible Things Lab's blog - As promised, the paper and the proof of concept code has just been postedon the ITL website hereA quote from the paper:In this paper we have described practical exploitation of the CPUcache poisoning in order to read or write into otherwiseprotected SMRAM memory We have implemented two working exploits:one for dumping the content of SMRAM and the other one forarbitrary code execution in SMRAM This is the third attack on SMMmemory our team has found within the last 10 months, affectingIntel-based systems It seems that current state of firmwaresecurity, even in case of such reputable vendors as Intel, isquite unsatisfyingThe potential consequence of attacks on SMM might include SMMrootkits 9, hypervisor compromises 8, or OS kernel protectionbypassing 2Don't worry, the shellcode we use in the exploit is totally harmlesshave really no idea how some people concluded we were going torelease an SMM rootkit today — it only increases an internal counteron every SMI and jumps back to the original handler If you wantsomething more fancy, AKA SMM rootkits, you might want to re-readSherri's and Shawn's last year's Black Hat paper and try writingsomething they describe thereThe attack presented in the paper has been fixed on some systemsaccording to Intel We have however found out that even the relativelynew boards, like eg Intel DQ35 are still vulnerable the very recentIntel DQ45 doesn't seem to be vulnerable though The exploit attachedis for DQ35 board — the offsets would have to be changed to work onother boards please do not ask how to do thisKeep in mind this is a different SMM attack than the one we mentionedduring our last month's Black Hat presentation on TXT bypassing theVU#127284 We are planning to present that other attack at theupcoming Black Hat Vegas Hopefully this will not be the only onething that ITL will entertain you with in Vegas — Alex and Rafal arealready working now on something even cooler and even lower levelfor the show, so cross your fingersAnd good luck to Loic with his presentation that is about to startjust nowIMAGEhttp://www.secuobs.com/revue/news/72779.shtmlhttp://www.secuobs.com/revue/news/72779.shtml Secuobs.com : 2009-03-13 14:58:50 - The Invisible Things Lab's blog - Next week's Thursday, March 19th, 1600 UTC, we will publish a paper +exploits on exploiting Intel® CPU cache mechanismsThe attack allows for privilege escalation from Ring 0 to the SMM onmany recent motherboards with Intel CPUs Interestingly, the very sameattack will be presented by another researcher, Loic Duflot, at theCanSecWest conference in Vancouver, Canada, on Thursday 19th, 1600UTC BTW, this is a different SMM-targeting attack than the one wementioned during our recent TXT talk and that is scheduled to bepresented later this yearHere's the full story there is also a moral at the end …Just after our presentation at the Black Hat last month, we ieRafal and I have been independently approached by some person or twodifferent persons — we haven't figured that out actually — there weresome ca 30 people willing to ask us questions after the talk, so it'shard to remember all the faces, who was very curious about our SMMattacks whose details we haven't discussed, of course, because Intelis still working on a fix This persons started asking variousquestions about the attacks and one of the questions, that was askedto both me and Rafal, was if the attack used caching Later that day,during a private ITL dinner, one of us brought this issue, and westarted thinking if it was indeed possible to perform an SMM attackvia CPU caching By the end of the dinner we have sketched out theattack, and later when we got back to Poland, Rafal implemented aworking exploit with code execution in SMM in a matter of just a fewhours I think I used way too many parenthesis in this paragraphSo, being the good and responsible guys that we are, we immediatelyreported the new bug to Intel actually talking to Intel's PSIRT isgetting more and more routined for us in the recent months ; Andthis is how we learnt that Loic came up with the same attack backthen there was no talk description at the conference website —apparently he approached Intel about this back in October 2008, so 3-4months before us — and also that he's planning to present it at theCanSecWest conference in March So, we contacted Loic and agreed to docoordinated disclosure next ThursdayInterestingly, however, none of us was even close to being the firstdiscoverer of the underlying problem that our attacks exploit Infact, the first mention of the possible attack using caching forcompromising SMM has been discussed in certain documents authored asearly as the end of 2005 by nobody else than Intel's ownemployees Stay tuned for the details in our upcoming paperConclusionIf there is a bug somewhere and if it stays unpatched for enough time,it is almost guaranteed that various people will rediscover andexploit it, sooner or later So, don't blame researchers that theyfind and publish information about bugs — they actually do a favor toour society Remember the guy who asked us if our attack used cachingI bet he or his associates also have had exploits for this cachingbug, but apparently didn't notify the vendor Hmm, what they mighthave been doing with the exploit When was the last time you scannedyour system for SMM rootkits ;Anyways, congrats to Loic for being the first one who wrote exploitsfor this bug Also congrats to Intel employees who originally noticedthe problem back in 2005IMAGEhttp://www.secuobs.com/revue/news/70819.shtmlhttp://www.secuobs.com/revue/news/70819.shtml Secuobs.com : 2009-02-19 23:55:20 - The Invisible Things Lab's blog - The new press release covering the basic details about our TXT attack ishereThe paper is hereThe slides converted to a PDF format are here There is also anoriginal version of slides in the Keynote format here for the Macpeople And for all the other people who don't use Mac, but stillvalue the aesthetics , I have also generated a QuickTime clickablemovie out from the Keynote slides -- it can be found here, but itweighs 80MBEnjoyhttp://www.secuobs.com/revue/news/63377.shtmlhttp://www.secuobs.com/revue/news/63377.shtml Secuobs.com : 2009-02-10 19:48:59 - The Invisible Things Lab's blog - Besides breaking the Intel's stuff, we have also been doing other thingsover at our lab Thought I would share this cool screenshot of aVirtual PC running inside Xen More precisely what you see on the picis: Windows XP running inside Virtual PC, that runs inside Vista,which itself runs inside a Xen's HVM VM Both the Virtual PC and Xenare using the Intel's hardware virtualization VT-x is always used forHVM guests on XenOur Nested Xen patch is part of a work done for a customer, so it isnot going to be published Besides it is currently a bit unstable ;It's just a prototype that shows such a thing could be donehttp://www.secuobs.com/revue/news/60442.shtmlhttp://www.secuobs.com/revue/news/60442.shtml Secuobs.com : 2009-01-26 19:22:28 - The Invisible Things Lab's blog - Many people in the industry have an innate fear of closed source AKAproprietary software, which especially applies to everythingcrypto-relatedThe usual arguments go this way: this proprietary crypto software isbad, because the vendor might have put some backdoors in there And:only the open source crypto software, which can be reviewed by anyone,can be trusted So, after my recent post, quite a few people wrote tome and asked how I could defend such an evil thing as BitLocker, whichis proprietary, and, even worse, comes from MicrosoftI personally think this way of reasoning sucks In majority of cases,the fact something is distributed without the accompanying source codedoes not prevent others from analyzing the code We do have advanceddisassemblers and debuggers, and it is really not that difficult tomake use of them as many people thinkOf course, some heavily obfuscated programs can be extremely difficultto analyze Also, analyzing a chipset's firmware, when you do not evenknow the underlying CPU architecture and the I/O map might be hardBut these are special cases and do not apply to majority of software,that usually is not obfuscated at allIt seems like the argument of Backdoored Proprietary Software usuallycomes from the open-source people, who are used to unlimited accessesto the source code, and consequently do not usually have muchexperience with advanced reverse engineer techniques, simply becausethey do not need them in their happy "Open Source Life" It's allDarwinism, after all ;On the other hand, some things are hard to analyze, regardless ofwhether the source code is available or not, think: crypto Also, howmany of you who actively use open source crypto software, egTrueCrypt or GnuPG, have actually reviewed the source code AnyoneYou might be thinking — maybe I haven't looked at the source codemyself, but because it is open source, zillions of other users alreadyhave reviewed it And if there was some backdoor in there, they wouldundoubtedly have found it already Well, for all those open sourcefetishists, who blindly negate the value of anything that is not opensource, I have only one word to say: DebianKeep in mind: I do not say closed source is more secure than opensource — I only resist the open-source fundamentalism, that definesevery proprietary software as inherently insecure, and everything opensource as ultimately secureSo, how should one eg a government institution verifysecurity-level of a given crypto software, eg to ensure there are nobuilt-in backdoors in there I personally doubt it could be performedby one team, as it just usually happens that the same people who mightbe exceptionally skilled in code review, system-level security, etc,at the same time are average cryptographers and vice-versaImagine eg that you need to find out if there are any weaknesses inyour system drive encryption software, something like BitLocker Evenif you get access to the source code, you still would have to analyzea lot of system-level details — how is the trusted boot implementedSRTM DRTM TPM interaction, which system software is trusted, howthe implementation withstands various not-crypto-related attacks egsome of the attacks I described in my previous post, etc…But this all is just system-level evaluation What should come lateris to analyze the actual crypto algorithms and protocols Those latertasks fall into cryptography field and not into system-level securitydiscipline, and consequently should be performed by some other team,the crypto expertsSo, no doubt, it is not an easy task, and the fact if there is orthere is not C/C++ source code available, is usually one of the minorheadaches a good example is our attack on TXT, where we were able todiscover bugs in Intel's specific system software, which, of course,is not open sourcehttp://www.secuobs.com/revue/news/55211.shtmlhttp://www.secuobs.com/revue/news/55211.shtml Secuobs.com : 2009-01-22 23:08:11 - The Invisible Things Lab's blog - In the previous post, I wrote the only one thing I really miss after I'veswitched from Vista to Mac is the BitLocker Driver Encryption Ithought it might be interesting for others to understand my position,so below I describe why I think BitLocker is so cool, and why I thinkother system disk encryption software sucksSo, it's all about the Trusted Boot BitLocker does make use of atrusted boot process, while all the other system encryption softwareI'm aware of, does not But why the trusted boot feature is so usefulLet's start with a quick digression about what the trusted bootprocess is…Trusted boot can be implemented using either a Static Root of Trust ora Dynamic Root of TrustThe Static Root of Trust approach also known as Static Root of TrustMeasurement or SRTM is pretty straightforward — the system startsbooting from some immutable piece of firmware code that we assume isalways trusted hence the static root and that initiates themeasurement process, in which each component measures the next one ina chain So, eg this immutable piece of firmware will firstcalculate the hash of the BIOS and extend a TPM's PCR register withthe value of this hash Then the BIOS does the same with the PCIEEPROMs and the MBR, before handling execution to them Then thebootloader measures the OS loader before executing it And so onAn alternative method to implementing trusted boot is to use DynamicRoot of Trust often called Dynamic Root of Trust Measurement orDRTM Intel's TXT technology, formerly LaGrande, is an example of aDRTM more precisely: TXT is more than just DRTM, but DRTM is thecentral concept on which TXT is built We will be talking a lot aboutTXT next month at Black Hat in DC : This will include discussion ofwhy DRTM might sometimes be preferred over SRTM and, of course, whatare the challenges with bothEssentially, both SRTM and DRTM, in the context of a trusted boot, aresupposed to provide the same: assurance the system that just booted isactually the system that we wanted to boot ie the trusted one andnot some modified system eg compromised by an MBR virusBitLocker uses the Static Root of Trust Measurement SRTM can reallymake sense when we combine it with either TPM sealing or attestationfeature BitLocker uses the former to make sure that only the trustedsystem can get access to the disk decryption key In other words:BitLocker relies on the TPM that it will unseal release thedecryption key needed to decrypt the system partition when and onlywhen the state of chosen PCR registers is the same is it was when thedecryption key was sealed into the TPMOk, why is this trusted boot process so important for the system diskencryption software Because it protects against a simple two-stageattack:1 You leave your laptop can be even fully powered down in a hotelroom and go down for a breakfast… Meanwhile an Evil Maid entersyour room She holds an Evil USB stick in her hand and plugs itinto your laptop and presses the power button The system startsand boots from the USB An Evil version of something similar toour BluePillBoot gets installed into the MBR or to a PCI EEPROMThis Evil Program has only one task — to sniff out the encryptionsoftware's password/PIN and then report it back to the maid nexttime she comes2 So, you come back to your room to brush your teeth after thebreakfast Obviously you cannot refrain from not turning on yourlaptop for a while You just need to enter your disk encryptionpassphrase/PIN/whatever Your encryption software happily displaysthe prompt, like if nothing happened After all how could itpossibly know the Evil Program, like BluePillBoot, has just beenloaded a moment ago from the MBR or a PCI EEPROM It can not So,you enter the valid password, your system gets the decryption keyand you can get access to your encrypted system3 But then you have an appointment at the hotel SPA at least thislittle fun you can have on a business trip, right Obviously youdon't want to look so geeky and you won't take your laptop withyou to the SPA, will you The Evil Maid just waited for thisoccasion… She sneaks again into your room and powers up yourlaptop She presses a magic key combo, which results in the EvilProgram displaying the sniffed decryption password Now, dependingon their level of subtleness, she could either steal your wholelaptop or only some more important data from the laptop Yoursystem disk encryption software is completely useless against hernowYes, I know that's 3 bullets, but the Evil Maid had to sneak intoyour room only twice:So, why the BitLocker would not allow for this simple attack Becausethe BitLocker software should actually be able to know that the systemgets compromised by the Evil Program since the last boot BitLockershould then refuse to display a password prompt And even if it didn'tand asked the user for the password, still it should not be able toget the actual decryption key out from the TPM, because the values inthe certain PCR registers will be wrong they will now account forthe modified hashes of the MBR or PCI EEPROM or BIOS The bottom lineis: the maid is not getting the decryption key just as the user now,which is what this is all aboutAt least this is how the BitLocker should work I shall add adisclaimer here, that neither myself, nor anybody from my team, havelooked into the BitLocker implementation We have not, because, as ofyet, there have been no customers interested in this kind of BitLockerimplementation evaluation Also, I should add that Microsoft has notpaid me to write this article I simply hope this might positivelystimulate other vendors, like eg TrueCrypt Hi David, or Apple, toadd SRTM or, better yet, DRTM, to their system encryption productsOf course, when we consider an idiot-attack, that involves simplygarbbing somebody's laptop and running away with it ie without anyprior preparation like our Evil Maid did, then probably all systemdisk encryption software would be just good enough assuming itdoesn't have any bugs in the crypto codeSome people might argue that using a BIOS password would be just asgood as using trusted boot After all, if we disable booting fromalternate media in BIOS eg from USB sticks and lock down the BIOSusing a password ie using the Power-On password, not just the BIOSsupervisor password, then the above two-stage attacks should not befeasible Those people might argue, that even if the Evil Maid hadcleared the CMOS memory by removing the CMOS battery from themotherboard, still they would be able to notice that something iswrong — the BIOS would not longer be asking for the password, or thepassword would be different from what they used beforeThat is a valid point, but relaying on the BIOS password to providesecurity for all your data might not be such a good idea Firstproblem is that all the BIOSes have had a long history of variousdefault or "maintenance" passwords I actually do not know how thesituation looks today with those default passwords Another problemis that the attacker might first clear the CMOS memory, and thenmodify her Evil MBR program to also display a fake BIOS passwordprompt, that would accept anything the user enters This way the userwill not be alerted that something is wrong and will be willing toprovide the real password for drive decryption when prompted later bythe actual drive encryption softwareOne might ask why can't the attacker use the similar attack againstBitLocker Even if the real BitLocker uses trusted boot process, wecan still infect the MBR, display the fake BitLocker PIN prompt andthis way get into the possession of the user's PINThis attack, however, can be spotted by an inquisitive user — afterall, if he or she knows they provided the correct PIN, then it wouldbe suspicious not to see the system being booted and it won't boot,because the fake BitLocker will not be able to retrieve the passwordfrom the TPM If the fake BitLocker wanted to boot the OS so thatuser didn't suspect anything, it would have to remove itself from thesystem and then reboot the system Again this should alert the userthat something wrong is going onThere is also a much more elegant way of defending against the aboveattack with fake BitLocker prompt — but I'd rather let Microsoft tofigure it out by themselves ;By the way, contrary to a popular belief the BitLocker doesn't protectyour computer from boot-stage infections, eg MBR viruses or BIOS/PCIrootkits As we have been pointing out since the first edition of ourUnderstanding Stealth Malware training at Black Hat in August 2007,BitLocker should not be thought as of a system integrity protectionThis is because it is trivial, for any malware that already got accessto the running Vista, to re-seal the BitLocker key to arbitrary newsystem firmware/MBR configuration Everybody can try it by going toControl Panel/BitLocker Driver Encryption, then clicking on the "TurnOff BitLocker" and choosing "Disable BitLocker Drive Encryption" Thiswill simply save your disk decryption key in plaintext, allowing youto eg reflash your BIOS, boot Vista again and then to enableBitLocker again this would generate a new key and seal it to the TPMwith the new PCR valuesThis functionality has been provided obviously to allow user to updatehis or her firmware But what is important to keep in mind is thatthis process of disabling BitLocker doesn't involve entering anyspecial password or PIN eg the BitLocker's PIN It just enoughthat you are the default user with admin rights or some malwarerunning in this context Pity they decided on the simplest solutionhere But still BitLocker is simply the one coolest thing in Vista andsomething I really miss on all other OSeshttp://www.secuobs.com/revue/news/54257.shtmlhttp://www.secuobs.com/revue/news/54257.shtml