All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rafal Wojtczuk <rafal@invisiblethingslab.com>
To: Vasiliy Baranov <vasiliy.baranov@gmail.com>
Cc: xen-devel@lists.xensource.com, joanna@invisiblethingslab.com
Subject: Re: Paper: Adventures with a certain Xen vulnerability
Date: Fri, 14 Nov 2008 17:41:20 +0100	[thread overview]
Message-ID: <20081114164120.GF7653@emperor2.itldev.org> (raw)
In-Reply-To: <e4a2b0250811140646p2d726b9cu77fc923472df6dfd@mail.gmail.com>

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

  reply	other threads:[~2008-11-14 16:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-14 14:46 Paper: Adventures with a certain Xen vulnerability Vasiliy Baranov
2008-11-14 16:41 ` Rafal Wojtczuk [this message]
2008-11-14 18:21   ` Vasiliy Baranov
  -- strict thread matches above, loose matches on Subject: below --
2008-10-15 13:21 Joanna Rutkowska

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=20081114164120.GF7653@emperor2.itldev.org \
    --to=rafal@invisiblethingslab.com \
    --cc=joanna@invisiblethingslab.com \
    --cc=vasiliy.baranov@gmail.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.