Re: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI

[Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx>]

Our paper describing the attacks can be now downloaded from here:

http://www.invisiblethingslab.com/itl/Resources.html

(Sorry the actual link contains spaces and would likely by unclickable
if I pasted it here).

Cheers,
joanna.

On 05/12/11 15:48, Ian Jackson wrote:
>              Xen security advisory CVE-2011-1898
>            VT-d (PCI passthrough) MSI trap injection
> 
> ISSUE DESCRIPTION
> =================
> 
> Intel VT-d chipsets without interrupt remapping do not prevent a guest
> which owns a PCI device from using DMA to generate MSI interrupts by
> writing to the interrupt injection registers.  This can be exploited
> to inject traps and gain control of the host.
> 
> 
> VULNERABLE SYSTEMS
> ==================
> 
> You are not vulnerable if you do not use "PCI passthrough".  That is,
> if you do not pass actual PCI devices (eg, graphics and network
> controllers) through to guests, for use by PCI device drivers in the
> guest.
> 
> In Xen with xend/xm or with xl this would be enabled by the "pci="
> option in the domain config file, or by using the "xl pci-attach" or
> "xm pci-attach" management command; if you do not use these features,
> you are not vulnerable.
> 
> You are not vulnerable if you are using PCI passthrough, but are not
> using Intel VT-d or AMD-Vi (aka "iommu") to attempt to prevent escape
> by guest DMA.  This is because in such a configuration, privilege
> escalation and denial of service are possible by guests anyway, and
> the present issue does not make the situation any worse.
> 
> You are vulnerable if you use Intel VT-d to pass PCI devices through
> to untrusted guests, unless your have interrupt remapping supported
> and enabled.  This is the case whether you are using Xen, KVM, or
> another virtualisation system.
> 
> Interrupt remapping is available in newer Intel VT-d chipsets.
> 
> 
> IMPACT
> ======
> 
> A guest given a PCI passthrough device can escalate its privilege and
> gain control of the whole system.
> 
> 
> MITIGATION AND RESOLUTION
> =========================
> 
> No complete software fix is available but we understand that Intel has
> addressed this issue with newer hardware.
> 
> We believe a patch along the lines of the one attached can be applied
> to Xen to reduce the impact to a denial of service.  Even with such a
> patch, a guest can still cause a complete system crash or resource
> starvation.
> 
> Upgrading to recent hardware that is interrupt remapping capable will
> resolve the remaining denial of service issues.  Support for interrupt
> remapping, when the hardware is capable, is present in all currently
> maintained versions of Xen.
> 
> On such recent hardware, when passing pci devices through to untrusted
> guests, we recommend the use of the "iommu=required" Xen command line
> boot option and the second atttached patch, to avoid unknowingly
> booting into a vulnerable configuration.
> 
> 
> REFERENCES
> ==========
> 
> Thanks to Rafal Wojtczuk and Joanna Rutkowska of Invisible Things Lab
> for bringing this issue to our attention.  Their paper on the attack
> will soon be available from Invisible Things Lab, at
> www.invisiblethingslab.com.
> 
> Information regarding chipset versions and interrupt remapping support
> should be available from Intel; please use your usual support and
> security response channels at Intel.
> 
> We believe that this vulnerability exists with all virtualisation
> systems which aim to support passing pci devices through to
> untrusted guests, on the affected Intel hardware.  If you are using
> a hypervisor other than Xen please refer to your hypervisor's usual
> security support and advisory release channels.
> 
> 
> PATCHES
> =======
> 
> The first patch is intended to reduce the impact from full privilege
> escalation to denial of service.
>  Filename: 00-block-msis-on-trap-vectors
>  SHA1: 0fcc1914714c228e98b3e84597e06cb5de09003c
>  SHA256: 998e8d5632ee6ad92f52796fe94923f9c38096c5adf2ca74209a6792436ea1e9
> 
> The second patch is intended to ensure that when Xen boots with
> "iommu=required" it will also insist that interrupt remapping is
> supported and enabled.  It arranges that booting with that option on
> vulnerable hardware will fail, rather than appearing to succeed but
> actually being vulnerable to guests.
>  Filename: intremap05033.patch
>  SHA1: 1cd26adc5ead0c07b67bf354f03164235d67395c
>  SHA256: 7f8c7d95d33bbd5c4f25671b380e70020fda1ba6cb50b67e59131fa8e59c1c66
> 
> Unfortunately we have not been able to test either patch.  Both will
> be applied to xen-unstable very soon.  We also intend to provide
> backports in the supported released Xen trees.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel