[Xen-devel] Is Xen affected by this x86 hardware security hole?

[Dave Feustel <dfeustel@xxxxxxxxxxxxxx>]

Is Xen affected by this newly reported x86 hardware security hole?
Can Xen eliminate this security problem in virtualized hardware?

Thanks,
Dave Feustel
=================
(Found at http://lists.freedesktop.org/archives/xorg/2006-April/014874.html)

Security issues
Duflot Loic loic.duflot at sgdn.pm.gouv.fr 
 Fri Apr 21 00:37:22 PDT 2006 
Previous message: xserver/xorg/configure.ac and VENDOR_RELEASE 
Next message: Security issues 
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] 
Hi all,

We recently crafted a proof-of-concept attack scheme on OpenBSD-based
systems that shows that with the privileges the X server is granted, it
is pretty easy (less than 10 lines of code indeed) to get to kernel
privileges. This schemes shows how an attacker with PIO privileges and
write access on the legacy video RAM range can get to kernel (ring 0
random code execution) privileges. Details can be found here:

http://www.ssi.gouv.fr/fr/sciences/fichiers/lti/cansecwest2006-duflot-paper.pdf
http://www.cansecwest.com/slides06/csw06-duflot.ppt
http://www.ssi.gouv.fr/fr/sciences/fichiers/lti/sstic2006-duflot-papier.pdf

So, basically, even though the X server appears to be running with ring
3 privileges, it can be considered to run with "kernel-like" privileges.
What our scheme proves is that the X server cannot run in userland
without it endangering the global security of the system.
This particular exploit may not be the only one of its kind. In the
course of the proof-of-concept exploit the attacker uses some
northbridge functionality to increase his privileges over the system,
but we recently found out that other PIO-configurable mechanisms could
be used for the same purpose! We would not be surprised if much more
hardware mechanisms proved to be usable for similar purposes in the future.
We find it is time to tackle the root of the problem. We cannot achieve
true security unless security critical operations (Programmed I/O
accesses for instance) are moved to kernel space.

We think the best thing to do now would be to move to a saner security
model. The X server could be for instance split in two different parts.
One of them (the one requiring PIO accesses or important privileges on
the hardware) could run in kernel mode, providing some abstraction to
the other one (the biggest one hopefully) remaining in userspace. The
part remaining in userspace would thus no longer require any particular
privilege.

Please be aware that this is not an OpenBSD-specific matter. Other
systems have no protection at all against the attack scheme we display.

We think it is a very urgent matter for true security will never be
achieved otherwise. For the time being the only advice we could give to
OpenBSD users who want their system to be secure is not to use the X
server. Everybody should work together on this to improve the global
security of IT systems.

Loïc

------------------------
Loïc Duflot
SGDN/DCSSI/SDS
http://www.ssi.gouv.fr/

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