|Public release ||2015-12-17 12:00|
|Updated ||2015-12-17 12:38|
|Title ||qemu-dm buffer overrun in MSI-X handling|
Filesadvisory-164.txt (signed advisory file)
-----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory CVE-2015-8554 / XSA-164
qemu-dm buffer overrun in MSI-X handling
UPDATES IN VERSION 3
"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.
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.
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.
Not passing through MSI-X capable devices to HVM guests will avoid this
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.
This issue was discovered by Jan Beulich of SUSE.
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*
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
(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:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
-----END PGP SIGNATURE-----
Xenproject.org Security Team