Date: Thu, 29 Oct 2015 12:00:35 +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 150 (CVE-2015-7970) - x86: Long latency populate-on-demand operation is not preemptible -----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----- [ CONTENT OF TYPE application/octet-stream SKIPPED ]
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ