[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] [oss-security] Xen Security Advisory 61 - libxl partially sets up HVM passthrough even with disabled iommu

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.patch

Please 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
Version: GnuPG v1.4.14 (GNU/Linux)


Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.