oss-security - Xen Security Advisory 99 - unexpected pitfall in xenaccess API

Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADzFZPtHf7jJGpiLa9vf9oM4-sf3t8z+TqK9_vxXKwqg_f4YVw@mail.gmail.com>
Date: Tue, 17 Jun 2014 06:13:53 -0700
From: Andres Lagar Cavilla <andres@...arcavilla.org>
To: xen-devel@...ts.xen.org, security@....org, xen-announce@...ts.xen.org, 
	oss-security@...ts.openwall.com
Subject: Xen Security Advisory 99 - unexpected pitfall in xenaccess API

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>                     Xen Security Advisory XSA-99
>                              version 2
>
>                  unexpected pitfall in xenaccess API
>
> UPDATES IN VERSION 2
> ====================
>
> Public Release.
>
> Added note regarding CVE.
>
> ISSUE DESCRIPTION
> =================
>
> A test/example program, for exercising the Xen memaccess API, does not
> take all necessary precautions against hostile guest behaviour.
>
> As a result, software developers using it as an example or template
> might have written and deployed vulnerable code.
>
How?

I've looked at the patch. It's the refactor proposed in a separate thread
by Dushyant Behl, lifted up a level. Obviously useful, +2.

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?

Is this predicated on the potential (lack of) software quality of the
xenaccess backends? That's a fair argument, but a different story.

I am puzzled how this is an XSA that addresses "privilege escalation".

Thanks
Andres

>
> See the patch for technical details of the problem.
>
> IMPACT
> ======
>
> Deployments of software inspired by, or derived from,
> xen.git/tools/tests/xen-access/xen-access.c, may be vulnerable to
> privilege escalation by a malicious guest administrator.
>
> xen-access is a test/example program and is not, without modification,
> useful in production.  It is not built or installed by default.
>
> VULNERABLE SYSTEMS
> ==================
>
> Unmodified Xen installations (including installations as provided by
> typical Free Software distributions) are not vulnerable.
>
> The following toolstacks/libraries do not use memaccess, so systems
> using Xen only via the following are not vulnerable:
>     libxl; xl; xend; xm; libvirt
>
> In general, Xen installations which make no use of the Xen memory
> access API (xc_mem_access_..., "XENMEM_access_...",
> XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE) are not vulnerable.
>
> Systems using the Xen hypervisor 4.1 or earlier are not vulnerable.
> ARM systems are not vulnerable.  AMD systems are not vulnerable.
> Intel x86 systems without EPT are not vulnerable.
>
> Software developers who have based their efforts on xen-access.c may
> have constructed vulnerable systems.  Such developers should examine
> their software, and communicate with their own downstreams, as
> applicable.
>
> Users of Xen-derived systems, whose vulnerability is not excluded
> above, should consult their vendor for information about the
> applicability of this vulnerability.
>
> MITIGATION
> ==========
>
> Disabling whatever functionality uses the memaccess API will avoid the
> vulnerability.
>
> NOTE REGARDING CVE
> ==================
>
> The CVE assignment team at the MITRE CVE Numbering Authority have told
> us that type of issue is typically considered site-specific and is not
> eligible for a CVE ID:
>
>  The scope of CVE does not include issues where a vulnerable program
>  can be present after a customer modifies shipped source code or
>  modifies the build process. The primary purpose of this guideline is
>  to avoid CVE assignments where, for example, the vulnerability exists
>  only when a customer enables experimental code and then recompiles. A
>  secondary purpose of this guideline is to avoid CVE assignments for
>  example code that wasn't intended to be used as-is.
>
> Software developers who have based production code on xen-access.c
> should obtain their own CVE number(s).
>
> CREDITS
> =======
>
> This vulnerability was discovered by Ian Campbell of Citrix.
>
> RESOLUTION
> ==========
>
> The attached patch repairs the test/example utility provided in the
> Xen Project source tree.
>
> To resolve the issue in production software, appropriate changes
> will have to be be made by its developers.
>
> $ sha256sum xsa99*.patch
> d6496699d9952bbfe1cd86e0ba84182e455a5dc4626654d387f92390d9680cd4
>  xsa99.patch
> $
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iQEcBAEBAgAGBQJToCn/AAoJEIP+FMlX6CvZBp8H/Az39oLQiAIyrZRD+IktvGuB
> mCLRcoyTJxxfE+9bAFltypelGNwq5NT/JUwub82whapbPW/e/rtGbln43FkdkoLu
> oFlddcteOzJMTLsLXxe50zrgb4QaUEt4lxQ2zEyFpL6PYz32pO24NLK8QzG480Ol
> 4u1UlBJeYM61Z4JPuCy0h5vMy0eU6G3yry6B09s4Dmdfvd6AU7BprFT4/aW+noQ0
> 84w11iL8Y53ddnidTgaXNkyvcq+5m57RL9uHvrRz7mViqhazkVkxGZHVKsUYuRPb
> wkBpSaa+cJkeF8AnDue/QuW0pWYpfrPoniD86SwgzsYYj5bN0EnQ4CTzVIAx284=
> =9myT
> -----END PGP SIGNATURE-----
>
>
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.