[Xen-devel] Re: Paper: Adventures with a certain Xen vulnerability

["Vasiliy Baranov" <vasiliy.baranov@xxxxxxxxx>]

On Fri, Nov 14, 2008 at 7:41 PM, Rafal Wojtczuk <rafal@xxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel