16 November 2015
Protect yourself against future threats.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 =========================================================================== AUSCERT External Security Bulletin Redistribution ESB-2015.2825 Xen Security Advisory CVE-2015-5307,CVE-2015-8104 / XSA-156 16 November 2015 =========================================================================== AusCERT Security Bulletin Summary --------------------------------- Product: Xen Publisher: Xen Operating System: Xen UNIX variants (UNIX, Linux, OSX) Impact/Access: Denial of Service -- Existing Account Resolution: Patch/Upgrade CVE Names: CVE-2015-8104 CVE-2015-5307 Reference: ESB-2015.2806.2 ESB-2015.2805 Original Bulletin: http://xenbits.xen.org/xsa/advisory-156.html - --------------------------BEGIN INCLUDED TEXT-------------------- - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2015-5307,CVE-2015-8104 / XSA-156 version 2 x86: CPU lockup during exception delivery UPDATES IN VERSION 2 ==================== Minor title and text adjustment. CVE-2015-8104 has been assigned for the problem with #DB. (The #AC issue remains CVE-2015-5307.) Public release. ISSUE DESCRIPTION ================= When a benign exception occurs while delivering another benign exception, it is architecturally specified that these would be delivered sequentially. There are, however, cases where this results in an infinite loop inside the CPU, which (in the virtualized case) can be broken only by intercepting delivery of the respective exception. Architecturally, at least some of these cases should also be resolvable by an arriving NMI or external interrupt, but empirically this has been determined to not be the case. The cases affecting Xen are: #AC (Alignment Check Exception, CVE-2015-5307): When a 32-bit guest sets up the IDT entry corresponding to this exception to reference a ring-3 handler, and when ring 3 code triggers the exception while running with an unaligned stack pointer, delivering the exception will re-encounter #AC, ending in an infinite loop. #DB (Debug Exception, CVE-2015-8104): When a guest sets up a hardware breakpoint covering a data structure involved in delivering #DB, upon completion of the delivery of the first exception another #DB will need to be delivered. The effects slightly differ depending on further guest characteristics: - - - Guests running in 32-bit mode would be expected to sooner or later encounter another fault due to the stack pointer decreasing during each iteration of the loop. The most likely case would be #PF (Page Fault) due to running into unmapped virtual space. However, an infinite loop cannot be excluded (e.g. when the guest is running with paging disabled). - - - Guests running in long mode, but not using the IST (Interrupt Stack Table) feature for the IDT entry corresponding to #DB would behave similarly to guests running in 32-bit mode, just that the larger virtual address space allows for a much longer loop. The loop can't, however, be infinite, as eventually the stack pointer would move into non-canonical address space, causing #SS (Stack Fault) instead. - - - Guests running in long mode and using IST for the IDT entry corresponding to #DB would enter an infinite loop, as the stack pointer wouldn't change between #DB instances. IMPACT ====== A malicious HVM guest administrator can cause a denial of service. Specifically, prevent use of a physical CPU for a significant, perhaps indefinite 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. It is possible that a guest kernel might expose the #AC vulnerability to malicious unprivileged guest users (by permitting #AC to be handled in guest user mode). However, we believe that almost all ordinary operating system kernels do not permit this; we are not aware of any exceptions. (A guest kernel which exposed the #AC vulnerability to guest userspace would be vulnerable when running on baremetal, without Xen involved.) VULNERABLE SYSTEMS ================== The vulnerability is exposed to any x86 HVM guest. ARM is not vulnerable. x86 PV VMs are not vulnerable. All versions of Xen are affected. x86 CPUs from all manufacturers are affected. MITIGATION ========== Running only PV guests will avoid this issue. Running only kernels which avoid exposing the #AC problem to userspace (as discussed in Impact) will prevent untrusted guest users from exploiting this issue. With such good kernels, the vulnerability can be avoided altogether 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. In Xen HVM, controlling the guest's kernel would involve locking down the bootloader. CREDITS ======= These issues were discovered by Ben Serebrin from Google and Jan Beulich from SUSE. RESOLUTION ========== To correctly support the intended uses of the relevant CPU features would require architectural changes to the CPU specification, design and implementation. This is not practical as a security response. Applying the appropriate attached patch works around the issue in software. xsa156.patch xen-unstable, Xen 4.6.x xsa156-4.5.patch Xen 4.5.x xsa156-4.4.patch Xen 4.4.x xsa156-4.3.patch Xen 4.3.x $ sha256sum xsa156*.patch ffc8153cdf4e69ff2feced6ea4988b594b5cb724e9909300209f9ae35fe0e618 xsa156-4.3.patch c2001aed46840b044a066b9ca79a8c53aca26fc637125016ccfebafa5ace5475 xsa156-4.4.patch af8edc5cfb2fe54d8c195b8748e80ffad0f32c37c50a16fa5005fec461cdb6ff xsa156-4.5.patch d92729ca9174f7d1d8c6fd31321d1a58696c0630e87420539c32f7718b9e8ee8 xsa156.patch $ NOTE REGARDING EMBARGO DURATION =============================== We have released this advisory as soon as possible after we obtained firm confirmation of the embargo end date from the discoverer. 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) iQEcBAEBAgAGBQJWQTU6AAoJEIP+FMlX6CvZpQMH/iNmCRPVz4H54WdWgiRJuNZV PrJFEITwxfOeaD84bQhxd0dXWqGnQvzPVScG5+qmWM6Bn533Gh2gkjKALHF8nltf usAuIgiXcHC0jv5m9/Z7+9t62mJkfnVhq0qdz/UEFO2VM8GbWCCArpUStvb/GetS sY7Rh1HV8p4nA5LOgvUgQc0yjCHoSfooyxkCNBBy31t5A33H4Se65pnKH/aRPH10 o4nX9NXxw2jN6XZ9bjACzm1KNPjDn1P5y/Zx5ccoHDQZHVYYHXMEgVSVnKEgriFL xPaFe0Att3RfBQtj9HAZJEE8YNy74m+28/GMIoCWU2FCwY6R86dDoVHU5hKiWRc= =z+MW - -----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 firstname.lastname@example.org 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: email@example.com 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 iQIVAwUBVklWA36ZAP0PgtI9AQKWSg/6AlcH7kDRvQu9SpptLfu7fVC1DK77xmFn FuwRbuyB+Z/aUAb1XjVn3ACEBYdGQ18hh6cTO/u1nb63GnjRtkACYA3WL1ctziaH zu/8gltWFH7voI+Eg8QSsh8UhLdA46fzzO4drVQOgP4CPfDZA9J+B7YA5FwNvT/M +ifWrkFUAlN7ijFlProFnShS3hWGBKP6BtHGMyupHzlwPH7VNWbsBaJX7WRut5rJ eCQATm2uyvbo43ckH1O0pRqygCiykEnY/wRoyfEch8PN4e2wF0zW0PGLQ5tw9KzD KUSilFC2RfMEo7Er0VElseBF1Om8mTW/IzYA4Yk/EM1nsXUGSkCuNnsbUtjOohCJ MiuSx0Fu1pfTbvqXyU5f1v0LeImW9Qg+I8zV7vMBRmOHzlDFjmLtt/RaVB0NlYGx inJbelcEylo09pBC6K7ZSz3e+Nn+pQXOkQ5fWn3WRktzzQtEELbgXA0LswXSr1Tl shqyRFx7Pr4W7OOtQBj0K3L3g40dUA59zOVo7iVLZyKMXgFECstYfu/xks8Z9iB4 sGK2SOeQocz2dlJogYgEnbEsl7X7t0eHU+cWaeZ0wzDPZ6JCSnlUH2Mv67AJKmwQ byGuB4pYdkLQRy8/676jINaZRjbM6pFD2yOXdZH1NEgelk4pAWMs/d5MbnPDsrim YTzuyPAxIkQ= =MEQA -----END PGP SIGNATURE-----