-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2015-8554 / XSA-164 version 4 qemu-dm buffer overrun in MSI-X handling UPDATES IN VERSION 4 ==================== Normalize version tags. ISSUE DESCRIPTION ================= "qemu-xen-traditional" (aka qemu-dm) tracks state for each MSI-X table entry of a passed through device. This is used/updated on (intercepted) accesses to the page(s) containing the MSI-X table. There may be space on the final page not covered by any MSI-X table entry, but memory for state tracking is allocated only for existing table entries. Therefore bounds checks are required to avoid accessing/corrupting unrelated heap memory. Such a check is present for the read path, but was missing for the write path. IMPACT ====== A malicious administrator of a guest which has access to a passed through PCI device which is MSI-X capable can exploit this vulnerability to take over the qemu process, elevating its privilege to that of the qemu process. In a system not using a device model stub domain (or other techniques for deprivileging qemu), the malicious guest administrator can thus elevate their privilege to that of the host. VULNERABLE SYSTEMS ================== Xen systems running x86 HVM guests with "qemu-xen-traditional", but without stubdomains, which have been passed through an MSI-X capable physical PCI device are vulnerable. The default configuration is NOT vulnerable from Xen 4.3 onwards (because it uses a newer upstream qemu version). Systems running only PV guests are NOT vulnerable. Only systems using PCI passthrough are vulnerable. Systems using "qemu-xen-traditional" stubdomain device models (for example, by specifying "device_model_stubdomain_override=1" in xl's domain configuration files) are NOT vulnerable. Only the traditional "qemu-xen-traditional" device model is vulnerable. Upstream qemu device models ("qemu-xen") are NOT vulnerable. ARM systems are NOT vulnerable. MITIGATION ========== Not passing through MSI-X capable devices to HVM guests will avoid this vulnerability. Running HVM guests with the default upstream device model will also avoid this vulnerability. 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. CREDITS ======= This issue was discovered by Jan Beulich of SUSE. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa164.patch qemu-xen-traditional master, 4.6.x, 4.5.x, 4.4.x, 4.3.x $ sha256sum xsa164* 40f7327aa414c77a0e18a305a144e4a720ba8fe1b618d2f3ad9d5f605667c340 xsa164.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 -----BEGIN PGP SIGNATURE----- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmV8b/IMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZIuIH/RjFgQoKRU0E9c7ay1qxqnuJ5lu3IcKAt1Cf1tKq WCtMrORiMXA00y2w5BdryeKF0iAT4+uMhtwNZE6putzVJhsntyocPVRf9jNA4diU BATkEJRv7GFTbaaew/3uY2bvUrxiSHd0Bmp+W81MrU9Myv/u8ikO80a5GsrxxCQM yi+PGP91/8a4ahp2tiJ+0QLK+0VH8BYOEXzZPAwIpsr8ypkDA7+8WC9X6NE40jEH wGht/IfeyKd7R/8QHMrMdOxUKwPiDoGll+9gJnzyUf64w+94w+YkbM0eoonGlgA5 NL0yU5zngP/slv4ANLCUWZL7ac4Fzc3FVWmrjiEzdg4s3MM= =4cod -----END PGP SIGNATURE-----