All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Feustel <dfeustel@mindspring.com>
To: xen-devel <xen-devel@lists.xensource.com>
Subject: Is Xen affected by this x86 hardware security hole?
Date: Tue, 02 May 2006 09:02:37 -0500	[thread overview]
Message-ID: <200605020902.37624.dfeustel@mindspring.com> (raw)

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/

             reply	other threads:[~2006-05-02 14:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-02 14:02 Dave Feustel [this message]
2006-05-02 13:10 ` Is Xen affected by this x86 hardware security hole? Mark Williamson
2006-05-02 13:25   ` Keir Fraser
2006-05-02 14:54     ` Dave Feustel
2006-05-02 15:46       ` Mark Williamson
2006-05-02 17:18         ` Dave Feustel
2006-05-02 16:08           ` Mark Williamson
  -- strict thread matches above, loose matches on Subject: below --
2006-05-02 13:54 Ian Pratt
2006-05-02 14:02 ` Mark Williamson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200605020902.37624.dfeustel@mindspring.com \
    --to=dfeustel@mindspring.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.