==================================================================== CERT-Renater Note d'Information No. 2012/VULN349 ____________________________________________________________________ DATE : 10/09/2012 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S) : Systems running Xen. ====================================================================== http://lists.xen.org/archives/html/xen-announce/2012-09/msg00000.html http://lists.xen.org/archives/html/xen-announce/2012-09/msg00001.html http://lists.xen.org/archives/html/xen-announce/2012-09/msg00002.html http://lists.xen.org/archives/html/xen-announce/2012-09/msg00006.html http://lists.xen.org/archives/html/xen-announce/2012-09/msg00003.html http://lists.xen.org/archives/html/xen-announce/2012-09/msg00005.html http://lists.xen.org/archives/html/xen-announce/2012-09/msg00004.html ______________________________________________________________________ Xen Security Advisory CVE-2012-3494 / XSA-12 version 3 hypercall set_debugreg vulnerability UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= set_debugreg allows writes to reserved bits of the DR7 debug control register on x86-64. IMPACT ====== A malicious guest can cause the host to crash, leading to a DoS. If the vulnerable hypervisor is run on future hardware, the impact of the vulnerability might be widened depending on the future assignment of the currently-reserved debug register bits. VULNERABLE SYSTEMS ================== All systems running 64-bit paravirtualised guests. The vulnerability dates back to at least Xen 4.0. 4.0, 4.1, the 4.2 RCs, and xen-unstable.hg are all vulnerable. MITIGATION ========== This issue can be mitigated by ensuring (inside the guest) that the kernel is trustworthy, or by running only 32-bit or HVM guests. RESOLUTION ========== Applying the appropriate attached patch will resolve the issue. PATCH INFORMATION ================= The attached patch resolves this issue: Xen unstable, 4.1 and 4.0 xsa12-all.patch $ sha256sum xsa12-all.patch 2415ee133e28b1c848c5ae3ce766cc2a67009bad8d026879030a6511b85dbc13 xsa12-all.patch ______________________________________________________________________ Xen Security Advisory CVE-2012-3495 / XSA-13 version 3 hypercall physdev_get_free_pirq vulnerability UPDATES IN VERSION 3 ==================== Public release. Credit Matthew Daley. ISSUE DESCRIPTION ================= PHYSDEVOP_get_free_pirq does not check that its call to get_free_pirq succeeded, and if it fails will use the error code as an array index. IMPACT ====== A malicious guest might be able to cause the host to crash, leading to a DoS, depending on the exact memory layout. Privilege escalation is a theoretical possibility which cannot be ruled out, but is considered unlikely. VULNERABLE SYSTEMS ================== All Xen systems. Xen 4.1 is vulnerable. Other versions of Xen are not vulnerable. MITIGATION ========== This issue can be mitigated by ensuring (inside the guest) that the kernel is trustworthy and avoiding situations where something might repeatedly cause the attempted allocation of a physical irq. RESOLUTION ========== Applying the appropriate attached patch will resolve the issue. CREDIT ====== Thanks to Matthew Daley for finding this vulnerability (and that in XSA-12) and notifying the Xen.org security team. PATCH INFORMATION ================= The attached patches resolve this issue Xen 4.1, 4.1.x xsa13-xen-4.1.patch $ sha256sum xsa13-*.patch ad6e3e40ff56c7c25a94d8d9763d4b49f07802b90b4362ddbe4c86bf285c1239 xsa13-xen-4.1.patch ______________________________________________________________________ Xen Security Advisory CVE-2012-3496 / XSA-14 version 3 XENMEM_populate_physmap DoS vulnerability UPDATES IN VERSION 3 ==================== Public release. Credit Matthew Daley. ISSUE DESCRIPTION ================= XENMEM_populate_physmap can be called with invalid flags. By calling it with MEMF_populate_on_demand flag set, a BUG can be triggered if a translating paging mode is not being used. IMPACT ====== A malicious guest kernel can crash the host. VULNERABLE SYSTEMS ================== All Xen systems running PV guests. Systems running only HVM guests are not vulnerable. The vulnerability dates back to at least Xen 4.0. 4.0, 4.1, the 4.2 RCs, and xen-unstable.hg are all vulnerable. MITIGATION ========== This issue can be mitigated by ensuring that the guest kernel is trustworthy or by running only HVM guests. RESOLUTION ========== Applying the appropriate attached patch will resolve the issue. CREDIT ====== Thanks to Matthew Daley for finding this vulnerability (and that in XSA-12) and notifying the Xen.org security team. PATCH INFORMATION ================= The attached patches resolve this issue xen-unstable xsa14-unstable.patch Xen 4.1, 4.1.x, 4.0, 4.0.x, 3.4 and 3.4.x xsa14-xen-3.4-and-4.x.patch $ sha256sum xsa14-*.patch 7a2e119b114708420c3484ecc338c7a198097f40e0d38854756dfa69c4c859a8 xsa14-unstable.patch 41a1ee1da7e990dc93b75fad0d46b66a2bda472e9aa288c91d1dc5d15d2c2012 xsa14-xen-3.4-and-4.x.patch ______________________________________________________________________ Xen Security Advisory CVE-2012-3497 / XSA-15 version 2 multiple TMEM hypercall vulnerabilities UPDATES IN VERSION 2 ==================== Public release. Credit Matthew Daley. ISSUE DESCRIPTION ================= Several sub-operations of the Transcendent Memory (TMEM) hypercall either do not correctly validate their inputs, do not correctly validate the privilege of the calling guest, or have other security-relevant bugs. A full list of the vulnerabilities in the TMEM system is not available at present. IMPACT ====== An unprivileged guest can overwrite hypervisor owned memory with the content of their choosing allowing them to escalate their privilege to that of the host. In addition an unprivileged guest can also crash the hypervisor, leading to a Denial of Service attack. VULNERABLE SYSTEMS ================== ONLY installations where "tmem" is specified on the hypervisor command line are vulnerable. Most Xen installations do not do so. All versions of Xen from 4.0 onward which have TMEM enabled and are running guests with untrusted administrators are vulnerable. Although we consider it unlikely, we have not been able to rule out the possibility that an malicious unprivileged user could exploit these issues via a trusted TMEM-aware kernel. Therefore all administrators are advised to disable TMEM even if all guest kernels are controlled and trusted. MITIGATION ========== Only systems which have TMEM enabled at boot time are affected by this issue. By default TMEM is disabled unless it is explicitly enabled via the hypervisor command line option "tmem". TMEM has been described by its maintainers as a technology preview, and is therefore not supported by them for use in production systems. Pending a full security audit of the code, the Xen.org security team recommends that Xen users do not enable TMEM. RESOLUTION ========== Work is ongoing, by the community maintainers for TMEM, to patch the specific bugs as they are found. This includes both the multiple vulnerabilities initially reported to the Xen.org security team, and multiple further vulnerabilities which have been discovered since then during our ad-hoc code inspection. At the time of writing, a complete set of fixes even for known issues is not available. PROCESS FOR TMEM VULNERABILITIES ================================ Until TMEM has gained production maturity, the Xen.org security team intends (subject of course to the permission of anyone disclosing to us) to handle these and future TMEM vulnerabilities in public, as if they were normal non-security-related bugs. We therefore intend that currently-known vulnerabilities will be publicly disclosed on the xen-devel mailing list, as normal bug reports, at the expiry of the XSA-15 embargo. In the meantime the list below may be helpful. Xen.org security team will ensure, on expiry of the embargo, that the documentation reflects TMEM's technology preview status. CREDIT ====== Thanks to Matthew Daley for finding these vulnerabilities (and that in XSA-12) and notifying the Xen.org security team. LIST OF KNOWN VULNERABILITIES ============================= **NOTE** that this is unlikely to be a complete list of problems. **NOTE** that after publication of this advisory, after the embargo ends, the advisory will no longer be updated to extend this list of vulnerabilities. See `Process for TMEM vulnerabilities', above. Multiple tmem save-related control ops do not check for NULL clients: TMEMC_SAVE_GET_CLIENT_WEIGHT, TMEMC_SAVE_GET_CLIENT_CAP, TMEMC_SAVE_GET_CLIENT_FLAGS and TMEMC_SAVE_END do not check that the cli_id used to find the client is valid, and can hence dereference a NULL client. This allows a malicious guest to crash the host (DoS), or, in the case of TMEMC_SAVE_END, memory corruption (DoS or worse). Multiple tmem save-related control ops do not check guest output buffer pointers: The functions tmemc_save_get_next_page, tmemc_save_get_next_inv and the TMEMC_SAVE_GET_POOL_UUID subop do not check incoming guest output buffer pointers, and do not use ie. copy_to_guest. A malicious guest can crash the host or cause memory corruption (DoS / code execution). Multiple tmem ops do not check for negative pool IDs: The functions tmemc_save_get_next_page, tmemc_restore_put_page and tmemc_restore_flush_page do not check for negative pool IDs, allowing (at least) memory corruption. do_tmem_destroy_pool does not check for invalid pool IDs: The function do_tmem_destroy_pool does not check for invalid pool IDs, allowing a malicious guest to crash the host or corrupt host memory (DoS / code execution). do_tmem_control's privilege check is commented out: This allows any guest access to control stack operations (many of which themselves do not have adequate argument checking). tmh_copy_from_client and tmh_copy_to_client have an integer overflow vulnerability: This can corrupt host memory. do_tmem_get()'s bad_copy error path leaves a spinlock held: The next operation on the same object will hang the CPU. This is a host DoS. do_tmem_op has at least one error path with broken locking checks: This is a host DoS or worse. ______________________________________________________________________ Xen Security Advisory CVE-2012-3515 / XSA-17 version 2 Qemu VT100 emulation vulnerability UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= The device model used by fully virtualised (HVM) domains, qemu, does not properly handle escape VT100 sequences when emulating certain devices with a virtual console backend. IMPACT ====== An attacker who has sufficient privilege to access a vulnerable device within a guest can overwrite portions of the device model's address space. This can allow them to escalate their privileges to that of the device model process. VULNERABLE SYSTEMS ================== All Xen systems running HVM guests are potentially vulnerable to this depending on the specific guest configuration. The default configuration is vulnerable. Guests using either the traditional "qemu-xen" or upstream qemu device models are vulnerable. MITIGATION ========== This issue can be avoided by only running PV guests or by configuring HVM guests to not use the virtual console('vc') backend for any device. For serial devices specify in your guest configuration: serial = 'none' in your guest configuration. For parallel port devices the syntax is toolstack specific. For xend specify in your guest configuration: parallel = 'none' For xl specify in your guest configuration: xl: device_model_args = ['-parallel', 'none'] In both cases the default is to use the vulnerable 'vc' mode. You can confirm whether or not you are vulnerable by pressing Ctrl-Alt- (for digit N) while connected to either the VNC or SDL console. If you are able to switch to a window displaying "serial" or "parallel" then you are vulnerable. The issue can also be mitigated by enabling the stub domain device model. In this case the attacked can only potentially gain control of the stub domain and not of the entire system. To enable stub domains specify in your guest configuration: device_model = "stubdom-dm" RESOLUTION ========== Applying the appropriate attached patch(es) will resolve the issue. PATCH INFORMATION ================= The attached patches resolve this issue Traditional qemu tree Xen 4.0, 4.1 and unstable xsa17-qemu-xen-traditional-all.patch Upstream qemu tree (present in unstable only) Xen unstable xsa17-qemu-xen-unstable.patch $ sha256sum xsa17-*.patch 60215322d3fbbc2054dfc160a20d9e0811af88487c4edc2f6ea81dcd5cedf039 xsa17-qemu-xen-traditional-all.patch 7b4bb59e7757080e7806a8b8eeb6b78fa0ffdfbfb28a7a379f7edff285bffd88 xsa17-qemu-xen-unstable.patch ______________________________________________________________________ Xen Security Advisory CVE-2012-3498 / XSA-16 version 3 PHYSDEVOP_map_pirq index vulnerability UPDATES IN VERSION 3 ==================== Public release. Credit Matthew Daley. ISSUE DESCRIPTION ================= PHYSDEVOP_map_pirq with MAP_PIRQ_TYPE_GSI does not range check map->index. IMPACT ====== A malicious HVM guest kernel can crash the host. It might also be able to read hypervisor or guest memory. VULNERABLE SYSTEMS ================== All Xen systems running HVM guests. PV guests are not vulnerable. The vulnerability dates back to Xen 4.1. Xen 4.0 is not vulnerable. 4.1, the 4.2 RCs, and xen-unstable.hg are vulnerable. MITIGATION ========== This issue can be mitigated by ensuring that the guest kernel is trustworthy, or by running only PV guests. RESOLUTION ========== Applying the appropriate attached patch will resolve the issue. CREDIT ====== Thanks to Matthew Daley for finding this vulnerability (and that in XSA-12) and notifying the Xen.org security team. PATCH INFORMATION ================= The attached patches resolve this issue Xen unstable xsa16-unstable.patch Xen 4.1, 4.1.x xsa16-xen-4.1.patch $ sha256sum xsa16-*.patch f8db42898620112c8e77bf116645d650b3671d4ccc49adcad09c7b4591d55cab xsa16-unstable.patch 4b76d554b23977443209e45d3a2404d63695eb3020ff87a8e16e5e25cbddff31 xsa16-xen-4.1.patch ______________________________________________________________________ Xen Security Advisory CVE-2012-3516 / XSA-18 version 2 grant table entry swaps have inadequate bounds checking UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= The grant table hypercall's GNTTABOP_swap_grant_ref sub-operation does not perform adequate checks on the input grant references. IMPACT ====== A malicious guest kernel or administrator can crash the host. It may be possible for an attacker to swap a valid grant reference, which they control, with an invalid one allowing them to write abitrary values to hypervisor memory. This could potentially lead to a privilege escalation. VULNERABLE SYSTEMS ================== Xen-unstable, including Xen 4.2 release candidates are vulnerable to this issue. Xen 4.1 and earlier do not include this hypercall and are therefore not vulnerable. MITIGATION ========== The only mitigation is not to run guests which have untrusted administrators. RESOLUTION ========== Applying the attached patch will resolve the issue. PATCH INFORMATION ================= The attached patch resolves this issue Xen unstable xsa18-unstable.patch $ sha256sum xsa18-unstable.patch ad354a1964fc52b0e48d405514156935cc8dfcb5bdaee307e3e74afcc0ca8914 xsa18-unstable.patch ====================================================================== ========================================================= Serveur de référence du CERT-Renater https://services.renater.fr/ssi/ ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23 - 25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email: certsvp@renater.fr + =========================================================