Headline
CVE-2020-25595: 337 - Xen Security Advisories
An issue was discovered in Xen through 4.14.x. The PCI passthrough code improperly uses register data. Code paths in Xen’s MSI handling have been identified that act on unsanitized values read back from device hardware registers. While devices strictly compliant with PCI specifications shouldn’t be able to affect these registers, experience shows that it’s very common for devices to have out-of-spec “backdoor” operations that can affect the result of these reads. A not fully trusted guest may be able to crash Xen, leading to a Denial of Service (DoS) for the entire system. Privilege escalation and information leaks cannot be excluded. All versions of Xen supporting PCI passthrough are affected. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only guests with passed through PCI devices may be able to leverage the vulnerability. Only systems passing through devices with out-of-spec (“backdoor”) functionality can cause issues. Experience shows that such out-of-spec functionality is common; unless you have reason to believe that your device does not have such functionality, it’s better to assume that it does.
Information
Advisory
XSA-337
Public release
2020-09-22 12:00
Updated
2020-09-22 13:36
Version
3
CVE(s)
CVE-2020-25595
Title
PCI passthrough code reading back hardware registers
Filesadvisory-337.txt (signed advisory file)
xsa337.meta
xsa337/xsa337-1.patch
xsa337/xsa337-2.patch
xsa337/xsa337-4.12-1.patch
xsa337/xsa337-4.12-2.patch
xsa337/xsa337-4.13-1.patch
xsa337/xsa337-4.13-2.patchAdvisory
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Xen Security Advisory CVE-2020-25595 / XSA-337
version 3
PCI passthrough code reading back hardware registers
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
Code paths in Xen’s MSI handling have been identified which act on unsanitized values read back from device hardware registers. While devices strictly compliant with PCI specifications shouldn’t be able to affect these registers, experience shows that it’s very common for devices to have out-of-spec “backdoor” operations which can affect the result of these reads.
IMPACT
A not fully trusted guest may be able to crash Xen, leading to a Denial of Service (DoS) for the entire system. Privilege escalation and information leaks cannot be excluded.
VULNERABLE SYSTEMS
All versions of Xen supporting PCI passthrough are affected.
Only x86 systems are vulnerable. Arm systems are not vulnerable.
Only guests with passed through PCI devices may be able to leverage the vulnerability.
Only systems passing through devices with out-of-spec (“backdoor”) functionality can cause issues. Experience shows that such out-of-spec functionality is common; unless you have reason to believe that your device does not have such functionality, it’s better to assume that it does.
REMINDER OF PCI PASSTHROUGH SUPPORT STATEMENT
The security team wishes to reiterate our support statement for PCI Device Passthrough (found in xen.git/SUPPORT.md):
“Because of hardware limitations (affecting any operating system or hypervisor), it is generally not safe to use this feature to expose a physical device to completely untrusted guests. However, this feature can still confer significant security benefit when used to remove drivers and backends from domain 0 (i.e., Driver Domains).”
The possibility of “backdoor” device functionality mentioned above is one of the major reasons for this stance. We issue this XSA to help maintain Driver Domains as a "defense-in-depth", and also on behalf of those who may have done full security audits of their particular hardware platform. It does not change our stance that passing through PCI devices to untrusted guests is in general not safe.
MITIGATION
Not passing through physical devices to untrusted guests will avoid the vulnerability.
CREDITS
This issue was discovered by Andrew Cooper of Citrix.
RESOLUTION
Applying the appropriate pair of attached patches resolves this issue.
Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches.
xsa337/xsa337-?.patch Xen 4.14 - xen-unstable xsa337/xsa337-4.13-?.patch Xen 4.13 xsa337/xsa337-4.12-?.patch Xen 4.10 - 4.12
$ sha256sum xsa337* xsa337*/* f027d07fb307f5441ee9d19b6385e421bba745059667d181031b0bfd7047a15b xsa337.meta 98c48781dd46bf6ff6cc46246c6c9f2e2be6ec696c0e7918d4b82845588ce04e xsa337/xsa337-1.patch 9e8ae24222371379f2ea62e14fcc7f7282e01c356dff230c22c9ab1d2fb941e2 xsa337/xsa337-2.patch a6744fdab01877e098f88dcd3bee10c3146aef66170a1422b3811cd09fc9faef xsa337/xsa337-4.12-1.patch a091652f1a3c0bf851e35b61d338d53b4690fab828b3c30f354c28c377af2aee xsa337/xsa337-4.12-2.patch fb27fd2508e017bf05131eb3d31bb8cc56c79690cbb7f1af76cb92fd568040a1 xsa337/xsa337-4.13-1.patch a25bc70ad55716ce3a0d9435fa2b0a492420a0eabfb0e3f94cd27de10242d98b xsa337/xsa337-4.13-2.patch $
DEPLOYMENT DURING EMBARGO
Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators.
HOWEVER, deployment of the mitigation is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted.
This is because removing of pass-through devices or their replacement by emulated devices is a guest visible configuration change, which may lead to re-discovery of the issue.
Deployment of this mitigation is permitted only AFTER the embargo ends.
AND: Distribution of updated software is prohibited (except to other members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team.
(Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team’s decisionmaking.)
For more information about permissible uses of embargoed information, consult the Xen Project community’s agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE-----
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl9p/ecMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZlcIIAKtn9RdA/CjIRcodtfxnnFPQu9SRtmHfLNQ2Vjmu F1nIjjEklUNJSpGlEGjG1cq3oA/SZTm2jYXu2k4rcAyrl0bhaflSoL/N+Fmwo2Ym 898KA8gLdIckagxz5WKVv/vqc3x/h2IZgN4AUgt73buUOxEBFudqJKvnwtep5Z5R 60MDs+lp/5Mp6cXUukAWzPnmtJDWZ4s4QHXHNkKXTUpByZfmGJqqflL6yJDFHSxt vvGpvElApkMP4Ks+rPoCrdG/ObbQvgwMgSJ//tnnWayfs1asOxrRbFlLAt4yVvdt Y6Hi69hHB+ZWO36qy5dvjjKk0ftbrPAPDbDk27y/zuKXhko= =TzZR -----END PGP SIGNATURE-----
Xenproject.org Security Team
Related news
Ubuntu Security Notice 5617-1 - It was discovered that memory contents previously stored in microarchitectural special registers after RDRAND, RDSEED, and SGX EGETKEY read operations on Intel client and Xeon E3 processors may be briefly exposed to processes on the same or different processor cores. A local attacker could use this to expose sensitive information. Julien Grall discovered that Xen incorrectly handled memory barriers on ARM-based systems. An attacker could possibly use this issue to cause a denial of service, obtain sensitive information or escalate privileges.