This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] Is Xen affected by this x86 hardware security hole?
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Tue, 2 May 2006 14:10:21 +0100
Cc: Dave Feustel <dfeustel@xxxxxxxxxxxxxx>
Delivery-date: Tue, 02 May 2006 06:13:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <200605020902.37624.dfeustel@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <200605020902.37624.dfeustel@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.1
> Is Xen affected by this newly reported x86 hardware security hole?

It's not so much x86's fault (does anyone ever expect to say that?!) as a 
software problem.  It's not really a new problem, I've heard of it grounched 
about before.  Hopefully OpenBSD folks might lend some muscle and help get 
this fixed.

X servers for various historic reasons have been given huge amounts of 
privilege to access hardware directly in unpleasant ways.  Since they can do 
this, they can in principle go and drive (pretty much) any hardware in your 
system (if they wanted to!) and use it for whatever they want.  They can also 
trivially disable interrupts and hang your system.  Yuk.

A better solution would be to have a kernel module that provides services to 
the X server, but this would require more code per platform, which is partly 
why it wasn't done like this...  *sigh*

The consequences for Xen:
* X running in dom0 can, in principle, subvert any domain you're running, if X 
itself gets subverted.  A bug in X in dom0 could hang the machine in 
* X in a domU can't get to the really hardware and so it can't subvert 
anything outside the domain.  It might be able to subvert the contents of the 
domain, depending on your setup.
* Xvnc, and friends, don't need hardware access at all - they can be run 
unprivileged and eliminate this risk of this particular class of attack.


> 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
> http://www.ssi.gouv.fr/
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

Xen-devel mailing list