Kurt Seifried
2013-Sep-10 16:31 UTC
Re: [oss-security] Xen Security Advisory 61 - libxl partially sets up HVM passthrough even with disabled iommu
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/10/2013 04:56 AM, Xen.org security team wrote:> Xen Security Advisory XSA-61 > > libxl partially sets up HVM passthrough even with disabled iommu > > 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. > > 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.patchPlease use CVE-2013-4329 for this issue. - -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBAgAGBQJSL0lgAAoJEBYNRVNeJnmTpKoP/RlZ1GcBYEZ/MAhKCgxitY0v COlxa8gXcfPx6wbf4BOwn15/+lIYW7VRAdTU5AeGjEag0GpOdXIXkI3VJM1VYuYS 7fpjPAIaSPHHuccONMl5B5kR3IQIh9DLSlBY8TEZY9ZJALvb70cEnHibuC+6IDb6 tnWOAOT+I6sRd1WcYyPGxjz5Q5D29fid34js767+2eCB+aPTPiuEu0MXvWOONjv7 CHjFGyrwrbDyOyi5ly3VqluVXho4p+S4U8UsnMZ7bR4wT9QCZiZ6xi+Ay/XZxQJK jgnIJOBjfFFrIiOYOr6v/lambXOnaEZDKRJ9XBTXKkc2uO3iHO/h7aBIBRvO9x4H V/TqH0XX1+DUWh60tLmBgtnEuBRek73+HuiejquhtUEKhAFsz23B7Sgnc8llIuAQ OvEU3Clfh79byZaA7HxEQOK6YEJC7tj5K9u/DxsJDr/QZqod3Q7eXNtW2Vobohpe GXDKJhQ3DnmtETPj34FsSZPRBaEfqv1qjRKpFugE117WhfRGmXY8o3dgsLmJv+GK c3BbSq3RCCNrss0fUQWzyjUb1qGSFlPoxPi3t5RT+fzEAdAPi5IdKrFfBB7kQH5J 4zxEn15qQG0RPK2n2RkDg9kKKMDO2UmVKN4OpyUpEmIsfHHpkWcNH2pfU4t18xAW flXo4tBjVrPv1jYNtg1T =VF8t -----END PGP SIGNATURE-----