Xen devel - May 2006 - Is Xen affected by this x86 hardware security hole?

> 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 
principle.
* 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.

Cheers,
Mark
> 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@lists.xensource.com
> 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
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 2 May 2006, at 14:10, Mark Williamson wrote:
> * 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
> principle.
Yes, although you are a little better off on Xen -- for example iopl==3 
doesn''t let you disable interrupts, as it does on native. However, the 
X server will still have access to most I/O ports and can certainly 
wreak havoc because of that.

For this specific problem, it would make sense to ensure that D_LCK is 
set during boot, so that noone can thereafter modify the SMM memory 
space. You need to know something about PCI space to do that, though, 
so it would make sense for us to leave that to domain0.

  -- Keir


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

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@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tuesday 02 May 2006 08:25, Keir Fraser wrote:
> 
> On 2 May 2006, at 14:10, Mark Williamson wrote:
> 
> > * 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
> > principle.
> 
> Yes, although you are a little better off on Xen -- for example iopl==3 
> doesn''t let you disable interrupts, as it does on native. However,
the
> X server will still have access to most I/O ports and can certainly 
> wreak havoc because of that.
> 
> For this specific problem, it would make sense to ensure that D_LCK is 
> set during boot, so that noone can thereafter modify the SMM memory 
> space. You need to know something about PCI space to do that, though, 
> so it would make sense for us to leave that to domain0.
> 
>   -- Keir
Thanks for the resonses.

For those interested in the gory details of a proof-of-concept exploit,
it''s all laid out in the 16-page pdf by Loic Duflot:

http://www.ssi.gouv.fr/fr/sciences/fichiers/lti/cansecwest2006-duflot-paper.pdf 

-- 
Lose, v., experience a loss, get rid of, "lose the weight"
Loose, adj., not tight, let go, free, "loose clothing"

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

> Thanks for the resonses.
>
> For those interested in the gory details of a proof-of-concept exploit,
> it''s all laid out in the 16-page pdf by Loic Duflot:
>
> http://www.ssi.gouv.fr/fr/sciences/fichiers/lti/cansecwest2006-duflot-paper
>.pdf
Ah, interesting.

It turns out this exploit is something new, in that it''s not something
I''d
heard of before.  But it looks mostly interesting to OpenBSD.  Why?  Because 
OpenBSD has more sane controls on the X Server than Linux, and so the fact 
that it can elevate privileges is worrysome.  Since on Linux it (often) runs 
with superuser privileges anyhow, this attack isn''t the main problem...

Their exploit *does* show that mmap of the video ram, combined with the 
ability to access IO port 0xB2 is enough for a root exploit...  I don''t
know
if fbdev is restrictive enough to prevent this - OBSD have obviously tried to 
minimise X11''s privileges and still found it circumventable.

Nevertheless, Xen offers confinement.  Also, as Keir pointed out, there are 
stricter restrictions on what even dom0 can do (and these can be made even 
more strict).

Cheers,
Mark

-- 
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
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > Nevertheless, Xen offers confinement.  Also, as Keir pointed out,
there
> > are stricter restrictions on what even dom0 can do (and these can be
made
> > even more strict).
> >
> > Cheers,
> > Mark
>
> If it turns out that Xen has the capability to prevent this exploit in
> virtualized operating systems, that capability could become a big
> inducement to use Xen all the time - certainly in my case.
Well, I think Keir was meaning we could even prevent it in dom0.

You could disable writes to SMRAM in a domU, in principle.  The question would 
be whether there are legitimate uses that would be compromised by this.  For 
a locked-down machine, perhaps not.  I''m a bit fuzzy on the voodoo of
SMM ;-)

You could also (again, in principle) report attempted writes to this area of 
memory to the system administrator so you could detect a possible attack.

Cheers,
Mark

-- 
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
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tuesday 02 May 2006 10:46, Mark Williamson wrote:
> > Thanks for the resonses.
> >
> > For those interested in the gory details of a proof-of-concept
exploit,
> > it''s all laid out in the 16-page pdf by Loic Duflot:
> >
> >
http://www.ssi.gouv.fr/fr/sciences/fichiers/lti/cansecwest2006-duflot-paper
> >.pdf
> 
> Ah, interesting.
> 
> It turns out this exploit is something new, in that it''s not
something I''d
> heard of before.  But it looks mostly interesting to OpenBSD.  Why? 
Because
> OpenBSD has more sane controls on the X Server than Linux, and so the fact 
> that it can elevate privileges is worrysome.  Since on Linux it (often)
runs
> with superuser privileges anyhow, this attack isn''t the main
problem...
> 
> Their exploit *does* show that mmap of the video ram, combined with the 
> ability to access IO port 0xB2 is enough for a root exploit...  I
don''t know
> if fbdev is restrictive enough to prevent this - OBSD have obviously tried
to
> minimise X11''s privileges and still found it circumventable.
> 
> Nevertheless, Xen offers confinement.  Also, as Keir pointed out, there are
> stricter restrictions on what even dom0 can do (and these can be made even 
> more strict).
> 
> Cheers,
> Mark
If it turns out that Xen has the capability to prevent this exploit in
virtualized operating systems,
that capability could become a big inducement to use Xen all the time -
certainly in my case.

-- 
Lose, v., experience a loss, get rid of, "lose the weight"
Loose, adj., not tight, let go, free, "loose clothing"

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