-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2020-29479 / XSA-353 version 4 oxenstored: permissions not checked on root node UPDATES IN VERSION 4 ==================== Public release. ISSUE DESCRIPTION ================= In the Ocaml xenstored implementation, the internal representation of the tree has special cases for the root node, because this node has no parent. Unfortunately, permissions were not checked for certain operations on the root node. Unprivileged guests can get and modify permissions, list, and delete the root node. Deleting the whole xenstore tree is a hostwide denial of service. Depending on the circumstances, the vulnerability can also be leveraged into an ability to gain write access to any part of xenstore. IMPACT ====== A guest administrator can deny service to the whole system simply by deleting the whole of xenstore. Additionally, depending on other software in use, privilege escalation may be possible. With the default "xl" toolstack, a guest administrator can escalate their privilege to that of the 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. The impact depends on the toolstack and other management software in use. Systems using libxl (for example, via "xl" or libvirt) are vulnerable to privilege escalation. Systems using C xenstored are not vulnerable, no matter what toolstack or management software is in use. 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. Note that the Ocaml patches for XSA-115 depend on this patch. xsa353.patch xen-unstable - 4.10 $ sha256sum xsa353* 48fa1f414773ab1a4135fe62aaae25c7c543efe5a4c5dba71db9e497fa9f3362 xsa353.meta e14922bf6b2095c1b17849b130e999726a1a31e29be1374e0cd3f9a8fa59fd3d xsa353.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+FMlX6CvZmg8IALQltyH/EPk78gGNyeb/1ri3jr7IVR5lyCy1Aedg zckh8FNaaRCplZAoa2Kc2aV2H1Lc5x/UfWtoOLaiSdcyRNXRKRFwq7LoBT7OH2SH KSo2HK0licTOv61SL2LoJ38tXec86V0Cos89DuWtSMLQT3LUmixQlSdiTUueFidH Fei8mqoYor5WtzjfgKjdR5KwrrPj65QFyUic3bRgdcc/t27Wr+oQU5iGg7ayeCNw 5Ylz8eyJj88rkNVw1S4jFH815lyENaJbVn56VvlEm0KDsnY7G4YAHExZ1lElrOdj nkOXN3o6CGiHTkXPOsbPuy0WboSrXK9AZykasml/EDw41Vg= =V1xW -----END PGP SIGNATURE-----