From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joanna Rutkowska Subject: Re: Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI Date: Fri, 13 May 2011 19:32:02 +0200 Message-ID: <4DCD6B12.8040700@invisiblethingslab.com> References: <19915.58644.191837.671729@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0788620064==" Return-path: In-Reply-To: <19915.58644.191837.671729@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Jackson Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0788620064== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF2CB5F1E43E34B01126EB749" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF2CB5F1E43E34B01126EB749 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 >=20 > ISSUE DESCRIPTION > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 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. >=20 >=20 > VULNERABLE SYSTEMS > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 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. >=20 > In Xen with xend/xm or with xl this would be enabled by the "pci=3D" > 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. >=20 > 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. >=20 > 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. >=20 > Interrupt remapping is available in newer Intel VT-d chipsets. >=20 >=20 > IMPACT > =3D=3D=3D=3D=3D=3D >=20 > A guest given a PCI passthrough device can escalate its privilege and > gain control of the whole system. >=20 >=20 > MITIGATION AND RESOLUTION > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >=20 > No complete software fix is available but we understand that Intel has > addressed this issue with newer hardware. >=20 > 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. >=20 > 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. >=20 > On such recent hardware, when passing pci devices through to untrusted > guests, we recommend the use of the "iommu=3Drequired" Xen command line= > boot option and the second atttached patch, to avoid unknowingly > booting into a vulnerable configuration. >=20 >=20 > REFERENCES > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 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. >=20 > Information regarding chipset versions and interrupt remapping support > should be available from Intel; please use your usual support and > security response channels at Intel. >=20 > 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. >=20 >=20 > PATCHES > =3D=3D=3D=3D=3D=3D=3D >=20 > 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: 998e8d5632ee6ad92f52796fe94923f9c38096c5adf2ca74209a6792436ea1= e9 >=20 > The second patch is intended to ensure that when Xen boots with > "iommu=3Drequired" 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: 7f8c7d95d33bbd5c4f25671b380e70020fda1ba6cb50b67e59131fa8e59c1c= 66 >=20 > 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. >=20 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------enigF2CB5F1E43E34B01126EB749 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNzWsSAAoJEDaIqHeRBUM0QNQH/2/pnACBZs9QGq1cLemYv+25 hS+Rk3YYfuBbUI6QnCi4SNKrhNwpkgcWrSKXXORyxs0WAaSYTnlshLIUHFHbj2Fm 8orGoXFTudatZ7toOGmsr/SN6tJFKDCOBs2rY0G7JeHKNqnnisZHvQAnUW0IUezI dU1JRrP0xTsvfUs2cZ+LUPZRgsUFxwSmTxAqaVKkPf8uQliUTdXSD+s6jyMG0mT/ Wgyy5svcFRK3eno7CMHwEtoY7CwxYwA2YJnCg7iG/OYfijWbJrXxBx1mdDEF5Tzc 290ncp02diqgYuy8nN4pWKOjKGw2SyTBeirnH9Iio5VJxye5jWIGY3KEcBn12+0= =7KDF -----END PGP SIGNATURE----- --------------enigF2CB5F1E43E34B01126EB749-- --===============0788620064== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0788620064==--