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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

             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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iJwEAQECAAYFAk3L5JUACgkQQz2i6ICVfYMh9wP/S/D3xN48bKBM2sBNuO08Hqhy
0ViFGdgZGs3p5EbRCIRTGe6YZonh8oIJi/JSxevd5WD7gDeV+8Dfr4in/gKXWThI
6kyJCzMZdJeB4ecJsX64sKS9pShJT39J1RAoeLeEGiPahO1Id6UySyF23xoF0R0E
7RpPPfG5lxS0xwdQO4M=
=yfWW
-----END PGP SIGNATURE-----

Attachment: 00-block-msis-on-trap-vectors
Description: mitigation patch for old hardware

Attachment: intremap05033.patch
Description: assurance patch for new hardware

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