Xen Security Advisory CVE-2015-8339,CVE-2015-8340 / XSA-159 version 2 XENMEM_exchange error handling issues *** EMBARGOED UNTIL 2015-12-08 12:00 UTC *** UPDATES IN VERSION 2 ==================== CVEs assigned. ISSUE DESCRIPTION ================= Error handling in the operation may involve handing back pages to the domain. This operation may fail when in parallel the domain gets torn down. So far this failure unconditionally resulted in the host being brought down due to an internal error being assumed. Furthermore error handling so far wrongly included the release of a lock. That lock, however, was either not acquired or already released on all paths leading to the error handling sequence. IMPACT ====== A malicious guest administrator may be able to deny service by crashing the host or causing a deadlock. VULNERABLE SYSTEMS ================== All Xen versions from at least 3.2 onwards are vulnerable. Older versions have not been inspected. MITIGATION ========== The vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. In Xen HVM, controlling the guest's kernel would involve locking down the bootloader. RESOLUTION ========== Applying the attached patch resolves this issue. xsa159.patch xen-unstable, Xen 4.6.x, Xen 4.5.x, Xen 4.4.x, Xen 4.3.x $ sha256sum xsa159* 53358536cc00258139224771d85cb1f3489e63a8156244285cd6213107fa9b32 xsa159.patch $ =================================== Xen Security Advisory CVE-2015-8341 / XSA-160 version 2 libxl leak of pv kernel and initrd on error *** EMBARGOED UNTIL 2015-12-08 12:00 UTC *** UPDATES IN VERSION 2 ==================== CVE assigned. ISSUE DESCRIPTION ================= When constructing a guest which is configured to use a PV bootloader which runs as a userspace process in the toolstack domain (e.g. pygrub) libxl creates a mapping of the files to be used as kernel and initial ramdisk when building the guest domain. However if building the domain subsequently fails these mappings would not be released leading to a leak of virtual address space in the calling process, as well as preventing the recovery of the temporary disk files containing the kernel and initial ramdisk. IMPACT ====== For toolstacks which manage multiple domains within the same process, an attacker who is able to repeatedly start a suitable domain (or many such domains) can cause an out-of-memory condition in the toolstack process, leading to a denial of service. Under the same circumstances an attacker can also cause files to accumulate on the toolstack domain filesystem (usually under /var in dom0) used to temporarily store the kernel and initial ramdisk, perhaps leading to a denial of service against arbitrary other services using that filesystem. VULNERABLE SYSTEMS ================== Both ARM and x86 systems using a libxl based toolstack are potentially vulnerable. Only libxl-based toolstacks which manage multiple domains in the same process (such as `libvirt') are vulnerable. libxl-based toolstacks which manage only a single domain per process and which exit on failure to create a domain (such as `xl') are not vulnerable. Toolstacks not using libxl are not vulnerable to this issue. Only domains configured to use a PV bootloader in the toolstack domain (e.g. pygrub) will expose this issue. Domains configured to use pvgrub (a totally different program) are not vulnerable. x86 HVM domains are not vulnerable. Systems where the kernel and initial ramdisk are provided by the host administrator from files in domain 0 are not vulnerable. Xen versions 4.1.x and later are vulnerable. MITIGATION ========== Avoiding the use of the PV bootloader mechanisms which run as processes in the toolstack domain (pygrub), either by providing kernels directly from the toolstack domain or using a PV bootloader which runs in guest context (such as pvgrub) will prevent exposure of this issue. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa160.patch xen-unstable xsa160-4.6.patch Xen 4.5.x, 4.6.x xsa160-4.4.patch Xen 4.3.x, 4.4.x $ sha256sum xsa160* 784398ede8ee959b1442b1916a89ec2bfcae3aab543407a7e7e21ee2c5e1fca0 xsa160.patch 82a0e1b332b9fbbcce0d703b47646c86acffda2c0b972e9c3eae197281f951ce xsa160-4.4.patch 38c6c66576f1d3ae335c5f05987d3de5acf3aad7fa59b4ee7992a65b89773960 xsa160-4.6.patch =========================================
Patches have been sent to xen maintainers.
commit cec1b419cc9c56d2573a858a6c6e727f97d924a4 Author: Ian Delaney <idella4@gentoo.org> Date: Wed Dec 9 13:28:39 2015 +0800 clean vulnerable vns. wrt #566842 #566844 Package-Manager: portage-2.2.24 commit d20b6d3f4e02313651ce37098087215e2e8ad92c Author: Ian Delaney <idella4@gentoo.org> Date: Wed Dec 9 13:26:20 2015 +0800 app-emulation/xen-tools: revbumps -> vns. 4.5.2-r2, 4.6.0-r3 wrt sec. bugs Addition of patches XSA-158 (#566844), XSA-{159,160} (#566842), fixing all corresponding security issues, patches made avaialable for public release as of yesterday (08/12). Patches compressed into my devspace then combined with those of dlan insource. This format will do for now. Not to be adjusted without prior discussion. All patches pass runtests Gentoo bugs: #566842 #566844
Is 4.5.2-r2 ready to go to stable?
(In reply to Agostino Sarubbo from comment #3) > Is 4.5.2-r2 ready to go to stable? Yes please ago, make it stable Arch; amd64
amd64 stable. Maintainer(s), please cleanup. Security, please vote.
(In reply to Agostino Sarubbo from comment #5) > amd64 stable. > > Maintainer(s), please cleanup. > Security, please vote. ago slight misunderstanding, title app-emulation/xen implicates xen only. xen-tools-4.5.2-r2 also requires making stable. xen / xen-tools are typically both drawn in, rarely xen-pvgrub. Will wait for this before cleaning both. Target: amd64
Arches, please test and mark stable: =app-emulation/xen-tools-4.5.2-r2 Target Keywords : "amd64 x86" Thank you! Resetting Stabilization for the xen-tools, as per maintainer.
(In reply to Ian Delaney from comment #6) > ago slight misunderstanding, title app-emulation/xen implicates xen only. > xen-tools-4.5.2-r2 also requires making stable. xen / xen-tools are > typically both drawn in, rarely xen-pvgrub. Will wait for this before > cleaning both. Next time please use the form used by Yury in comment #7
(In reply to Yury German from comment #7) > Arches, please test and mark stable: > > =app-emulation/xen-tools-4.5.2-r2 > > Target Keywords : "amd64 x86" > > Thank you! > > Resetting Stabilization for the xen-tools, as per maintainer. x86 has nothing to do here.
commit 15376b7a9fc87586a7767a2f5456dd861d9d0028 Author: Ian Delaney <idella4@gentoo.org> Date: Wed Dec 23 08:22:13 2015 +0800 app-emulation/xen-tools: clean vn. 4.5.2-r1 re sec bug #566842 commit 59aef5a6741547b1c8a27ac7feebe6a307f7aa15 Author: Ian Delaney <idella4@gentoo.org> Date: Wed Dec 23 08:19:16 2015 +0800 app-emulation/xen: clean vn. 4.5.2-r1 re sec bug #566842
Please Clean or Mask - app-emulation/xen-tools 4.2.5-r11, 4.2.5-r10. Setting dependency for all other cleanup for xen-tools against this bug.
masking them breaks rdep qemu atm
This issue was resolved and addressed in GLSA 201604-03 at https://security.gentoo.org/glsa/201604-03 by GLSA coordinator Yury German (BlueKnight).
