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

            Xen Security Advisory CVE-2020-29482 / XSA-323
                               version 3

                   Xenstore: wrong path length check

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

Public release.

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

A guest may access xenstore paths via absolute paths containing a full
pathname, or via a relative path, which implicitly includes
/local/domain/$DOMID for their own domain id.  Management tools must
access paths in guests' namespaces, necessarily using absolute paths.

oxenstored imposes a path name limit which is applied solely to the
relative or absolute path specified by the client.  Therefore, a guest
can create paths in its own namespace which are too long for management
tools to access.

IMPACT
======

Depending on the toolstack in use, a malicious guest administrator
might cause some management tools and debugging operations to fail.
For example, a guest administrator can cause `xenstore-ls -r` to fail.

However a guest administrator cannot prevent the host administrator
from tearing down the domain.

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 and analysed by Andrew Cooper, both
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.

xsa323.patch           xen-unstable - Xen 4.11.x
xsa323-4.10.patch      Xen 4.10.x

$ sha256sum xsa323*
b693f259d92033ffc568412f1ea591b63d7e8dcaa7f88b62158b3c09e65ad122  xsa323.meta
fdfefa3c064c6c5f49d666d7c3444f919777d557c8cb9c2e9ae6ac94711d37de  xsa323.patch
90ab525fad3f43b6de2858f8a58128ce0d4ca97f5960bcd2af5be55d49059c92  xsa323-4.10.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/Yqd4MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZNeEH/iXf3oBcCJAICRa2WuXXR8zs/R/GUaiQCJYvU2So
OBil7cnb6bIomVmDd7TxjYUaHL3ilMEFHPTbUq0gLLKPlaJqVJTLyxDzss6VEmqp
eyQ8GBRODHLHCGcQaS3eKtCN9e6Oyd+rEm5CIPXvcu+g+HVnxG1BCdzHOei7NEPS
P5rmOn3Gkv6LlYQpVPYzVX3baIpLe09Ha+1iCS2bflArPgAc23ajxHHffuI90TIF
cBjN93AOpgBc89wGM0G11NSPAjnVUWe69qLJp6HDW6mQRaUxHQVbpBesd0V43/9P
XCvo6TxWdfDgJFOubZRKg6jHP5CKqobL4PZZT+X1MC8ZNbI=
=ilKH
-----END PGP SIGNATURE-----