Date: Tue, 31 Mar 2015 16:13:39 +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 120 (CVE-2015-2150) - Non-maskable interrupts triggerable by guests -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2015-2150 / XSA-120 version 5 Non-maskable interrupts triggerable by guests UPDATES IN VERSION 5 ==================== The original patches were incomplete: although they eliminated the possibility that the guest might disable memory and I/O decoding, they did not ensure that these bits were set at start of day. The result was that a malicious guest could simply avoid enabling them and continue to exploit the vulnerability. Well behaved guests would normally enable decoding and therefore would not normally suffer a regression. Additional patches are now supplied to resolve this issue. ISSUE DESCRIPTION ================= Guests are currently permitted to modify all of the (writable) bits in the PCI command register of devices passed through to them. This in particular allows them to disable memory and I/O decoding on the device unless the device is an SR-IOV virtual function, in which case subsequent accesses to the respective MMIO or I/O port ranges would - - on PCI Express devices - lead to Unsupported Request responses. The treatment of such errors is platform specific. IMPACT ====== In the event that the platform surfaces aforementioned UR responses as Non-Maskable Interrupts, and either the OS is configured to treat NMIs as fatal or (e.g. via ACPI's APEI) the platform tells the OS to treat these errors as fatal, the host would crash, leading to a Denial of Service. VULNERABLE SYSTEMS ================== Xen versions 3.3 and onwards are vulnerable due to supporting PCI pass-through. Upstream Linux versions 3.1 and onwards are vulnerable due to supporting PCI backend functionality. Other Linux versions as well as other OS versions may be vulnerable too. Any domain which is given access to a non-SR-IOV virtual function PCI Express device can take advantage of this vulnerability. MITIGATION ========== This issue can be avoided by not assigning PCI Express devices other than SR-IOV virtual functions to untrusted guests. CREDITS ======= This issue was discovered by Jan Beulich of SUSE. RESOLUTION ========== Applying the appropriate attached patches resolves this issue for the indicated versions of Linux, but only for ordinary PCI config space accesses by the guest. See XSA-124 for all other cases. xsa120.patch Linux 3.19 xsa120-addendum.patch Linux 3.19 xsa120-classic.patch linux-2.6.18-xen.hg xsa120-classic-addendum.patch linux-2.6.18-xen.hg $ sha256sum xsa120*.patch 32441fd3930848f7533f74376648fbeb5e35870661e1259860fe10f9a1f67f88 xsa120.patch 32be0b76f5585e9258ebaed348b40b57014ee5163c313a0523fd46f55ac05210 xsa120-addendum.patch ecd4568d418d6e275f1eebdba4867e7cfdc6a487292db0e9eff0e9e7e2c91826 xsa120-classic.patch 8b377abe56bebf5030587030bf231c2d5bc1f695e21cc4dfbbd348e9b616849c xsa120-classic-addendum.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: 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----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJVGseNAAoJEIP+FMlX6CvZcR4H/RGyM4VV4/1LLFkERmVe6jCq KhPGTWw72ZMt+iTGLZYOWGu3CTwpG2RSMWwRUNE9dBinUyq5j8GYW+dpAmtBFCT/ muEW3k+cw4BnhOIi6ny3bcCsxnm7SesrpWAmRvwgZRWljZMA0tHhperl1ioovMG0 +jf7ktNU91li7jTm0BSba7FoWIhfSsY5K+hU0/xMrKOUkzdpYzhu8Uzj9exhijHC 5AJ05XDi88ZuZfR7ZPnVvTOaIJaXsVeiM4rfSpp+SsqTyOZW4+ORpd5ecEp93O/N LNtcHsUjqwm/ezkwM8oHrGQqYWf7Ms4mRuykIE2X/voG/Cf+kvDQE7fOj++3Db0= =La+E -----END PGP SIGNATURE----- Download attachment "xsa120.patch" of type "application/octet-stream" (3745 bytes) Download attachment "xsa120-addendum.patch" of type "application/octet-stream" (1874 bytes) Download attachment "xsa120-classic.patch" of type "application/octet-stream" (3716 bytes) Download attachment "xsa120-classic-addendum.patch" of type "application/octet-stream" (1743 bytes)
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.