Dear Qubes community,
We have just published Qubes Security Bulletin (QSB) #30: Critical Xen bugs related to PV memory virtualization (XSA-213, XSA-214).
The current text of this QSB is reproduced below. The latest version, including any future corrections, will always be available in the Qubes Security Pack (qubes-secpack).
View QSB #30 in the qubes-secpack:
Learn about the qubes-secpack, including how to obtain, verify, and read it:
View all past QSBs:
View XSA-213 and XSA-214 in the XSA Tracker:
---===[ Qubes Security Bulletin #30 ]===--- May 2, 2017 Critical Xen bugs related to PV memory virtualization (XSA-213, XSA-214) Summary ======== Today the Xen Security Team has disclosed two bugs related to PV memory handling affecting Qubes OS: XSA-213  and XSA-214 . An attacker who exploits either of these bugs can break Qubes-provided isolation. This means that if an attacker has already exploited another vulnerability, e.g. in a Web browser or networking or USB stack, then the attacker would be able to compromise a whole Qubes system. Technical details ================== Xen Security Advisory XSA-213 : | x86: 64bit PV guest breakout via pagetable use-after-mode-change | | 64-bit PV guests typically use separate (root) page tables for their | kernel and user modes. Hypercalls are accessible to guest kernel | context only, which certain hypercall handlers make assumptions on. | The IRET hypercall (replacing the identically name CPU instruction) | is used by guest kernels to transfer control from kernel mode to user | mode. If such an IRET hypercall is placed in the middle of a multicall | batch, subsequent operations invoked by the same multicall batch may | wrongly assume the guest to still be in kernel mode. If one or more of | these subsequent operations involve operations on page tables, they may | be using the wrong root page table, confusing internal accounting. As | a result the guest may gain writable access to some of its page tables. Xen Security Advisory XSA-214 : | grant transfer allows PV guest to elevate privileges | | The GNTTABOP_transfer operation allows one guest to transfer a page to | another guest. The internal processing of this, however, does not | include zapping the previous type of the page being transferred. This | makes it possible for a PV guest to transfer a page previously used as | part of a segment descriptor table to another guest while retaining the | "contains segment descriptors" property. | | If the destination guest is a PV one of different bitness, it may gain | access to segment descriptors it is not normally allowed to have, like | 64-bit code segments in a 32-bit PV guest. | | If the destination guest is a HVM one, that guest may freely alter the | page contents and then hand the page back to the same or another PV | guest. | | In either case, if the destination PV guest then inserts that page into | one of its own descriptor tables, the page still having the designated | type results in validation of its contents being skipped. The second bug requires cooperation between two VMs of different types, which somewhat limits its applicability. The Xen Security Team also announced a third advisory today: XSA-215 "possible memory corruption via failsafe callback". | Only x86 systems with physical memory extending to a configuration | dependent boundary (5Tb or 3.5Tb) may be affected. Whether they are | actually affected depends on actual physical memory layout. We believe this bug is extremely unlikely to affect any Qubes users due to the very high hardware requirements (5Tb or 3.5Tb of physical memory). Patching ========= Patched packages will be built and uploaded to the security-testing repository shortly after this advisory is published. We have recently implemented and published the details of a new, transparent build infrastructure.  In this new infrastructure, the source code for packages is pushed to a public repository, and logs from the build process are also publicly published. However, the Xen security policy does not permit us to make this data public until after the embargo has been lifted.  While we have already privately built and tested these packages, we must wait until the embargo has been lifted before transparently building the public packages using our new infrastructure. The specific packages that resolve the problem discussed in this bulletin are as follows: For Qubes 3.2: - Xen packages, version 4.6.5-27 The packages are to be installed in dom0 via the qubes-dom0-update command or via the Qubes VM Manager. A system restart will be required afterwards. If you use Anti Evil Maid, you will need to reseal your secret passphrase to new PCR values, as PCR18 will change due to the new xen.gz binary. These packages will migrate to the current (stable) repository over the coming days after being tested by the community. Commentary =========== XSA-213 is a fatal, reliably exploitable bug in Xen. In the nearly eight-year history of the Qubes OS project, we have become aware of four bugs of this calibre: XSA-148 , XSA-182 , XSA-212 , and now XSA-213. Coincidentally, all of these fatal bugs have been in Xen mechanisms for handling memory virtualization for paravirtualized (PV) VMs. Some might argue that having only four fatal bugs (among other not-that-fatal ones ) in 8 years is a reasonably good result, especially compared to other desktop systems. We, however, have been deeply upset by each and every of these bugs. In fact, after we learned of the second of these (XSA-212) 10 months ago, we immediately began working on a way to move away from using PV-based VMs and toward using only hardware-based virtualization (HVM) VMs in Qubes 4.x . The switch from PV to HVM has been a major undertaking and has introduced a delay in the release of Qubes 4.0. This undertaking is now complete, however , and Qubes 4.0-rc1 will be released in the next 1-2 months, after we've finished up with some remaining minor issues. We originally hoped we could transition to running all Linux VMs in a so-called PVH mode of virtualization, where the I/O emulator is not needed at all, but it turned out the Linux kernel is not quite ready for this. So, in Qubes 4.0, we will use the classic HVM mode, where the I/O emulator is sandboxed within... a PV VM (which is also the case when one runs Windows AppVMs on Qubes 3.x). This makes it possible for an attacker to chain attacks: one for QEMU with another hypothetical for PV virtualization, to break out of a VM. But the good news is that, with the work we have done in 4.0 to transition from PV to HVM, the final step to transition to PVH should be trivial, and we hope to introduce it in 4.1, once the upstream Linux kernel supports it. Since we began working on ditching PV virtualization 10 months ago, two more fatal Xen bugs were published: one last month (XSA 212 ) and the one we discuss today (XSA 213). To provide our users with some means of addressing these problems, we've recently introduced "Paranoid Backup Recovery" mode , which we believe is a meaningful way for users to recover from potential compromises on Qubes OS. Many readers will undoubtedly continue asking, "If Xen is so buggy, why not ditch it for some other hypervisor?" First, all public hypervisors have security issues, and it's unclear whether Xen is any buggier than the other available options. Second, and most importantly, we don't see any good alternative at this moment. Xen has some unique architectural features, such as support for running network and storage backends within _unprivileged_ VMs, which other, popular VMMs do not. Finally, unlike many research projects, Xen is mature enough to support all sorts of features that are necessary when running on a laptop, such as power management and reasonable compatibility with most BIOSes. In principle, however, Xen is an interchangeable component within the Qubes OS architecture. One day, we might replace it with something else, and thanks to the generalized architecture we introduced in Qubes 3.0  and took even further in Qubes 4.0 (e.g. ), Qubes users and admins might not even notice! Credits ======== See original Xen Security Advisories: - XSA-213  - XSA-214  References ===========  https://xenbits.xen.org/xsa/advisory-213.html  https://xenbits.xen.org/xsa/advisory-214.html  https://xenbits.xen.org/xsa/advisory-215.html  https://github.com/QubesOS/qubes-infrastructure/  https://www.xenproject.org/security-policy.html  https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-024-2016.txt  https://github.com/QubesOS/qubes-issues/issues/2185  https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/  https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-029-2017.txt  https://www.qubes-os.org/news/2017/04/26/qubes-compromise-recovery/  https://blog.invisiblethings.org/2015/04/23/qubes-30rc1-and-roadmap.html  https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-022-2015.txt  https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-024-2016.txt  https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-029-2017.txt  https://www.qubes-os.org/security/qsb/  https://www.qubes-os.org/doc/mgmt/ -- The Qubes Security Team https://www.qubes-os.org/security/