Date: Thu, 17 Dec 2015 12:42:26 +0000 From: Xen.org security team <security@....org> To: xen-announce@...ts.xen.org, xen-devel@...ts.xen.org, xen-users@...ts.xen.org, oss-security@...ts.openwall.com CC: Xen.org security team <security@....org> Subject: Xen Security Advisory 164 (CVE-2015-8554) - qemu-dm buffer overrun in MSI-X handling -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2015-8554 / XSA-164 version 3 qemu-dm buffer overrun in MSI-X handling UPDATES IN VERSION 3 ==================== Public release. 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: Xen unstable, 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----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJWcqy+AAoJEIP+FMlX6CvZldwH/RpMzmRhI6lFR02GKXXC+87V Yb2d8au5C/yxYED23WhIW+zPajaNjcpu73xgRqc+mNYSyGOOcmCWEF7nSp4tSHC7 XpF8EXPXFtOYSWuxnn38tL+bqs+sa+Ju5koqxkMzKsYM+TgKvUdtoCqEi7uElJ5y wX3HCyBH0zTX+YMbN32DYihwTRTdDBNXqEhDZcULSkvrKWlYlfJGUJus50JBMZFF THIf6mFZp2VZoHtc14xz4aMzDX8MmK+Xq+jMrMLM56oj9OmAShw4a3Glxbzzla7r H7YFCH2OwrBPCDXWL2DF2LY/pQicIQfVZ1QWHOAMIbKL3icmMwlbINx15Dc0YHE= =KYw9 -----END PGP SIGNATURE----- [ CONTENT OF TYPE application/octet-stream SKIPPED ]
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ