Re: X11 -> Root? (Qubes square rooted)

[Brad Spengler <spender () grsecurity net>]

Hello list for lions,

Grab yourself your beverage of choice and some anticipatory popcorn;
this will take a while.

So every year or so we get some overly confident zealot shot down on DD
(any SELinux zealots still out there?)  Going with the tide of
security, this year's program seems to center around a new topic:
virtualization, particularly from the person who brought us the only
100% undetectable (*) rootkit.  The internet hype machine seems to be in
full swing already (I think that's what Joanna's in charge of now, since
Rafal is the only one writing papers, no offence to him in any of the
below BTW) so hopefully this will provide some grounding for those of us
who know better.
* 100% detectable you say?  Sorry, I can't hear your arguments when my
fingers are secured firmly in my ears and your voice is drowned out by
the din of my own self-congratulation.

The PaX Team and I tried to dissect some claims made by Joanna (link in
the parent post) until she began selectively moderating the posts,
while of course still allowing her personal attacks and hype/hand-waving
through.  I have to say this: regardless of the level of disagreement
between us and Red Hat/SELinux/Linux/anyone else, not once have we ever
been censored this way.  So unlike Joanna, since we don't have a
hand-waving marketing blog of our own disguising itself as some
technical resource and we can't post on her blog about how it's
censored, we thought we'd bring you the posts Joanna chose to
moderate (it should be clear why) and a deconstruction of Qubes.

First the personal attacks:

My reply below was moderated.  Obviously mentioning in her post (as
Rafal did in his paper) that there was an actual concrete bug being
abused here that was already known and published five years ago isn't
as effective at ramping up the internet hype machine.  So Joanna chose
the more mysterious and false claim that "it doesn't exploit any
concrete bug, which makes it so much more interesting."

The bug was the Linux kernel allowing the stack to
expand into an adjacent mapping, such that the stack pointer could then
point into the adjacent mapping and modify data within it.  This
property made a host of other exploits possible as well, as mentioned in
http://grsecurity.net/~spender/64bit_dos.c (still awaiting CVEs and a
fix for the latter issue BTW).  Furthermore, this bug in Linux was
publicized in 2005 by Gael Delalleau (see slides 8, 11, 15, etc of
http://cansecwest.com/core05/memory_vulns_delalleau.pdf),
so the only discovery here was finding one (of several) applications that
happen to be exploitable due to this bug.
For the sake of completeness, a fix was proposed before this
presentation in 2004 by Andrea Archangeli, see:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-09/7904.html
and was discussed in various other places at the time:
http://lwn.net/Articles/93078/

With this context, on to what was posted:
Joanna posted to me: "Is re-discovering somebody's else findings your
speciality? :)"

The post in reply was:
> Regarding rediscovering someone else's work, I'd have to defer to you
> guys on that on your rediscovery of Gael's 2005 publication.  Rafal was
> kind enough to mention it in his paper, though any mention of it was
> unsurprisingly absent from your marketing post.

> And again we have, the way to deal with the problem is to ignore it.
> Sorry, "dealing with" the problem of compromised bookmark storage
> turning into full system rootkits by keeping people from storing
> bookmarks is no solution.

> "Everything that happens inside the VM is beyond the Qubes security
> model."
> Indeed, 90% of what actual security deals with that desktop users care
> about is beyond the Qubes security model."

She also decided to selectively moderate half of a post by the PaX Team.
The censored continuation of his final post was the following:

> > In Qubes architecture we don't care
> > whether the attacker has "just" user
> > privileges, or full root privileges
> > in the AppVM -- because there is no
> > gain for the attacker in having root
> > over having "just" user.

> in other words, AppVMs can do with a single root account. is that the
> case? if not, why? beware, you cannot use anything security related to
> justify having non-root accounts as well ;).

> > but Xen has been designed with the
> > assumption that it should withstand
> > attacks from fully compromised (root-ed) VMs.

> that's not true, like most existing operating systems, Xen hasn't been
> designed to withstand attacks, in fact it has few if any self-protection
> features (ask yourself the simple question: if you have a bug in the
> hypervisor that gives you arbitrary read/write access to its memory, is
> there anything you cannot achieve then?). what it was designed for is to
> provide a certain amount of isolation between different domU's.

Even after giving herself the last word and declaring the end of the
thread (after censoring our posts) she couldn't help herself but to
allow this additional post through:

> > If you think Qubes architecture is
> > buggy, feel free to write some proof of
> > concepts to back up your opinion

> Hehe, in order to prove that Xen is indeed just as buggy as Linux
> kernel, The PaX Team or Spengler would have to write *lots* of exploits
> for Quebes, I guess ;)

Bravo, pure class demonstrated: the kind we've grown to expect.

On to Qubes:

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.

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!

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").

It's quite reminiscent really of Joanna's defense against her 100%
undetectable rootkit.  Regardless of whatever detection method was
proposed, some imaginary hand-waving scenario would be proposed that
would magically defeat the detection (ignoring of course any actual
implementation details and the effects of such additional logic).

In the introduction of the Qubes architecture document (section 1.1),
Joanna introduces a false security dichotomy by ignoring any security
improvements/approaches (like the ones they're oblivious to based
on the amusingly incorrect contents of section 3.3 "Anti-exploitation
mechanisms in the hypervisor") and focusing on vendors patching individual
vulnerabilities, leaving the only solution being (surprise) her
solution, a new OS.  I know this is difficult for a "rockstar wannabe"
to grasp, but there are many difficult problems in security.  They're
not insurmountable, but they take a lot of time and hard work to deal
with.  Not all of us can ignore the real security problems we face and
instead deal with some far removed set of problems with a couple
thousand lines of Python and act as if we accomplished something great.

To usher in this newfound age of security, I call for all of you
to start developing all your code under disposable AppVMs in Qubes.
Save early and often, because I have a feeling you might lose your data
at some point...  You'll have to find some way to do proper performance
testing too, something about performance counters and MSR bitmaps.

BTW, a personal invitation to Joanna:  if you believe in Qubes as much
as your 100% undetectable rootkit, the PaX Team and I give you the same
offer we would give to any SELinux zealot; put your most personal,
valuable information in an AppVM, and give the world separate access to
an AppVM with root ssh access enabled and outbound connections
disallowed (since root doesn't matter, after all).  In other words, put
something other than hype where your mouth is.

Most cordially,
-Brad

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave