WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI
From: Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 13 May 2011 19:32:02 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 13 May 2011 10:30:33 -0700
Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:cc:subject:references:in-reply-to:content-type; s=smtpout; bh=wrR3u2ih3pjvFqnEVdhkovuCwT8=; b=J+jY2uarocGSowcAXX3Di6kyDI4BooWJySuxxYABXxebBHu8SqmyxMk/Z1A4+6WUJzqQLQJWCtriCb6e76grmWvWIu/sLoLcsnJZSWX8X7t7H15Mns11A6WtKo86/wHF+WDl+n1FtmTuKgk+58y9xxYClAwImbWPlNFc8WDqX2o=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <19915.58644.191837.671729@xxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <19915.58644.191837.671729@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110421 Fedora/3.1.9-2.fc14 Lightning/1.0b3pre Thunderbird/3.1.9
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