Date: Tue, 08 Dec 2015 12:01:12 +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 158 (CVE-2015-8338) - long running memory operations on ARM -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2015-8338 / XSA-158 version 3 long running memory operations on ARM UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= Certain HYPERVISOR_memory_op subops take page order inputs, with so far insufficient enforcement of limits thereof. In particular, for all of XENMEM_increase_reservation, XENMEM_populate_physmap, and XENMEM_exchange the order was limited to 9 only for guests without physical devices assigned. Guests with assigned devices were allowed up to order 18 (x86) or 20 (ARM). XENMEM_decrease_reservation enforced only the latter, higher limit uniformly on all kinds of guests. All of these operations involve loops over individual pages (possibly nested, with only the iteration count of the innermost loop being of interest here), resulting in iteration counts of up to 1 million on ARM. Total execution time of these operations obviously depends on system speed, but have been measured to get into the seconds range. IMPACT ====== A malicious guest administrator can cause a denial of service. Specifically, prevent use of a physical CPU for a significant period. Other attacks, namely privilege escalation, cannot be ruled out. 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. VULNERABLE SYSTEMS ================== All Xen versions supporting ARM are affected. x86 versions of Xen are unaffected. 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. On ARM, controlling the guest's kernel may involve locking down the bootloader. Exposure may be limited by not passing through physical devices to untrusted guests. (However, where device pass-through is being used to enhance security, for example, by disaggregating device drivers, users should not change their configuration: moving the drivers from a separate domain, to dom0, does NOT mitigate this vulnerability. Rather, it simply recategorises the additional exposure, regarding it "as designed" and therefore "not a bug". Users and vendors of disaggregated systems should not change their configuration.) CREDITS ======= This issue was discovered by Julien Grall of Citrix. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa158.patch xen-unstable, Xen 4.6.x, Xen 4.5.x xsa158-4.4.patch Xen 4.4.x, Xen 4.3.x $ sha256sum xsa158* 50d7431cbad8faa631e2057ddd795b880f79b96d126a0b83afef3eceacf0026d xsa158.patch 54b538905e66227bf7f326006a7c322bdf35c76ad8600ff462e61d6e2eab6f04 xsa158-4.4.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 NO PASS-THROUGH partial 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 altering the set of devices observable in a guest 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) iQEcBAEBAgAGBQJWZr8FAAoJEIP+FMlX6CvZS7UIAKtjK/KGZxAv3L38qTlldHhF BAYuZvlDt4wJEKYd9wUbN5nqXAL23muKj+oOLjS4PRHnsNKAjyKicJEFDIpLGr9z fLKqmWvxnDexP3tjiUqz5z8IOpGTMgFPPl9kosYXhBiQAIrrlTigL+umYSGlIsB1 MkLfW1ZST3H7eoBzNkFEpGsMTjAtnYJfYwZp2MLC8sbdNq04RWbiIqljEb61ULdi CXAFoiVcDiNbRrT2LRFwfAIM2mtzi6Me0GUMmGrdsfg0rlmgxHVItPLEd8fZ1CTE ChqUOCZfL9DH3zlBgqD+0oADxhfwbHHnsu2Mvy0MzgwTZ7zX+12eer89qwvtgwA= =AIko -----END PGP SIGNATURE----- Download attachment "xsa158.patch" of type "application/octet-stream" (7650 bytes) Download attachment "xsa158-4.4.patch" of type "application/octet-stream" (7449 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.