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
signature.asc
Description: OpenPGP digital signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home