[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CADzFZPu1JdVbCmbBbib8Y0s4Drpt9cRuqkcQTDazhfRweHS=jg@mail.gmail.com>
Date: Tue, 17 Jun 2014 06:50:01 -0700
From: Andres Lagar Cavilla <andres@...arcavilla.org>
To: Ian Campbell <Ian.Campbell@...rix.com>
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, Jun 17, 2014 at 6:36 AM, Ian Campbell <Ian.Campbell@...rix.com>
wrote:
> 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.
>
Correct. So (1) Xen's handling of events won't change (2) the dom0 helper's
view will.
So the bottomline question is how can a guest inject an event for a dom0
helper which will cause privilege escalation.
Such a helper would be (1) terribly designed (2) unduly powerful.
>
> 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.
>
W^X is enforced by Xen and it won't be swayed by guest ring manipulation.
The helper would have been thrown off balance, and failed to audit
something at worst. Maybe this means a security problem down the line for
that helper toolchain, but outside the purview of the hypervisor.
One path that is not obvious is how would Xen react if the guest corrupts
the ring in a way that makes it look full. The intended behavior is for Xen
to put the guest vcpu in a wait/queue (or kill the guest). So that the
damage at most might be self-DoS.
I see how helpers may be thrown totally off balance. I see self-DoS, but
still do not see privilege escalation happening.
>
> 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.
>
Correct, my bad.
Thanks
Andres
>
> 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.
