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 e.g. covered adjusting the core Odyssey framework to be more flexible (after all “WNI” is quite a non-standard hypervisor) as well as some components that were Windows-specific, but not WNI-specific (e.g. could very well be used on Hyper-V based Qubes OS in the future). But we also invested lots of time into evaluating all those Windows security mechanisms in order to achieve our specific goals (e.g. proper GUI isolation, networking isolation, kernel object spaces isolation, etc)...
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.
Thursday, January 16, 2014
Subscribe to:
Post Comments (Atom)
27 comments:
No surprises here, but useful to have it all spelled out so clearly.
One minor quibble: you don't explain the distinction between a logon session and a terminal services session, potentially misleading readers into thinking they are the same thing.
The "Windows Simulator" feature of Visual Studio, which enables debugging Windows Store apps in a window while simulating different input and output devices, is supposedly implemented by creating an RDP connection to the local machine [1][2] and works on Windows 8 - a consumer system. It would suggest that the "one interactive session" restriction has been relaxed. Perhaps this could solve the problems described in the paper, if Qubes WNI was retargeted to Windows 8+.
[1] Build 2011 session - Tools for building Metro style apps (at about 32:00)
[2] VS Blog - First look at Windows Simulator
@Jakub:
A quote from the article you referenced:
"Developers need to be careful while modifying the state of the operating system in the Simulator because any changes in the Simulator will be reflected on the local machine itself. Multiple instances of Visual Studio and Expression Blend share the same instance of the Windows Simulator."
Sounds kind of disappointing :/
@Harry:
You're right, this could've been spelled out more clearly. It's hard to find a proper definition of "interactive session" even on MSDN for some reason. What I usually call an interactive session is the whole environment created for a user when they log on to the system either by a physical console or Remote Desktop. That includes a separate address space (not a widely known fact I think, but vital for loading independent copy of win32k.sys for example), window stations, desktops and finally a logon session and a shell process created during interactive logon.
It doesn't help that Microsoft renamed Terminal Services to Remote Desktop Services in Server 2008. I think "proper" name for interactive sessions is "Remote Desktop Sessions" [1]. Of course they are a core part of the system now even without Remote Desktop server.
[1] http://msdn.microsoft.com/en-us/library/aa383496(v=vs.85).aspx
I'm curious: would the hypervisor generalization work you did enable you to run under seccomp-bpf?
@Joanna:
> "Developers need to be careful while modifying the state of the operating system in the Simulator because any changes in the Simulator will be reflected on the local machine itself."
I expect the isolation is the same as provided by a regular Remote Desktop session. The above sentence reads to me as a general warning that this is not some artificial, emulated system (such as that presented by the Windows Phone emulator).
> "Multiple instances of Visual Studio and Expression Blend share the same instance of the Windows Simulator."
This could potentially be quite crippling, but it is not clear whether this is a conscious limitation of the "Windows Simulator" feature (e.g. to conserve system resources and/or reduce user confusion) or a restriction in the "loopback Remote Desktop" mechanism itself. The OS could, for instance, limit the number of simultaneously active sessions to 2, similar to what Windows Server does with Remote Desktop set to "Administration" mode.
Two active sessions would provide the ability to interact with one isolation domain at once, while e.g. showing frozen images (last known state) of applications running in other domains (the sessions of those domains would be disconnected, just like when using fast user switching). Upon switching the foreground window to that of another domain, the session of that domain could be reconnected (and that of the previous window disconnected).
But those are all idle musings, requiring actual experiments to verify.
@anon-who-asks-about-seccomp:
Probably not, because, AFAIU, seccomp can only be used to sandbox specially prepared apps, rather than create isolated containers for running unmodified generic apps.
What should be, however, possible, and without much effort I think, is to use Linux LXC as a "hypervisor" for Qubes Odyssey. And we might even do this one day...
Pruning the application under Sandboxie will overcome most of the issues you pointed out, such as changing system preferences, inter process communication, etc.
@anon-advertising-sandboxie:
As discussed in the paper, sadboxing of a specific app is not the same a creating a container that would work out of the box for any app (which is what is the goal of Qubes).
Qubes is not about creating a tailroed sandbox for specific app -- instead it's about creating domains where you can run any app, isolated from each other.
@anon-advertising-sandboxie:
... and even if we assume we want to sandbox only a specific app, like in case of Sanboxie, but tailoring the policy for it. Still, perhaps you can explain, how does Sandboxie resolves some of the problems described in the paper, such as:
1) Protecting the Kernel Object name same against squatting attacks? E.g. the sandboxed app creates objects that will later be picked up and used by MS Office run outside of the sandbox -- as a result control of the MS Office will be taken?
2) GUI isolation?
?
It may not be an appropriate approach for your project, but have you seen the RDP reversing that was done a couple years ago that opened up the ability for multiple sessions and other hacks?
http://www.slideshare.net/alisaesage/hacking-microsoft-remote-desktop-services-for-fun-and-profit
"Pruning the application under Sandboxie will overcome most of the issues you pointed out, such as changing system preferences, inter process communication, etc."
Back in early 2011, I conducted research with the same goal and use the same techniques, such as running in a different security context, applying local/group policies, but I also ran each application under Sandboxie. Sandboxie had the ability to give a different color to each window, protect system preferences, etc. It still falls short, but what I was trying to get at is that using all of your techniques, plus Sandboxie, adds more isolation and identification of domains.
Your work does go into much more detail about the many methods of inter-process communication reguarding this topic than I've seen before.
@another-anon-who-advertisies-sandboxie-without-providing-much-tecnical-facts:
And how does Sandboxie provide the colorful frames around the sandboxed window, so that the app cannot spoof it?
@rjohnson:
Yeah, as you say, this is not an acceptable approach, because using undocumented Windows patching to enable undocumented features in a legitimate product has at least two problems:
1) It might be not legal (at least in some countries)
2) It is not reliable because MS might decide to change this undocumented code we patch anytime without warning, with a new automatic update.
borderColor=0xFF0000
What is the necessity to prevent all inter-process communication? Couldn’t two programs in different domains which require Internet access also communicate via a third party server?
Do you know of a program that can be used to test whether it is isolated? For example, run the program in two different domains and have them try to communicate via clipboard, files, registry, IPC, etc.
@anon-who-proposed-primitive-border-color-overwrite:
And what if the app decided to use a borderless window and will draw the decoration frame all by itself (pixel by pixel)?
@anon-who-asks-why-to-limit-inter-process-communication:
Inter-process communication might be a misleading term in this context -- it's really about preventing inter-process interference. Again, an MS Office app might create some (kernel) objects that would turn out to be actually owned by the sandboxed malicious app (see the paper). Being able to e.g. control a shared memory section object is quite devastating. This is, of course, completely different story, than an app exposing just some networking endpoint (which still might be dangerous, so we naturally would like to have an option to limit those too).
What about the Chrome/Chromium browser sandbox for Windows, which could be used directly:
http://www.chromium.org/developers/design-documents/sandbox
and
http://www.chromium.org/developers/design-documents/sandbox/Sandbox-FAQ
@anon-who-advicates-chromium-sandbox:
Could be used directly... for what? Did you read our paper?
Interesting article, I was wondering why limit yourselves to target Win7 retail if it causes issues? I could imagine Qubes would also have some appeal to the the pro version and server edition crowds. In a way, it is almost equivalent to targeting Xen as it was back in 2009 :)
I'd also be curious to know your opinion on the suitability of the child sessions mechanism introduced in Win8 (http://msdn.microsoft.com/en-us/library/hh769143(v=vs.85).aspx) for security isolation.
As a footnote, http://blogs.msdn.com/b/ntdebugging/archive/2007/01/04/desktop-heap-overview.aspx?PageIndex=7 might contain some useful troubleshooting documentation regarding the undisciplined behaviour of desktops and dlls in alternate winstations.
Cheers from Sydney!
@anon-from-sydney: it makes no sense to require Windows Server for Qubes WNI because then we could very well use MS Hyper-V as an isolation providers, instead of OS processes/user accounts.
And perhaps one day we will write Qubes for Hyper-V, but it will likely require consumer Windows. But this would not be called "Qubes WNI"...
Thanks for the analysis - it's no surprise that the Windows behemoth has no real plan for decent segregation, and this applies to licencing as well - there is the absurd situation that you nominally have to have multiple licences for running each VM which is only there to get around security weaknesses in the base product - how many eyes and hands do we have!
Regarding Sandboxie, I'm disappointed that this appears to have become an antagonistic scenario, whereas, having used Sandboxie and Qubes (thanks a bunch), I see them both as rather applicable in different scenarios.
Sandboxie 4 uses ANONYMOUS_LOGIN as the user (as well as restricting calls & disk & network access). Clearly less secure than Qubes (because it's vulnerable to OS subversion, but it does trap a lot of real-world malware) and app oriented - but lightweight and pretty easy to set up, far easier than things like AppArmor. Being able to wipe browser sessions reliably and easily is a good feature.
Although this hardly rates as news, Sandboxie was recently purchased by Invincea. Invincea is a DARPA funded start-up, with all of the requisite ties to various U.S. government defense agencies (NSA, DIA, etc). This may or may not affect your views about its utility as a trustworthy isolation mechanism, lol. In any event, Qubes seems like an excellent idea to the extent that the underlying hardware can be relied upon (where there can be no adequate defense, without basically giving up VLSI altogether). Good job.
So, Qubes WNI would be possible on Windows 8 Pro or Enterprise (and Windows 7 Pro, Ultimate, etc.), because Hyper-V is available ?
(technical question leaving aside eventual license problems)
Another Question, how about using the free Hyper-V Server 2012 ? (once again I know nothing of the licensing angle)
Would be interested to see whether Qubes can take advantage of Valgrind/Docker(LXC) in the future as a possible alternative or additional tool in addition to Xen. Any thoughts Joanna?
I was wondering about same thing what dragon788 already mentioned. Could you share your viewpoint/alternative ideas Joanna on LXC/Docker subject?
@dragon & anon asking about using LXC as an isolation provider -- please see this article:
http://theinvisiblethings.blogspot.com/2013/03/introducing-qubes-odyssey-framework.html
The short answer: yes, LXC might be a good option for the "poor-man's" edition of Qubes OS. Much less secure than Xen, but more than "just Linux" IMHO.
Post a Comment