Xen Security Advisory CVE-2015-8338 / XSA-158 version 2 long running memory operations on ARM *** EMBARGOED UNTIL 2015-12-08 12:00 UTC *** UPDATES IN VERSION 2 ==================== CVE assigned. 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.) 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* cddd4085f0b95e52250a5d7e50baa1b8753e9e8e21db2f4c7561a6bdfcf280ec xsa158.patch 4bca0702d45ca5a9ffff8d227ba1002c45435193abe988664a9bfe9914cee2c6 xsa158-4.4.patch $
Patches have been sent to the Xen Maintainers under xen security process.
commit ee95ed95448051233465b7e7005cf423de73a6e8 Author: Ian Delaney <idella4@gentoo.org> Date: Wed Dec 9 12:40:52 2015 +0800 app-emulation/xen: clean vulnerable vns. wrt #566842 #566844 commit c7ca943bfd7c509ec97d6a7fca2367320034fba7 Author: Ian Delaney <idella4@gentoo.org> Date: Wed Dec 9 10:48:14 2015 +0800 app-emulation/xen: revbumps -> vns. 4.5.2-r2, 4.6.0-r3 wrt sec. bugs Addition of patches XSA-158 (#566842), XSA-158 (#566844), 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. Line 3 of above commit should read Addition of patches XSA-158 (#566844), XSA-{159,160} (#566842), (this correct entry made in msg in commit in xen-tools)
Closing as noglsa.
