Date: Tue, 08 Dec 2015 12:02:21 +0000 From: Xen.org security team <security@....org> To: xen-announce@...ts.xen.org, xen-devel@...ts.xen.org, xen-users@...ts.xen.org, oss-security@...ts.openwall.com CC: Xen.org security team <security@....org> Subject: Xen Security Advisory 160 (CVE-2015-8341) - libxl leak of pv kernel and initrd on error -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2015-8341 / XSA-160 version 3 libxl leak of pv kernel and initrd on error UPDATES IN VERSION 3 ==================== Public release. 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. CREDITS ======= This issue was discovered by George Dunlap of Citrix. 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* 470811aeead5e942d6fedad5b4e21bee85f2160b022bcab315520014b6aa39a6 xsa160.patch d0ce9e3c2b951ac3d25da4a0f6f232b13980625a249ed9c4cd6e9484721943a5 xsa160-4.4.patch 40362873b7fa2c1450596ef9ea23c73f80608b77ca50b89e62daf46c131fcee6 xsa160-4.6.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patch described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. However deployment of the mitigations described above is not permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because such a change to the bootloader arrangements of a PV guest would be a user-visible change which could lead to the rediscovery of the vulnerability. 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----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJWZr8JAAoJEIP+FMlX6CvZfEYH/Rg7X9HdB+937h81tq30nrkE /PazyPDB8DprHL0X/IjPEQFvGOazCf45uzSzkrPXaFwu27yhbAxx/m8s94FxUjWb EiWwYKsb0Gh9OBejRkgiB3VMQmySWqkcjzUR1f2hk4iJ3yX8q2peRECK/Ba9aYPu lHN9aycnh1ORPmWPUUo8cMFhRVag1P5E77mqrxXo2nfed23xDA5GeZceg8XoT67n T2m59xAEwrSrHypb/XESuwtEU67CnowRcxlH7Z3EEk+ljvxOBvdovNp0yztOtArK EnV3UAwM+YMXvoYB4YZUQ/q9tZ1dIgyeTosOSoNHI471lBYL9QTlO22bc4+qKCE= =IjJr -----END PGP SIGNATURE----- Download attachment "xsa160.patch" of type "application/octet-stream" (2739 bytes) Download attachment "xsa160-4.4.patch" of type "application/octet-stream" (2702 bytes) Download attachment "xsa160-4.6.patch" of type "application/octet-stream" (2744 bytes)
Powered by blists - more mailing lists
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.