Re: Is Xen affected by this x86 hardware security hole?

Re: Is Xen affected by this x86 hardware security hole?

[Mark Williamson]

> 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!

Re: Is Xen affected by this x86 hardware security hole?

[Keir Fraser]

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

RE: Is Xen affected by this x86 hardware security hole?

[Ian Pratt]

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

Isn't this what the kernel /dev/fbdev driver does? 

If you're running an fbdev Xserver you shouldn't need to give the
Xserver io or mmio permissions.

Ian

Is Xen affected by this x86 hardware security hole?

[Dave Feustel]

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/

Re: Is Xen affected by this x86 hardware security hole?

[Mark Williamson]

> > 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*
>
> Isn't this what the kernel /dev/fbdev driver does?
>
> If you're running an fbdev Xserver you shouldn't need to give the
> Xserver io or mmio permissions.

Yes, I think that's the idea behind it.  Does anyone know if it works in the 
general case, or only for specific graphics cards / specific display modes?  
I've not used it myself.

The real problem is that X servers can generally call iopl() / ioperm() and 
thus get access to stupid things.  Deprivileging the process (or preferably 
terminating the existence of those syscalls with extreme prejudice) is really 
the right fix.

That said, they can usually only call those things because they're root, and 
if they're root a root exploit doesn't seem so bad *shrug*?  Does anyone 
actually use fine grained access control for X servers in modern distros?

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!

Re: Is Xen affected by this x86 hardware security hole?

[Dave Feustel]

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"

Re: Is Xen affected by this x86 hardware security hole?

[Mark Williamson]

> 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!

Re: Is Xen affected by this x86 hardware security hole?

[Mark Williamson]

> > 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!

Re: Is Xen affected by this x86 hardware security hole?

[Dave Feustel]

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"