[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1403012214.16844.111.camel@kazak.uk.xensource.com>
Date: Tue, 17 Jun 2014 14:36:54 +0100
From: Ian Campbell <Ian.Campbell@...rix.com>
To: Andres Lagar Cavilla <andres@...arcavilla.org>
CC: <xen-devel@...ts.xen.org>, <security@....org>,
<xen-announce@...ts.xen.org>, <oss-security@...ts.openwall.com>
Subject: Re: Xen Security Advisory 99 - unexpected pitfall in xenaccess API
On Tue, 2014-06-17 at 06:13 -0700, Andres Lagar Cavilla wrote:
> But fundamentally, how is this a vulnerability? Since the dawn of time
> guests can poke at the qemu and PV frontend rings. So self DoS, check.
> But, privilege escalation?
PV frontend rings have an endpoint in the guest, but by contrast the
xenaccess ring is supposed to have its endpoint in Xen, having a guest
able to poke at it therefore requires additional consideration and
thought.
> Is this predicated on the potential (lack of) software quality of the
> xenaccess backends? That's a fair argument, but a different story.
An attacker who can poke at this particular ring can cause the xenaccess
backend's view of the world to become different from the actual state of
things within Xen, by virtue of injecting events for which Xen has not
made the appropriate state change.
For instance imagine a xenaccess who was trying to enforce W^X but was
being fed false information by the guest about writing/executing pages
which did not correspond to actual changes being made in the p2m.
For qemu there is no Xen side state, so all a guest can do with ring
access here is to perform emulated I/O which it could otherwise have
achieved by doing the I/O.
Ian.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
