Xen devel - Sep 2008 - [Fwd: Xen 3.4 feature request (security)]

From: Joanna Rutkowska <joanna@invisiblethingslab.com>
Organization: Invisible Things Lab
 

Hello,

On behalf of the Invisible Things Lab team I propose addition of the
following security features/changes into Xen 3.4 roadmap:

1) No self-modifying code in the hypervisor.

Currently there is at least one place where the hypervisor builds a
trampoline
that is later executed (emulate_privileged_op() which builds a "stub"
on
the
stack for I/O emulation). Such approach has not only a problem of being
inelegant and potentially dangerous, the bigger problem is that it makes
runtime
verification of the hypervisor code integrity more difficult.

2) Strict application of the NX/XD bit in the hypervisor.

Every page that doesn''t contain code should be marked as
non-executable.
Currently this is not the case, as e.g. the Xen''s heap is executable.
There
should be no pages that contain both the code and data. Strict NX
application
would not only make the exploitation of bugs in the hypervisor harder
(as e.g.
the FLASK overflow that we exploited during Black Hat last month [1]),
but would
also allow to create much simpler and more effective runtime integrity
scanners
for the hypervisor (see our Black Hat slides about the HyperGuard
project done
together with Phoenix [2]).

3) Make the Xen system more auditable. Currently the Xen hypervisor does
not
expose several important information about the system. For example the
"xm list"
command (and the underlying hypercall) do not present an information
whether
each domain is privileged or not. As a consequence it is possible for an
attacker, that got access to the hypervisor, to set the privileged bit
for one
of the DomUs, allowing it to e.g. map memory at will from other domains
to his
or her domain (See [3] for details of a practical implementation of such
backdoor).

With current Xen implementation such Xen compromise would be
undetectable. We
believe such scenario could be used e.g. in the hosting scenarios, where
various
domains are rented to different customers. During one of our Black Hat
presentation we have presented a rootkit that does just that. Note that
such
rootkit doesn''t require modifications of any code in the hypervisor,
nor
adding
any new code, just setting the is_privileged flag for some domain. Thus
if we
imagined a runtime hypervisor integrity scanner, like the mentioned
above
HyperGuard, it would still not detect the system compromise.

To make this auditing complete, the hypervisor should also expose a set
of MFNs
that a given domain effectively is allowed to use (so, the set
containing any
MFN that is present in any page table that the domain can set as its
current
page table). This is to address a more complex variation of the
compromise
described above where, instead of privileging a domain, the attacker
simply maps
some MFN to the domain, e.g. by manually modifying the page tables
inside the
hypervisor.

We would be happy to answer/discuss any questions/doubts you might have
regarding the above propositions.

Regards,
Joanna Rutkowska
Invisible Things Lab, CEO
http://invisiblethingslab.com/

[1]
http://theinvisiblethings.blogspot.com/2008/08/our-xen-0wning-trilogy-hi
ghlights.html

[2] http://invisiblethingslab.com/bh08/part2.pdf

[3] http://invisiblethingslab.com/bh08/part1.pdf
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjFivoACgkQORdkotfEW84ZmgCfWRrndQHxJSPDd3lxfLaVZJO5
lasAoOUjMWNkZZEGsw2he/06BZfY1/B9
=uHhh
-----END PGP SIGNATURE-----

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Stephen Spector writes ("[Xen-devel] [Fwd: Xen 3.4 feature request
(security)]"):
> On behalf of the Invisible Things Lab team I propose addition of the
> following security features/changes into Xen 3.4 roadmap:
Thanks for your suggestions.  The right route for these kind of
suggestions is design and code contributions via xen-devel mailing
list (CC''d).

I can''t comment on the design issues with all of these items, but for
example ...
> 3) Make the Xen system more auditable. Currently the Xen hypervisor
> does not expose several important information about the system. For
> example the "xm list" command (and the underlying hypercall) do
not
> present an information whether each domain is privileged or not. [...]
... I''m sure we would welcome patches to improve this.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> On behalf of the Invisible Things Lab team I propose addition of the
> following security features/changes into Xen 3.4 roadmap:
Joanna,

Thanks very much for your input, it''s much appreciated.
> 1) No self-modifying code in the hypervisor.
> 
> Currently there is at least one place where the hypervisor builds a
> trampoline that is later executed (emulate_privileged_op() which
builds a "stub"
> on the stack for I/O emulation). Such approach has not only a problem
of being
> inelegant and potentially dangerous, the bigger problem is that it
> makes runtime verification of the hypervisor code integrity more
difficult.

Unfortunately its reasonably tricky to do anything else as the emulated
instruction needs to be executed with the contents of all registers set
up as per the guest code in case the instruction is actually a
communication with SMM.

I guess it''s only a small subset of instructions that (by convention)
need that level of emulation, so we could create static code stubs for
this purpose. 
> 2) Strict application of the NX/XD bit in the hypervisor.
> 
> Every page that doesn''t contain code should be marked as non-
> executable.
> Currently this is not the case, as e.g. the Xen''s heap is
executable.
> There should be no pages that contain both the code and data. Strict
NX
> application would not only make the exploitation of bugs in the
hypervisor harder
> (as e.g. the FLASK overflow that we exploited during Black Hat last
month [1]),
> but would also allow to create much simpler and more effective runtime
integrity
> scanners for the hypervisor (see our Black Hat slides about the
HyperGuard
> project done together with Phoenix [2]).
Yep, makes sense to tighten this up.
> 3) Make the Xen system more auditable. Currently the Xen hypervisor
> does not expose several important information about the system. For
example the
> "xm list" command (and the underlying hypercall) do not present
an
information
> whether each domain is privileged or not. As a consequence it is
possible for
> an attacker, that got access to the hypervisor, to set the privileged
bit
> for one  of the DomUs, allowing it to e.g. map memory at will from
other domains
> to his or her domain (See [3] for details of a practical
implementation of
> such backdoor).
Yep, it certainly makes sense to expose the capability set each guest
has, and have an extended mode of "xm list" to display it.
> To make this auditing complete, the hypervisor should also expose a
set
> of MFNs that a given domain effectively is allowed to use (so, the set
> containing any MFN that is present in any page table that the domain
can set as its
> current page table). This is to address a more complex variation of
the
> compromise described above where, instead of privileging a domain, the
attacker
> simply maps some MFN to the domain, e.g. by manually modifying the
page tables
> inside the hypervisor.
There are existing hypercalls to retrieve the MFN list, and it would be
possible to write a user space audit tool.

Actually, for debug purposes Xen already has fairly sophisticated (but
slow) memory audit routines. In debug builds its possible to trigger
these via a hypercall (or even ''xm''). It can spot pages that
are shared
and print out info on them. 
> We would be happy to answer/discuss any questions/doubts you might
have
> regarding the above propositions.
Thanks,
Ian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel