Protect yourself against future threats.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 =========================================================================== AUSCERT External Security Bulletin Redistribution ESB-2015.2735 Multiple vulnerabilities have been identified in Xen 2 November 2015 =========================================================================== AusCERT Security Bulletin Summary --------------------------------- Product: Xen Publisher: Xen Operating System: Xen UNIX variants (UNIX, Linux, OSX) Windows Impact/Access: Denial of Service -- Existing Account Resolution: Patch/Upgrade CVE Names: CVE-2015-7972 CVE-2015-7971 CVE-2015-7970 CVE-2015-7969 CVE-2015-7814 CVE-2015-7813 Original Bulletin: http://xenbits.xen.org/xsa/advisory-146.html http://xenbits.xen.org/xsa/advisory-147.html http://xenbits.xen.org/xsa/advisory-149.html http://xenbits.xen.org/xsa/advisory-150.html http://xenbits.xen.org/xsa/advisory-151.html http://xenbits.xen.org/xsa/advisory-152.html http://xenbits.xen.org/xsa/advisory-153.html Comment: This bulletin contains seven (7) Xen security advisories. - --------------------------BEGIN INCLUDED TEXT-------------------- - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2015-7813 / XSA-146 version 3 arm: various unimplemented hypercalls log without rate limiting UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= The HYPERVISOR_physdev_op hypercall and most suboperations of the HYPERVISOR_hvm_op hypercall are not currently implemented by Xen on ARM and when called will log the use to the hypervisor console. However these guest accessible log messages are not rate-limited. IMPACT ====== A malicious guest could cause repeated logging to the hypervisor console, leading to a Denial of Service attack. VULNERABLE SYSTEMS ================== Xen 4.4 and later systems running on ARM hardware are vulnerable. x86 systems are not affected. MITIGATION ========== The problematic log messages are issued with priority Warning. Therefore they can be rate limited by adding "loglvl=error/warning" to the hypervisor command line or suppressed entirely by adding "loglvl=error". On systems where the guest kernel is controlled by the host rather than guest administrator, running only kernels which do not call these hypercalls will also prevent untrusted guest users from exploiting this issue. However untrusted guest administrators can still trigger it unless further steps are taken to prevent them 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. CREDITS ======= This issue was discovered by Julien Grall of Citrix. RESOLUTION ========== Applying the attached patch resolves this issue. xsa146.patch xen-unstable, Xen 4.6.x, Xen 4.5.x, Xen 4.4.x $ sha256sum xsa146*.patch 1d0ff203581ac5bcc0ec4469a4909da968b218ed83280efd217020c396028591 xsa146.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----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJWMgm1AAoJEIP+FMlX6CvZGjMH/iYvPwiZU0iKkgADyMBek6A6 fmkHlmd5z7EC7eSwKn2SzRcw8KsE9E4Hdo4IaPoWx+ElSKlHwteo8vdHq3zYXWsb vpYFvlD5wiWRYpTDiBtDZC7cwOx1qqelDMwwN8k3p1g+eNqEB5VrfjVWWxp7xE6a +gqEea9+ASJmZ1K3cczOGIzWSrGSGcC7v715nECCwBkquYlsdP8L7I+K2IiCL45i ymRm+fD3CvDtLT+Q3ZG9I/C78CH5O4INATrdz6Syqtti+jPoYY7+6LmLZXR0tIk2 v47g/mAoDNwJAaWDfZL9GnzXTZIm+Lri+qh/4LkunnMGgHIF4Ah4HhsNJlX4h7M= =lDV8 - -----END PGP SIGNATURE----- - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2015-7814 / XSA-147 version 3 arm: Race between domain destruction and memory allocation decrease UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= While freeing the memory associated with a domain during domain destruction Xen could race with a toolstack domain reducing the amount of memory associated with that same domain via the XENMEM_decrease_reservation. In the case where this race is hit the host will crash. The race is not exposed via the XENMEM_remove_from_physmap or XENMEM_exchange interfaces. IMPACT ====== Domains deliberately given partial management control may be able to deny service by crashing the host. Such a domain needs to be granted access to at least one of XENMEM_decrease_reservation or XEN_DOMCTL_destroydomain over another domain. As a result, in a system designed to enhance security by radically disaggregating the management, the security may be reduced. But, the security will be no worse than a non-disaggregated design. VULNERABLE SYSTEMS ================== This issue is only relevant to systems which intend to increase security through the use of advanced disaggregated management techniques. This does not include systems using libxl, libvirt, or OpenStack (unless substantially modified or supplemented, as compared to versions supplied by the respective upstreams). Only ARM systems are potentially affected. All Xen versions which support ARM are potentially affected. x86 systems are not affected. MITIGATION ========== There is no known mitigation. Switching from disaggregated to a non-disaggregated operation does NOT mitigate these vulnerabilities. Rather, it simply recategorises the vulnerability to hostile management code, regarding it "as designed"; thus it merely reclassifies these issues as "not a bug". Users and vendors of disaggregated systems should not change their configuration. CREDITS ======= This issue was discovered by Ian Campbell of Citrix. RESOLUTION ========== Applying the attached patch resolves this issue. xsa147.patch xen-unstable, Xen 4.6.x, Xen 4.5.x, Xen 4.4.x $ sha256sum xsa147*.patch 35cd9c5dabd5af6756957cf7378d527b2fcbff35dcf578769769a364a98ea6ac xsa147.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----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJWMgm3AAoJEIP+FMlX6CvZHPAIAIgXu4741IJeO/Pb187gxO3Z IXpSSJF1Fvof/Ma6LLSGRth94WiafF91MKKqlEAKFPyfRUOkJXHAoahDUe7lF1Lr V5qSA4jAu69ZIhg3AAKuI+xBV/PNx7rlaG0duRI9nHmLRhbIU3EF9YJbKntdZzZr gdE/zLk+moW4U2/quEIEQGqtDGr/RAm5N0MqGwW4mcHUhlp4XcNuqrC8+b5qaeJ3 8/pc9whzyHM04De5Ve9/iFUu0J6KxNK+hN9V14mO8bcPXzK/K8X4C3qUD6HtZx+U VsaKT/N4INNDg7wqULcjg/Vp23SE/mUPM8Fernee9KnI2CY3pnS9DB1KEYMry5s= =7g7l - -----END PGP SIGNATURE----- - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2015-7969 / XSA-149 version 3 leak of main per-domain vcpu pointer array UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= A domain's primary array of vcpu pointers can be allocated by a toolstack exactly once in the lifetime of a domain via the XEN_DOMCTL_max_vcpus hypercall. This array is leaked on domain teardown. This memory leak could -- over time -- exhaust the host's memory. IMPACT ====== A domain given partial management control via XEN_DOMCTL_max_vcpus can mount a denial of service attack affecting the whole system. The ability to also restart or create suitable domains is also required to fully exploit the issue. Without this the leak is limited to a small multiple of the maximum number of vcpus for the domain. The maximum leak is 64kbytes per domain (re)boot (less on ARM). VULNERABLE SYSTEMS ================== This issue is only relevant to systems which intend to increase security through the use of advanced disaggregated management techniques. This does not include systems using libxl, libvirt, or OpenStack (unless substantially modified or supplemented, as compared to versions supplied by the respective upstreams). Versions of Xen from 4.0 onwards are vulnerable. All architectures are affected. MITIGATION ========== The leak is small. Preventing the creation of large numbers of new domains, and limiting the number of times an existing domain can be rebooted, can reduce the impact of this vulnerability. Switching from disaggregated to a non-disaggregated operation does NOT mitigate the XEN_DOMCTL_max_vcpus vulnerability. Rather, it simply recategorises the vulnerability to hostile management code, regarding it "as designed"; thus it merely reclassifies these issues as "not a bug". Users and vendors of disaggregated systems should not change their configuration. NOTE REGARDING CVE ================== Note that CVE-2015-7969 covers both this issue and XSA-151. CREDITS ======= This issue was discovered by Ian Campbell of Citrix. RESOLUTION ========== Applying the attached patch resolves this issue. (To resolve CVE-2015-7969, the patch from XSA-151 is required too.) xsa149.patch xen-unstable, Xen 4.6.x, Xen 4.5.x, Xen 4.4.x, Xen 4.3.x $ sha256sum xsa149*.patch e01628400b81c4bb7bafba348f2ecb1fe80f16e3162cee5013e0be1d7311738b xsa149.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the PATCH (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 (RE)BOOT LIMIT MITIGATION 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 applying domain creation and reboot limits in connection with a security issue would be a user-visible change which could lead to the rediscovery of the vulnerability. Deployment of the mitigation is permitted only AFTER the embargo ends. Also: 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) iQEcBAEBAgAGBQJWMgm7AAoJEIP+FMlX6CvZ5EEH/RpWXVKVpA5JdTGGfWan9ojV +9Froz+RdUJmINLHE/sIIAudfCIlc7zA1Ap/ukSUC9YfBZvjwMpiouTz2IJV+kgp C0zTjTHrqf0RG7k9aXKTqDNhHWP/FukVv6V4KZ+vmC9CluV8ODhnvogO0bS4wO2y dzJAtQZxhD1r0rgvLWlT0Wq0LylTqW6mXg0lHiBv+HFonKJAIEeg/0dJbriKsc0N 1+vI4DujVzE1Q3LuhkGtaxdGyZ/4rcfMexmIYHzpvehHLXKa63oHg7IGX2SchiKb YFumc9K3sYdv+AHkqM9FdtKEgDvwcHL9+d4YVgGfQm9ukh2onEC6uw7VeVnPlXY= =/Ww0 - -----END PGP SIGNATURE----- - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2015-7970 / XSA-150 version 5 x86: Long latency populate-on-demand operation is not preemptible UPDATES IN VERSION 5 ==================== Updated patch. Compared to the version in XSA-150 v4 and earlier, this patch is simpler and involves less rearrangement of the code. It is therefore thought to be less risky. However, both this version and the earlier versions have been tested, and both versions eliminate the vulnerability. Readers who have already prepared updates with, and/or deployed, the earlier patch, do not necessarily need to update. Public release. ISSUE DESCRIPTION ================= When running an HVM domain in Populate-on-Demand mode, Xen would sometimes search the domain for memory to reclaim, in response to demands for population of other pages in the same domain. This search runs without preemption. The guest can, by suitable arrangement of its memory contents, create a situation where this search is a time-consuming linear scan of the guest's address space. The scan might be triggered by the guest's own actions, or by toolstack operations such as migration. In guests affected by XSA-153, this scan might be triggered simply by memory pressure in the guest. Even guests not started in PoD mode can create PoD entries. IMPACT ====== A malicious HVM guest administrator can cause a denial of service. Specifically, prevent use of a physical CPU for a significant period. If a host watchdog (Xen or dom0) is in use, this can lead to a watchdog timeout and consequently a reboot of the host. If another, innocent, guest, is configured with a watchdog, this issue can lead to a reboot of such a guest. In guests affected by XSA-153, this vulnerability may also be triggered by an unprivileged guest user, simply by imposing a workload which generates memory pressure. VULNERABLE SYSTEMS ================== The vulnerability is exposed to any x86 HVM guest. ARM is not vulnerable. x86 PV VMs are not vulnerable. Versions of Xen from 3.4 onwards are affected. MITIGATION ========== Running only PV guests will avoid this issue. On systems not also vulnerable to XSA-153, the vulnerability can be avoided by ensuring that only trusted guest kernels are used, and that further steps are taken to prevent a 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. CREDITS ======= This is issue was disclosed by Andrew Cooper of Citrix. RESOLUTION ========== Attached is a patch which resolves the issue by limiting the long-running "sweep" operation. This patch will resolve the issue on systems where PoD is not intentionally in use. (Ie, where all HVM guests are started with memory==maxmem.) When PoD is in use, there are concerns that there may be situations -- operating systems not tested, or buggy balloon drivers, for example -- where limiting the long-running operation may cause guests to crash which may otherwise not. Therefore, the patch should be used with caution. This patch can interact badly on configurations vulnerable to XSA-153. XSA-153 is triggerable by unprivileged guest users. The patch changes the consequences from a host-wide CPU denial problem (which might be tolerated without catastrophic symptoms in some configurations) into a likely guest crash; thus it limits the scope of the consequences to the specific guest, but may worsen the severity. xsa150.patch xen-unstable, Xen 4.6.x, Xen 4.5.x, Xen 4.4.x, Xen 4.3.x $ sha256sum xsa150* 9054215f08cab48d2523efb456eb3c93ca6ac580d661f6e4f1feca115c67afa8 xsa150.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----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJWMgobAAoJEIP+FMlX6CvZ7W4H/36Bx6Aj+4PX3kLPwzsheejj CWpOQjM4BZAVWkv1N9QInJagZ87qRFwFGlM8FzDuGy3dE7Df5MCs/BH9B1xrJ0E9 Ur30mpsw1IAf9YF/l/XlNLf9G6XCo/g2yS7Jfv5qk3953+0ZkqSd7t8ekFaQSKUz GGOkhQKJuFsnEmimQTLLBt6brHaYfFJtnbKIFzcBQtRExlKI3BYk3OHNLvIUlj6X MGij0fJTJggvGjaZ+Olthf0GLtDIZ8GbWD+0FQ4bJwEAacSJ1eVOYzVAdNfFIuVv 73MyN8QyEgu+HSc9RJnILV/g7oIfuGazo1A19KAjeImd81W4bQDVnZJ1KCkcbd0= =ISHR - -----END PGP SIGNATURE----- - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2015-7969 / XSA-151 version 3 x86: leak of per-domain profiling-related vcpu pointer array UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= A domain's xenoprofile state contains an array of per-vcpu information, which is allocated once in the lifetime of a domain in response to that domain using the XENOPROF_get_buffer hypercall on itself or by a domain with the privilege to profile a target domain using the XENOPROF_set_passive hypercall. This array is leaked on domain teardown. This memory leak could -- over time -- exhaust the host's memory. IMPACT ====== The following parties can mount a denial of service attack affecting the whole system: - A malicious guest administrator via XENOPROF_get_buffer. - A domain given suitable privilege over another domain via XENOPROF_set_passive (this would usually be a domain being used to profile another domain, eg with the xenoprof tool). The ability to also restart or create suitable domains is also required to fully exploit the issue. Without this the leak is limited to a small multiple of the maximum number of vcpus for the domain. The maximum leak is 128kbytes per domain (re)boot. VULNERABLE SYSTEMS ================== Versions of Xen from 4.0 onwards are vulnerable. The XENOPROF hypercalls are only implemented on x86. ARM is therefore not vulnerable. MITIGATION ========== On systems where the guest kernel is controlled by the host rather than guest administrator, running only kernels (in the target and profiling domain respectively) which do not call these hypercalls will also prevent untrusted guest users from exploiting this issue. However untrusted guest administrators can still trigger it unless further steps are taken to prevent them 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. The leak is small. Preventing the creation of large numbers of new domains, and limiting the number of times an existing domain can be rebooted, can reduce the impact of this vulnerability. NOTE REGARDING CVE ================== Note that CVE-2015-7969 covers both this issue and XSA-149. CREDITS ======= This issue was discovered by Jan Beulich of SUSE. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. (To resolve CVE-2015-7969, the patch from XSA-149 is required too.) xsa151.patch xen-unstable, Xen 4.6.x, Xen 4.5.x, Xen 4.4.x, Xen 4.3.x $ sha256sum xsa151*.patch e247a9dbbe236ffa3c5aa5e2d41047fa67da80f2b0474eef3440b5b3da2d5617 xsa151.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the PATCH or the TRUSTED KERNEL MITIGATION (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 (RE)BOOT LIMIT MITIGATION 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 applying domain creation and reboot limits in connection with a security issue would be a user-visible change which could lead to the rediscovery of the vulnerability. Deployment of the reboot mitigation is permitted only AFTER the embargo ends. Also: 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) iQEcBAEBAgAGBQJWMgm9AAoJEIP+FMlX6CvZticH+waAPTUnRA9CTnPs1BDjiTcc kBuVb8ouvffinj+FCVQ/CIC1IAkClU8vBcOb3NAe9/PaCYPe9OlAxpvAAxxlgr05 N1Py8rBUEemKcCS9T4jTT2TNLYm9lzFihcTMOp+Y2diavcdmnhXj+kjO/FpD7tG/ TRDBnCVsxA4m+yxQJO8xXWIE+lYCoF+42Qc8Dyi2tcaN4WaBjjD5DyqNHIuf1ISF DljnT3TsgDIlxmgeQsufX0VIh45FdZXExOmGAgRS3JCn0cTmQwONecyM5NjKaljZ LEwk5sMSRa4cmb8naJRxPf30CydjmLBMdzU8KRjg+d6M46jTGTV794k/AKc4VxI= =u9LH - -----END PGP SIGNATURE----- - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2015-7971 / XSA-152 version 3 x86: some pmu and profiling hypercalls log without rate limiting UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= HYPERCALL_xenoprof_op and HYPERVISOR_xenpmu_op log some errors and attempts at invalid operations. These log messages are not rate-limited, even though they can be triggered by guests. IMPACT ====== A malicious guest could cause repeated logging to the hypervisor console, leading to a Denial of Service attack. VULNERABLE SYSTEMS ================== Xen versions 3.2.x and later are affected. (The VPMU part of the vulnerability is applicable only to Xen 4.6 and later.) ARM systems are not affected. (The pmu hypercall is x86-specific, and xenoprof is not supported on ARM.) MITIGATION ========== The problematic log messages are issued with priority Warning. Therefore they can be rate limited by adding "loglvl=error/warning" to the hypervisor command line or suppressed entirely by adding "loglvl=error". On systems where the guest kernel is controlled by the host rather than guest administrator, running only kernels which do not call these hypercalls will also prevent untrusted guest users from exploiting this issue. However untrusted guest administrators can still trigger it unless further steps are taken to prevent them 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. CREDITS ======= This issue was discovered by Jan Beulich of SUSE. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa152-unstable.patch xen-unstable, Xen 4.6.x xsa152-4.5.patch Xen 4.5.x, Xen 4.4.x, Xen 4.3.x $ sha256sum xsa152*.patch 596f51797aa591b5abd068ead03e21215cf70997c98a4a562392499afe47b81c xsa152.patch 7ae2811ea80da29ee234ad5a2cbb5908e03db8fb6c50774d378d77d273e74e39 xsa152-4.5.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----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJWMgm/AAoJEIP+FMlX6CvZzPwIAJs/NTew5AJA3bTO6QZtVC2T sRt2F11prjjeklrAcqSC03q2bBpyylLB6PJ1jmmtT0MKtST5BszGA+sJt3G8nxw1 XKN8zNX5Yzfmltgi6ZeWk/1ps6kceb4evhkIUzt1v8Ttge148rEedGrJD9eLeRht XdZr8ujXwP3NGBAesKNf0DugPTR7diYyUzvwven+OXVPg0ZT53t1r6Xref7Vl4p6 5b9uOK3rh/QVRbPGTOA1vzObk0MssBTGA615JGG0da4fr4vVUQsVK/MV/N6oc4fJ iUHUcH83ldLGB9kt3+kq1S6KBESInriytPrKxNFvaKOrPlaOTOKRGvJSW0QZpos= =BsWE - -----END PGP SIGNATURE----- - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2015-7972 / XSA-153 version 3 x86: populate-on-demand balloon size inaccuracy can crash guests UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= The design of the memory populate-on-demand (PoD) system requires that a guest's memory ballooning driver reach its memory reduction target. The target is not entirely well-defined in terms of the information visible to the appropriate parts of the system, so some unknown set of guests (but probably most guests) will fail this criterion. If the guest memory balloon driver does not free sufficient memory to reach its target, the guest will proceed to run with a nonzero number of outstanding PoD pages. When the guest or management toolstack touches such a page, the hypervisor would search the guest memory for a page containing only zeroes. If no such page is found, the guest crashes. Prior to the patch for XSA-150, the search might lock up the relevant physical cpu for a while. After the patch to XSA-150, it might crash the guest even if a suitable zero page is available. This means that in the current arrangements toolstack software must apply an adjustment to a guest's PoD target as supplied to Xen. Neither xend nor libxl do this. IMPACT ====== Guests configured with PoD might be unstable, especially under load. In an affected guest, an unprivileged guest user might be able to cause a guest crash, perhaps simply by applying load so as to cause heavy memory pressure within the guest. This problem also allows an unprivileged guest user to exercise the separate vulnerability described in XSA-150: an unprivileged guest user might be able to cause a denial of service affecting the host. VULNERABLE SYSTEMS ================== The vulnerability is restricted to HVM guests which have been constructed in Populate-on-Demand mode (ie, with memory < maxmem). ARM is not vulnerable. x86 PV VMs are not vulnerable. x86 HVM domains without PoD (ie started with memory==maxmem, or without mentioning "maxmem" in the guest config file) are not vulnerable. Systems using libxl (whether via xl, or libvirt, or another higher layer) or xend (whether via xm, or libvirt, or another higher layer) are vulnerable. If the system has been stress-tested (by imposing memory load on the guest) and found to be stable, it is less likely that the guest is vulnerable. Combinations of Xen, guest, guest balloon driver, and toolstack software, which have an empirical adjustment as described in the Description, and which have been formally stress-tested in PoD mode, are less likely to be vulnerable. Migration is not capable of creating a guest with outstanding PoD. So migrating a guest which is vulnerable might crash it. However, if a guest has been migrated successfully since it booted, it is no longer vulnerable. Xen versions back to 3.4.x are affected. Vulnerability of a particular guest can be tested by the host administrator using the utility `xsa153-check.c', attached to this advisory. MITIGATION ========== Reducing the guest's memory target, after guest startup, can cause the guest's ballon driver to eliminate the PoD discrepancy. If the guest successfully balloons down, it will no longer be vulnerable. On systems using libxl this can be done with `xl mem-set', during or after each guest boot: # ./xsa153-check `xl domid name-of-guest` checked domain 621 for XSA-153: VULNERABLE (1 more outstanding pages) try using xl mem-set to reduce its memory by 1 (Mby) or perhaps reduce /local/domain/621/memory/target by 4 # xl list name-of-guest Name ID Mem VCPUs State Time(s) name-of-guest 621 512 2 r----- 156.9 # xl mem-set name-of-guest 511 # [ wait for guest to give up memory ] # ./xsa153-check `xl domid name-of-guest` checked domain 621 for XSA-153: NOT vulnerable # Alternatively, no matter the toolstack, it is possible for a host administrator to bypass the toolstack code and give ballooning instructions directly to the guest: [ suppose guest domid is 616, eg from xl domid name-of-guest ] # ./xsa153-check 616 checked domain 616 for XSA-153: VULNERABLE (1 more outstanding pages) try using xl mem-set to reduce its memory by 1 (Mby) or perhaps reduce /local/domain/616/memory/target by 4 # xenstore-read /local/domain/616/memory/target 520188 # xenstore-write /local/domain/616/memory/target 520184 # [ wait for guest to give up memory ] # ./xsa153-check `xl domid name-of-guest` checked domain 616 for XSA-153: NOT vulnerable # The memory/target value is in decimal, and is a number of kilobytes; it must be a multiple of 4, since a page is 4 Kb on affected systems. The value to write should be some amount less than the value read. It is not currently known whether use of the VM memory event inspection facilities (in-tree, this means the xc_monitor utility) might invalidate the workaround. Note that guests may become unstable if given too little memory, so large reductions of the memory target should be applied with caution, if at all. The expected offset related to XSA-153 is small (tens of pages, perhaps). If a large reduction is required, it is more likely that either the guest is still booting up (and still working to reduce the PoD memory), or that the guest's balloon driver is not functioning: # ./xsa153-check `xl domid name-of-guest` checked domain 623 for XSA-153: VULNERABLE (65536 more outstanding pages) difference is >1Mby ballon driver not running or guest still booting? # A guest without a working balloon driver will be unstable in PoD mode, especially under memory pressure; this is an inherent feature of the design of PoD. RESOLUTION ========== The attached patch fixes the problem for systems using libxl (via xl, or via libvirt, or another higher layer). At the time of writing there is no patch for xend-based systems. xsa153-libxl.patch xen-unstable, Xen 4.5, Xen 4.6 xsa153-libxl.patch Xen 4.1 to 4.4 inclusive, using libxl (Xend was removed in Xen 4.5; so the libxl-only patch is always sufficient for Xen 4.5 and later.) $ sha256sum xsa153* 633df5d970af49476c2d279e604150c444834bb906f6568070f0c2e0ceaa3af4 xsa153-check.c f5cbc98cba758e10da0a01d9379012ec56b98a85a92bfeb0c6b8132d4b91ce77 xsa153-libxl.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 NOTE REGARDING SHORT EMBARGO ============================ This issue was quickly encountered by the Security Team during our investigations of the scope and impact of XSA-150; this issue was originally discussed in the `Incomplete Information' section of XSA-150 v1. Accordingly XSA-153 is embargoed and the embargo will end at the same time as that of XSA-150. - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJWMgofAAoJEIP+FMlX6CvZaqUIAIzgbftJMwo2ywcWycAGzeDS 5iseCaCqx1OD8a00m+WvXTLX/yKKJQrgTJkDlJfgqEb4Y2NoVRUKShApSHsbFrFa qeocl7ipBdXTYk0FZZrsBd/aCjQgL/NlYf0BCaV+tpPuehOBgJwWpIf4RltOQVkv MxfRCGee52yUbWyFykmlKK3fxfGi4wXfMGN6zS9FXpudIBxjedRS4gyksERusXS7 hcRNEcLNzeQA+4PUmpkOzwS/NrtWiIU265kaHFsMUO8HbxcFgzFJ+15G0GK8JgY5 9XE0XWxn/B5Uc7IMiDxcFYT79C87XXvH4ctFArN9MJqss/ko0H25fz+Te8iWigc= =vBPN - -----END PGP SIGNATURE----- - --------------------------END INCLUDED TEXT-------------------- You have received this e-mail bulletin as a result of your organisation's registration with AusCERT. The mailing list you are subscribed to is maintained within your organisation, so if you do not wish to continue receiving these bulletins you should contact your local IT manager. If you do not know who that is, please send an email to auscert@auscert.org.au and we will forward your request to the appropriate person. NOTE: Third Party Rights This security bulletin is provided as a service to AusCERT's members. As AusCERT did not write the document quoted above, AusCERT has had no control over its content. The decision to follow or act on information or advice contained in this security bulletin is the responsibility of each user or organisation, and should be considered in accordance with your organisation's site policies and procedures. AusCERT takes no responsibility for consequences which may arise from following or acting on information or advice contained in this security bulletin. NOTE: This is only the original release of the security bulletin. It may not be updated when updates to the original are made. If downloading at a later date, it is recommended that the bulletin is retrieved directly from the author's website to ensure that the information is still current. Contact information for the authors of the original document is included in the Security Bulletin above. If you have any questions or need further information, please contact them directly. Previous advisories and external security bulletins can be retrieved from: http://www.auscert.org.au/render.html?cid=1980 =========================================================================== Australian Computer Emergency Response Team The University of Queensland Brisbane Qld 4072 Internet Email: auscert@auscert.org.au Facsimile: (07) 3365 7031 Telephone: (07) 3365 4417 (International: +61 7 3365 4417) AusCERT personnel answer during Queensland business hours which are GMT+10:00 (AEST). On call after hours for member emergencies only. =========================================================================== -----BEGIN PGP SIGNATURE----- Comment: http://www.auscert.org.au/render.html?it=1967 iQIVAwUBVjcIz36ZAP0PgtI9AQJDLRAAiZDJ8YuDYaugjGtiihmV4HTtjUMZAQbq MgTtJ1xbKGgEXj9o/5WsNhx3LWk77Vu0B+C5HKOvRiGNiE7iK/YaJkR9/BNsJeSz tBJx+PwmmqAgOUaf4Fk+GNf67VYPzazLqHHXH2zHWMpTLNbe1Hw7Y00Q2RC8gp+p hAkxeUxF/nipcWZF+xM5LQ9IQtkGSU8svVQHmm/Or6NgrKE8eTtmURtQLVlvnxP+ V9kJ3VSM3e0bqdmV1lzIbniaqfxbmrh2QWIwCadIXHT77JqqfGWm+XkUPtygoz1k Nsb/BvYZPo+nIBB4daR8E9bJv+QUkcuJi+9SuRFP+1y6GKl/WaFAay8EK+QtWaeo HDdBUI1Xzn1jtcLccz0XVs2KmRdoM+WXXB2iTL/pW+H2Huei0hBuy8n6MdDI69s0 jPS9nNIPkeKFDcSB+Y6Ku4RUMmAv+k/SZGfVHkrnPQe2iR84R9KigpwK4VmWkE9n hQCC0gW2XNcMbv6YlXr4GsE4XK7VaWV/4Pbt6PtPalcGeebEMdk92MTq36V2DKDT dEEhMtfQtSD5TxLCSqixarQjJh4LmSXfpsSEqj7csJ3HlgxHuy3/+MbTCNb3IpXv XH6bT4LnHP7Ylkvkc8u4TnuzWtlpdyE9tJu08A+RWYPokvdUU1LcN7lxuu8pwWIF 8IhSX/mVMbY= =EzdE -----END PGP SIGNATURE-----