[kernel-xen] Xen Security Advisory 61 - libxl partially sets up HVM passthrough even with disabled iommu

[Steven Haigh]

Sorry guys - false alarm.

I double checked all this - even though the XSA was released *after* the
release of 4.2.3, I automatically assumed that it was vulnerable in
4.2.3 - however it is already included in 4.2.3.

Sorry for the noise.

On 10/09/13 21:34, Steven Haigh 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
> ==========
> 
> xen-4.2.3-2 is currently being built and will be distributed to the
> mirrors shortly.
> 
> 
> 
> _______________________________________________
> kernel-xen mailing list
> kernel-xen at lists.wireless.org.au
> https://lists.wireless.org.au/mailman/listinfo/kernel-xen
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://lists.wireless.org.au/pipermail/kernel-xen/attachments/20130910/d4ee9527/attachment.sig>