Brad Spengler’s criticism of Qubes OS from 16 years ago. Is there a response to it and does his writings have any points that applies to Qubes OS 16 years later?
Basically, the Qubes TCB cannot simply be the hypervisor, because the
hypervisor itself is not capable of the kind of information flow control
between VMs Qubes needs to provide security for user data.
As mentioned in the comments that were allowed through, the hypervisor
self-protection problem hasn't been solved; the assumption from the
architecture document being this will be done in the future (tm). Like
I mentioned in my comments, this will require some real work, especially
if Joanna's seen the relevant academic work in this area.
Is it done 16 years later? I assume?
From the below HyperSafe (2010) paper:
"A recent study of the National Vulnerability Database [33] indicates
that in the last three years, there were 26 security vulnerabilities
identified in Xen"
HyperSafe aims to provide hypervisor self-protection through page
table lockdown, proper page protections, and restricted pointer
indexing (replacing traditional call/jmp/ret use). The restricted
pointer indexing requires a modified compiler for static determination
of call/jmp/ret targets. Hypersafe implemented all this for the
BitVizor hypervisor, though only the page lockdown for Xen (because
they're unable to get Xen to compile with their modified compiler).
The 5% performance hit for all of it (on top of the hypervisor hit) in
the BitVizor case is in the acceptable range, though there are no
performance statistics for Xen. Not much to complain about here
(other than not properly crediting prior work), though the "powerful
synthetic attacks" in IV.B are an amusing read:
http://people.csail.mit.edu/costan/readings/oakland_papers/hypersafe.pdf
Want to protect guest kernels with that fancy hypervisor of yours
though, like a secure OS would? Currently SecVisor does this, with
100% performance hit for a kernel compile; good luck getting anyone
to use that. And that's just for the hypervisor to protect the
guest kernel code in a limited way ("ROP", other alterations of code
flow (eg. via data modification) still perfectly possible, see Section 8 of:
http://www.sosp2007.org/papers/sosp079-seshadri.pdf)
BTW, by using Xen, people are prevented from having any significant
guest kernel self-protection unless it's implemented by the
hypervisor.
Currently all that exists is a "sandbox" designed to prevent the kind
of unrealistic attacks/rootkits we've seen from the same people, where
the attack surface has just been shifted to the hypervisor and
other associated privileged code. I use the term sandbox loosely
because Qubes is a departure from the standard sandbox, as it sandboxes
by basically giving up on all the problems traditional sandboxes deal
with and relying on the strength of virtualization and some python
scripts to attempt isolation, not of applications (unless you run only
one process in each AppVM), but of the entire guest OSes. While other
sandbox approaches would actually care about a sandboxed mail reader
being able to exfiltrate your mailspool, under the weakened protection
model of Qubes, this is acceptable. Assuming it makes the problem go
away!
What are unrealistic attacks/rootkits he is talking about?
Other notes: X runs in dom0, vulns in the NVIDIA drivers have been
remotely exploitable, and for performance reasons there's a tendency to
pass through more directly to the hardware. From a malicious website,
browsed in a sandboxed browser, inside a VM, you can *still* exploit
the NVIDIA driver on the *host*.
Your personal email will still get owned, your personal browsing history
will get owned, and unless you maintain no state for any of these
associated VMs (no saving bookmarks, no saving emails, no saving
anything parsed by an application) you're all set for persistent
compromise until you completely wipe out the VM. All while maintaining
the naive assumption that the attackers the architecture was built for
(count on both hands how many times your BIOS, network card, or SMM has
been owned) don't have VM breakout exploits for a completely unprotected
hypervisor. And of course, distro/upstream backdoors that get shared
among all of your AppVMs are impossible.
So the secure solution is to give each application its own OS and VM,
never use your computer as normal people use them (by saving all kinds
of state), ensure that your own interfacing with the color-coded
separation is flawless, magically know with no false-negatives that
anything transferred between VMs isn't trojaned in some way (AV
companies would surely love to know how you figured that one out!) and
then at the end of it all, when everything you care about still gets
owned, what have we solved exactly?
More importantly, Qubes presents itself as a "secure operating system"
without providing most of the things one would expect from a secure
operating system (not having your mail spool stolen, for instance).
There's really no formal definition of what Qubes is supposed to be in
the architecture document, other than that it aims to be a "secure
operating system" that tries to protect user data, sortof, in the ways
that it wants to "protect" it. It's a clever little device to be so
vague as to resist definition, since it makes attacks on it akin to
trying to come up with a definition of 'Art'.
The difficulty in properly assessing Qubes is that much of its
protection exists only on paper. So if you point out some deficiency,
one can just point to the architecture document as if that were some
kind of actual solution that would be possible to implement with
acceptable performance and resource usage. Or one can point to some
hardware that's 10 years away from the general public using it, if ever.
I really encourage people to actually read the architecture document,
because Joanna likes referring to it so much as if anything you bring up
is a solved problem. When you actually read what she's referring to as
the solution, you realize they've essentially ignored the problem or
offered some hypothetical potential solution that can't be applied in a
generic sense (and then it's not the fault of the system, but rather
the user, if the user fails to apply the compltely unrealistic
"solution").
16 years later we have such hardware or no?