-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2013-4329 / XSA-61 version 2 libxl partially sets up HVM passthrough even with disabled iommu UPDATES IN VERSION 2 ==================== CVE number assigned. Clarified fixed status of Xen 4.2.3 and 4.1.6.1. ISSUE DESCRIPTION ================= With HVM domains, libxl's setup of PCI passthrough devices does the IOMMU setup after giving (via the device model) the guest access to the hardware and advertising it to the guest. If the IOMMU is disabled the overall setup fails, but after the device has been made available to the guest; subsequent DMA instructions from the guest to the device will cause wild DMA. IMPACT ====== A HVM domain, given access to a device which bus mastering capable in the absence of a functioning IOMMU, can mount a privilege escalation or denial of service attack affecting the whole system. VULNERABLE SYSTEMS ================== 1. Only systems which pass busmastering-capable PCI devices through to untrusted guests are vulnerable. (Most PCI devices are busmastering-capable.) 2. Only systems which use libxl as part of the toolstack are vulnerable. The major consumer of libxl functionality is the xl toolstack which became the default in Xen 4.2. In addition to this libvirt can optionally make use of libxl. This can be queried with # virsh version which will report "xenlight" if libxl is in use. libvirt currently prefers the xend backend if xend is running. The xend and xapi toolstacks do not currently use libxl. 3. Only Xen versions 4.0.x through 4.2.x are vulnerable. Xen 4.1.6.1 and 4.2.3, however, have the issue already fixed. 4. Only HVM domains can take advantage of this vulnerability. 5. Systems which have a functioning IOMMU are NOT vulnerable. MITIGATION ========== This issue can be avoided by not assigning PCI devices to HVM guests when there is no functioning IOMMU. NOTE REGARDING LACK OF EMBARGO ============================== This issue was disclosed publicly on xen-devel; the person reporting it did not appreciate that it was a security issue. Additionally the patch to fix the issue was already applied to the respective branches (in particular resulting in Xen 4.3 not being vulnerable). Under the circumstances the Xen.org security team do not consider that this advisory should be embargoed. Also, we apologise for the delay to this advisory message, which was due to an oversight by us. CREDITS ======= George Dunlap found the issue as a bug, which on examination by the Xenproject.org Security Team turned out to be a security problem. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa61-4.1.patch Xen 4.1.x xsa61-4.2-unstable.patch Xen 4.2.x, xen-unstable $ sha256sum xsa61*.patch 19caa5f1ce91ebc908c899b8be216034dc67c3e890f59597f659caed41d468f6 xsa61-4.1.patch 5898926de86dd6a27f8e34a2c103e3d0c6267b1d7d947434f294423ed3b0eefd xsa61-4.2-unstable.patch $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJSMF5dAAoJEIP+FMlX6CvZODQH/36rIjMga0UcOVZhSp5ORRQw ImLuSKW9Mh0ZIc0hxtiRUx7YaLI4nQYw/x2w48IIdg/70QN1ukdPCFGWJ/y1bnBZ eL2VMA/zqoStVKF5hlwUTXJFsaa7b9zDawrG6ewkf0p5F84LkZl/T8vVwIZglK+l 3Cq6PK2dDcWz56DJ/pdDOgGgJa6yzkCH1uMfUHRR5DcbtQSFvKmmlb062tjB5Im+ FFxctUZiH+BldDTDQh73dfw6zvoWt8hYADD8hB/m+YB+8HsTFSLmtTfSQ5HTFq1j vWsVshjneWxIcyV9bj3vhVoCLn/VhtW+uPlmU/QFItqpbvMI+BucPdiww+Y3f40= =cL0+ -----END PGP SIGNATURE-----