[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    [oss-security] Xen Security Advisory 352 v3 (CVE-2020-29486) - oxenstored: node ownership can be cha
From:       Xen.org security team <security () xen ! org>
Date:       2020-12-15 12:20:24
Message-ID: E1kp9JY-00077n-Gf () xenbits ! xenproject ! org
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

            Xen Security Advisory CVE-2020-29486 / XSA-352
                               version 3

   oxenstored: node ownership can be changed by unprivileged clients

UPDATES IN VERSION 3
====================

Public release.

ISSUE DESCRIPTION
=================

Nodes in xenstore have an ownership.  In oxenstored, a owner could
give a node away.  But node ownership has quota implications.

Any guest can run another guest out of quota, or create an unbounded
number of nodes owned by dom0, thus running xenstored out of memory

IMPACT
======

A malicious guest administrator can cause denial of service, against a
specific guest or against the whole host.

VULNERABLE SYSTEMS
==================

All systems using oxenstored are vulnerable.  Building and using
oxenstored is the default in the upstream Xen distribution, if the
Ocaml compiler is available.

Systems using C xenstored are not vulnerable.

MITIGATION
==========

There are no mitigations.

Changing to use of C xenstored would avoid this vulnerability.  However,
given the other vulnerabilities in both versions of xenstored being
reported at this time, changing xenstored implementation is not a
recommended approach to mitigation of individual issues.

CREDITS
=======

This issue was discovered by Edwin Török of Citrix.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball.  Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.

xsa352.patch           xen-unstable - 4.10

$ sha256sum xsa352*
a3b2b2bd4c6b49c472df23f88fb9a5e204d2ba3cd0c3901f8ed057566ef98c85  xsa352.meta
6f9798e20282d4e06f0a8a1abd0d147649e20b33c21559d5a1ea0b1a73a2a4e4  xsa352.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.


(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl/Yqd8MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZ/JgH/Rb3BDBjWi+fTDsPMr21yDsrCWGzpyBabflpglQt
b3rTDEx7YlNCkb32xYvZLR9mGAGg8X01zIQVKOQ10Hnib6Vx4TvcdwPqSYGMn3U6
4g3TmWpZJZNfCIbdznXGhOmTLZzVEGDZu1+S+mE3aAdtDGEE98p9P/J43dEt/kWX
R/DcMrCe9LOHKi+MCxZqAFlbZ79QJls6G/sH6VWSUp/Bq8hCtsd/C0Jk3LIBZgnW
V3SUYLhR7Tp7Pkda4m4lVLlvCo+9jlVwevs/MmvyFulxUrDN1/9LrHpZyJ7ZMBwt
2N7zpJpdrY5JiEH6d4fuVUsH78+9+zVxs5PFDXUc7ud2QyA=
=ofMB
-----END PGP SIGNATURE-----

["xsa352.meta" (application/octet-stream)]
["xsa352.patch" (application/octet-stream)]

From: =?UTF-8?q?Edwin Török?= <edvin.torok@citrix.com>
Subject: tools/ocaml/xenstored: only Dom0 can change node owner
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Otherwise we can give quota away to another domain, either causing it to run
out of quota, or in case of Dom0 use unbounded amounts of memory and bypass
the quota system entirely.

This was fixed in the C version of xenstored in 2006 (c/s db34d2aaa5f5,
predating the XSA process by 5 years).

It was also fixed in the mirage version of xenstore in 2012, with a unit test
demonstrating the vulnerability:

  https://github.com/mirage/ocaml-xenstore/commit/6b91f3ac46b885d0530a51d57a9b3a57d64923a7
  https://github.com/mirage/ocaml-xenstore/commit/22ee5417c90b8fda905c38de0d534506152eace6

but possibly without realising that the vulnerability still affected the
in-tree oxenstored (added c/s f44af660412 in 2010).

This is XSA-352.

Signed-off-by: Edwin Török <edvin.torok@citrix.com>
Acked-by: Christian Lindig <christian.lindig@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff --git a/tools/ocaml/xenstored/store.ml b/tools/ocaml/xenstored/store.ml
index 3b05128f1b..5f915f2bbe 100644
--- a/tools/ocaml/xenstored/store.ml
+++ b/tools/ocaml/xenstored/store.ml
@@ -407,7 +407,8 @@ let setperms store perm path nperms  	| Some node ->
 		let old_owner = Node.get_owner node in
 		let new_owner = Perms.Node.get_owner nperms in
-		if not ((old_owner = new_owner) || (Perms.Connection.is_dom0 perm)) then Quota.check store.quota new_owner 0;
+		if not ((old_owner = new_owner) || (Perms.Connection.is_dom0 perm)) then
+			raise Define.Permission_denied;
 		store.root <- path_setperms store perm path nperms;
 		Quota.del_entry store.quota old_owner;
 		Quota.add_entry store.quota new_owner


[prev in list] [next in list] [prev in thread] [next in thread]