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.