Xen devel - Oct 2008 - Paper: Adventures with a certain Xen vulnerability

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


	       Invisible Things Lab is proud to present:


  "Adventures with a certain Xen vulnerability (in the PVFB backend)"

				   by

			     Rafal Wojtczuk


				  ***

				Starring

Xen  3.2.0,  DomU  (an	ordinary  virtual   machine,   paravirtualized),
Dom0  (privileged  administrative  domain)  running  on  FC8  with   NX,
ASLR and SELinux enabled, The Evil Hacker, and a  certain  vulnerability
in  the Frame Buffer backend.

				  Plot

The Evil Hacker escapes from DomU and  gets  into  Dom0.   Using  clever
ret-into-libc technique he succeeds with his attack on x86 architecture,
despite the NX and ASLR deployed in Dom0 OS (Fedora Core 8).   The  Evil
Hacker	is  also  not  discouraged  by	the   fact   that   the   target
OS has SELinux protection enabled - he demonstrates how  the  particular
SELinux policy for Xen,  used  by  default  on	FC8,  can  be  bypassed.
Ultimately he gets full root  access  in  Dom0.   Rafal  also  discusses
variation of the exploitation on  x86_64  architecture	-  he  partially
succeeds, but his x64 exploit doesn''t  work  in  certain 
circumstances.

				  ***

Curious individuals can get the full paper here:

http://invisiblethingslab.com/pub/xenfb-adventures-10.pdf

				  ***

This paper is one of the outcomes of a broader	research  into	Xen  and
virtualization	 security    sponsored	  by	Phoenix    Technologies.

				  ***

This paper is also a teaser for  our  upcoming	Virtualization	Security
Training, that is scheduled  for  Spring  2009.   Stay	tuned  for  more
details.

				  ***

Sincerely,

Joanna Rutkowska
CEO (and Head of PR:)
Invisible Things Lab
http://invisiblethingslab.com/

-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkj17nAACgkQORdkotfEW87AyACgmUTikRl2+tccYINOaGkLT+zJ
XbQAoKE0RVf9aQdlsrgc5kulIWLv5cdd
=AVVP
-----END PGP SIGNATURE-----

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

Hi Joanna,

I have a question about the exploitability of the issue described in this
paper http://invisiblethingslab.com/pub/xenfb-adventures-10.pdf (link found
in http://lists.xensource.com/archives/html/xen-devel/2008-10/msg00411.html
).

Would exploit be possible if domU were booted with a dom0-supplied kernel
(that is, by specifying the kernel in dom0 config rather than via pygrub),
which domU would not be able to modify? That is, could the problem be
exploited by only playing with domU modules and rebooting the system without
modifying the kernel? And what if the dom0-supplied kernel did not allow
domU to load any modules?

Asking this as part of a more general discussion taking place here:
http://lists.xensource.com/archives/html/xen-users/2008-11/msg00102.html

I have yet to learn a lot about kernels and modules so sorry if my questions
do not make any sense.

Thank you in advance,
Vasiliy


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

On Fri, Nov 14, 2008 at 05:46:28PM +0300, Vasiliy Baranov
wrote:
> I have a question about the exploitability of the issue described in this
> paper http://invisiblethingslab.com/pub/xenfb-adventures-10.pdf (link found
> in http://lists.xensource.com/archives/html/xen-devel/2008-10/msg00411.html
> ).
> 
> Would exploit be possible if domU were booted with a dom0-supplied kernel
> (that is, by specifying the kernel in dom0 config rather than via pygrub),
> which domU would not be able to modify? That is, could the problem be
> exploited by only playing with domU modules and rebooting the system
without
> modifying the kernel? 
No (in all sane configurations). In case of xen-3.2.0 (the vulnerable
version), domU could pass the framebuffer dimensions to the backend only once 
throughout the domain''s lifetime. Usually the domU kernel (if it has
PVFB
support) does it during its early boot phase; therefore an attacker cannot do 
it after the kernel has booted.
> And what if the dom0-supplied kernel did not allow
> domU to load any modules?
If you intend to disallow arbitrary kernel mode execution in domU, you
should also take care of other methods to run kernel mode code, e.g.
a) modifying kernel memory by /dev/mem or /dev/kmem
b) exploiting buffer overflows (reachable by uid 0) in domU kernel
c) other scenarios
It is easy to prevent a). The case b) is difficult. I suspect a determined
attacker can find such an overflow quite easily. Finally c); uid 0 has many
ways to interact with its kernel, there may be other ways to achieve
arbitrary kernel mode execution.
 
> Asking this as part of a more general discussion taking place here:
> http://lists.xensource.com/archives/html/xen-users/2008-11/msg00102.html
Generally, disallowing domU users to run arbitrary kernel code is a good  
idea: it significantly limits the possible ways to interact with backends
and hypervisor, which in turn makes it much harder to exploit any bug in them.
Of course, backends and hypervisor are designed to be immune to any
exploitation attempt by domU, but the actual implementation may contain 
vulnerabilities (as we have already seen a couple of times).

Regards,
Rafal Wojtczuk
Principal Researcher
Invisible Things Lab

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

On Fri, Nov 14, 2008 at 7:41 PM, Rafal Wojtczuk <
rafal@invisiblethingslab.com> wrote:
> On Fri, Nov 14, 2008 at 05:46:28PM +0300, Vasiliy Baranov wrote:
> > I have a question about the exploitability of the issue described in
this
> > paper http://invisiblethingslab.com/pub/xenfb-adventures-10.pdf (link
> found
> > in
> http://lists.xensource.com/archives/html/xen-devel/2008-10/msg00411.html
> > ).
> >
> > Would exploit be possible if domU were booted with a dom0-supplied
kernel
> > (that is, by specifying the kernel in dom0 config rather than via
> pygrub),
> > which domU would not be able to modify? That is, could the problem be
> > exploited by only playing with domU modules and rebooting the system
> without
> > modifying the kernel?
> No (in all sane configurations). In case of xen-3.2.0 (the vulnerable
> version), domU could pass the framebuffer dimensions to the backend only
> once
> throughout the domain''s lifetime. Usually the domU kernel (if it
has PVFB
> support) does it during its early boot phase; therefore an attacker cannot
> do
> it after the kernel has booted.
>
> > And what if the dom0-supplied kernel did not allow
> > domU to load any modules?
> If you intend to disallow arbitrary kernel mode execution in domU, you
> should also take care of other methods to run kernel mode code, e.g.
> a) modifying kernel memory by /dev/mem or /dev/kmem
> b) exploiting buffer overflows (reachable by uid 0) in domU kernel
> c) other scenarios
> It is easy to prevent a). The case b) is difficult. I suspect a determined
> attacker can find such an overflow quite easily. Finally c); uid 0 has many
> ways to interact with its kernel, there may be other ways to achieve
> arbitrary kernel mode execution.
>
> > Asking this as part of a more general discussion taking place here:
> >
http://lists.xensource.com/archives/html/xen-users/2008-11/msg00102.html
> Generally, disallowing domU users to run arbitrary kernel code is a good
> idea: it significantly limits the possible ways to interact with backends
> and hypervisor, which in turn makes it much harder to exploit any bug in
> them.
> Of course, backends and hypervisor are designed to be immune to any
> exploitation attempt by domU, but the actual implementation may contain
> vulnerabilities (as we have already seen a couple of times).
>
Rafal,

Thank you very much. This really helps. Well, in my case disallowing users
to have root access and load custom modules in domU is out of question. If I
understand you correctly, it means that in my situation disallowing
untrusted kernels is not going to buy me much, so I better rely on Xen and
you guys doing your tremendous work.

Thank you,
Vasiliy


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