| Summary: | <app-emulation/xen-tools-{4.6.4-r3, 4.7.1-r3}: privilege escalation (XSA-199) | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Aaron Bauman (RETIRED) <bman> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | dlan |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | B2 [glsa cve glsa blocked] | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 601250 | ||
| Bug Blocks: | |||
commit aa0628e3a28bf1b07d198bb1ec54f144c90df40a Author: Yixun Lan <dlan@gentoo.org> Date: Sat Dec 3 11:46:00 2016 +0800 app-emulation/xen-tools: fix XSA-199 Gentoo-Bug: 600662 https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=aa0628e3a28bf1b07d198bb1ec54f144c90df40a This issue was resolved and addressed in GLSA 201612-56 at https://security.gentoo.org/glsa/201612-56 by GLSA coordinator Thomas Deutschmann (whissi). |
Xen Security Advisory CVE-2016-9637 / XSA-199 version 2 qemu ioport array overflow *** EMBARGOED UNTIL 2016-12-06 12:00 UTC *** UPDATES IN VERSION 2 ==================== CVE assigned. ISSUE DESCRIPTION ================= The code in qemu which implements ioport read/write looks up the specified ioport address in a dispatch table. The argument to the dispatch function is a uint32_t, and is used without a range check, even though the table has entries for only 2^16 ioports. When qemu is used as a standalone emulator, ioport accesses are generated only from cpu instructions emulated by qemu, and are therefore necessarily 16-bit, so there is no vulnerability. When qemu is used as a device model within Xen, io requests are generated by the hypervisor and read by qemu from a shared ring. The entries in this ring use a common structure, including a 64-bit address field, for various accesses, including ioport addresses. Xen will write only 16-bit address ioport accesses. However, depending on the Xen and qemu version, the ring may be writeable by the guest. If so, the guest can generate out-of-range ioport accesses, resulting in wild pointer accesses within qemu. IMPACT ====== A malicious guest administrator can escalate their privilege to that of the host. VULNERABLE SYSTEMS ================== PV guests cannot exploit the vulnerability. ARM systems are not vulnerable. HVM domains run with QEMU stub domains cannot exploit the vulnerability. (A QEMU stub domain is used if xl's domain configuration file contains "device_model_stubdomain_override=1".) Guests using the modern "qemu-xen" device model, with a qemu version of at least 1.6.0 (for example, as provided by the Xen Project in its Xen 4.4.0 and later releases), cannot exploit the vulnerability. x86 HVM guests, not configured with qemu stub domains, using a version of qemu older than qemu upstream 1.6.0, can exploit the vulnerability. x86 HVM guests using the traditional "qemu-xen-traditional", not configured with qemu stub domains, can therefore exploit the vulnerability. In tabular form: Guest Xen QEMU QEMU "traditional" Status type version stub and/or qemu version ARM any n/a n/a any OK x86 PV any n/a n/a any OK x86 HVM any yes qemu-xen-traditional OK x86 HVM any no qemu-xen* >= 1.6.0 OK x86 HVM >= 4.4 no qemu-xen* Xen supplied OK x86 HVM any no qemu-xen* < 1.6.0 Vulnerable x86 HVM <= 4.3 no qemu-xen* Xen supplied Vulnerable x86 HVM any no qemu-xen-traditional Vulnerable [*] qemu-xen is the default when qemu stub domains are not in use, since Xen 4.3. MITIGATION ========== Enabling stubdomains will mitigate this issue, by reducing the escalation to only those privileges accorded to the service domain. In a usual configuration, a service domain has only the privilege of the guest, so this eliminates the vulnerability. Running HVM guests with the default upstream device model, in Xen 4.4 and later, will also avoid this vulnerability. RESOLUTION ========== Applying the attached patch resolves this issue. xsa199-trad.patch qemu-xen-traditional, all versions $ sha256sum xsa199* 5d07f2fac30b85ed318d066c31c5f45fc4dacb6e52393e41659d89682b27a428 xsa199-trad.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patch described above (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 mitigations described above 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 in all cases the configuration change may be visible to the guest which could lead to the rediscovery of the vulnerability. 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