[<prev] [next>] [day] [month] [year] [list]
Message-Id: <E1YVIqJ-0002tg-Jt@xenbits.xen.org>
Date: Tue, 10 Mar 2015 12:00:59 +0000
From: Xen.org security team <security@....org>
To: xen-announce@...ts.xen.org, xen-devel@...ts.xen.org,
xen-users@...ts.xen.org, oss-security@...ts.openwall.com
CC: Xen.org security team <security@....org>
Subject: Xen Security Advisory 124 - Non-standard PCI device functionality
may render pass-through insecure
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Xen Security Advisory XSA-124
version 2
Non-standard PCI device functionality may render pass-through insecure
UPDATES IN VERSION 2
====================
Clarify scope. PCI config space backdoors are just one example.
Provide more examples of potential problems. Provide some additional
mitigation options.
Public release.
ISSUE DESCRIPTION
=================
Devices with capabilities or defects that are undocumented or that
virtualization software is unaware of may allow guests to control
parts of the host that they shouldn't be in control of. Here are some
examples of the kind of problem:
* While XSA-120 deals with standard PCI config space accesses to the
PCI control word, various devices have alternative methods to read
and modify config space values. A guest which has been given such a
device can definitely cause a host DoS; worse attacks cannot be
ruled out.
* Devices which are physically integrated into the system chipset
might have undocumented direct access to memory or other resources
(as well as the documented access via the IOMMU). A guest with such
a device is likely to be able to gain control of the host.
* Many devices permit (or require) the loading or updating of the
firmware on the device. Bad firmware is likely to be able to
violate the PCI protocols (depending on the physical circuitry on
the device). The impact of such violations is difficult to assess
in the abstract.
Malicious firmware might also be able to cause electrical problems
for the PCI bus, system power supply, and other circuitry. This
could be used to mount fault-injection attacks, or even to cause
damage to hardware.
Again, this will depend on the details of the device, but in general
defending against bad firmware would require additional electronics.
Therefore the Xen Project Security Team expects that devices which
support firmware loading are unlikely to be robust against malicious
firmware unless that robustness has been specifically engineered.
Since the details are device specific, special workarounds would need
to be developed for any such device for which secure pass-through is
desired. Developing such workarounds is a task presenting multiple
challenges, particularly since the hardware details are often not
officially documented, and is beyond the scope of normal security
fixes.
The Xen Project Security Team is therefore adopting an exceptional
process for these kind of problems. See below for details of that
exceptional process, and for the scope of the exception.
IMPACT
======
Passing through a device providing such mechanisms, which bypass or
subvert the software layers that ensure security and correctness, may
expose the host to guest induced information leaks, host crashes, and
privilege escalation.
VULNERABLE SYSTEMS
==================
Only systems where physical PCI devices are passed through to
untrusted guests are affected.
All hypervisors supporting PCI passthrough are exposed to this kind of
problem; this includes all versions of Xen which support PCI
passthrough.
Only x86 Xen systems are currently affected. ARM systems are not
currently affected when running Xen due to not supporting
pass-through. However once this feature is implemented ARM systems
will become vulnerable to this class of bugs and subject to the
exceptional handling described in this advisory.
Devices specifically designed and advertised for secure PCI
passthrough (for example, SR-IOV virtual functions) are outside the
scope of this advisory, and outside the process exception. We are not
aware of problems with any such devices at the present time, and any
vulnerabilities which we become aware of will be handled in the normal
way.
Any other PCI devices might cause vulnerablities, and are subject to
the exception. Whether a specific system is actually vulnerable
depends on the characteristics of the PCI device being passed through:
* The device behaviour will usually depend on the specific firmware
loaded onto the device itself; if such firmware is (or can be)
loaded by guests, the device is probably vulnerable (unless its
manufacturer has specifically advertised to the contrary).
* Other devices should be assumed to be vulnerable unless the complete
functionality is known, and has been reviewed in the context of PCI
passthrough security.
MITIGATION
==========
Not passing through any physical devices to guests will avoid this
vulnerability.
This vulnerability can also be avoided by only passing through devices
the entire scope of whose functionality is known and has been reviewed
for PCI passthrough security and correctness, or only devices
specifically and correctly designed to be passed through in a secure
manner (for example, SR-IOV virtual functions).
If the functionality of a PCI device needs to be exposed to an
untrusted guest, PCI passthrough related vulnerabilities can be
avoided by offering the guest that functionality via a higher-level
protocol. For example: rather than PCI passthrough of a storage
controller, offer the guest Xen paravirtualised block devices, or
configure the guest as a client for a SAN protocol (such as NBD or
iSCSI); rather than passing through a graphics controller, provide the
guest with a Xen paravirtualised framebuffer, or have the guest export
applications via a network terminal protocol (such as X11 or VNC).
RESOLUTION
==========
For affected devices, no reasonable resolution in software is
possible.
"Unreasonable" resolution might be possible for specific devices,
where the complete scope of the device's functionality is known. In
such a case it might be possible to write device-specific workaround
code to eliminate the vulnerabilities. The Xen Project Security Team
does not intend to develop software along those lines.
NOTE REGARDING CVE
==================
MITRE have provisionally concluded that this Xen Security Advisory
does not describe a vulnerability for which they should issue a CVE
Identifier.
PROCESS FOR HARDWARE RELATED PASS-THROUGH VULNERABILITIES
=========================================================
Unless affected hardware is specifically declared to be secure when
used with PCI passthrough, the Xen Project Security Team intends
(subject of course to the permission of anyone disclosing to us) to
handle these and future hardware related PCI pass-through
vulnerabilities in public, as if they were normal non-security-related
bugs.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBAgAGBQJU/tzbAAoJEIP+FMlX6CvZWdMH/13dCkBkpLSn4b3CM+637TmC
sPGFiS40Q1n1bipGxiug1YoRUsSljDt1kUhGOlYEriPfISkR/XoH2O/3hTnntEKS
FTqUt7KLdNKRNif17tyrSuBG9sZy3JHTH0b5tjlOulSUp7pY8UoalwJD0YJpPGv/
BFlP4aySZs9etTfIyN/yfv06zbl+8znZlA1AwTr0UVm7p4Dwz2pMUmfF5N5AVQXS
ruWNqnjLjqTleGgG9ZTMLDgPXuylKuFab4BFPeOMqP7p0RoWd4gJV2O7LhHFM0c3
KxCcUtDJolu5QSSsEKq6arWpb1IzzvZ7vXTmaYyw5zdmUR8P5VvE/O2rY2PBM2Q=
=bgFa
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
