On Tuesday, May 2, 2017 at 8:10:13 AM UTC-4, Andrew David Wong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > 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 text of this QSB is reproduced below. This QSB and its accompanying > signatures will always be available in the Qubes Security Pack > (qubes-secpack). > > View QSB #30 in the qubes-secpack: > > <https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-030-2017.txt> > > Learn about the qubes-secpack, including how to obtain, verify, and read it: > > <https://www.qubes-os.org/security/pack/> > > View all past QSBs: > > <https://www.qubes-os.org/security/bulletins/> > > ``` > > > ---===[ 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 [1] and XSA-214 [2]. > > 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 [1]: > > | 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 [2]: > > | 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"[3]. > > | 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. [4] 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. [5] 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 [12], XSA-182 [13], XSA-212 [14], 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 [15]) 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 [6]. > > 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 [7], 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 [9]) 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 [10], 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 > [11] and took even further in Qubes 4.0 (e.g. [16]), Qubes users and > admins might not even notice! > > Credits > ======== > > See original Xen Security Advisories: > > - XSA-213 [1] > - XSA-214 [2] > > References > =========== > > [1] https://xenbits.xen.org/xsa/advisory-213.html > [2] https://xenbits.xen.org/xsa/advisory-214.html > [3] https://xenbits.xen.org/xsa/advisory-215.html > [4] https://github.com/QubesOS/qubes-infrastructure/ > [5] https://www.xenproject.org/security-policy.html > [6] > https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-024-2016.txt > [7] https://github.com/QubesOS/qubes-issues/issues/2185 > [8] https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/ > [9] > https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-029-2017.txt > [10] https://www.qubes-os.org/news/2017/04/26/qubes-compromise-recovery/ > [11] https://blog.invisiblethings.org/2015/04/23/qubes-30rc1-and-roadmap.html > [12] > https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-022-2015.txt > [13] > https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-024-2016.txt > [14] > https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-029-2017.txt > [15] https://www.qubes-os.org/security/bulletins/ > [16] https://www.qubes-os.org/doc/mgmt/ > > - -- > The Qubes Security Team > https://www.qubes-os.org/security/ > ``` > > - -- > Andrew David Wong (Axon) > Community Manager, Qubes OS > https://www.qubes-os.org > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCgAGBQJZCHb3AAoJENtN07w5UDAwGCQP/jBcCWlznoL+c3oPbboQu8w7 > xLHpq8ULwb5eI69mdIVqBrnfpeCriVcd8Qa6h0KdIlQVnaBqJ903W6JER+NMaZPq > p6/rbJuUhKA87P8tSUmbdEiJ6SsZ4oMSvHMGvp3px083o8z8ejvF0H3lJRv7TKXt > rQjTo6/X9ezvQlPvgIiE5nGMcgk7VvNDkkM7XrlLsC5J5wcSjHx6YgL5I8MK7+Y4 > MJpwBgV4xNmO3WI2oriohCEZ8+55F3KyNe+1rg1BJFIkniT+rti6jgAkWtvR+Odm > mkgEQlyz/Qp8mZcbQGP2w810Ru4KVi6Te0Z1ObylJx+UUFPSoNevvlkgmarTJ+HI > 8/D5xlEdZTg2NPuE7aIpJw8C9zR0iA/qC/QWb7PBoBROzYmY89Bxe4M2Ed1g37Hk > mnXqaJ8XwbfZeODn5IzVck2E+IMvR/UKzHTgSw16MOJXuNUsRgYeZPELy8K4OMm0 > Y8LKXVgiWwkMsvu7r3Lep6iWb/YC29xhfXJPLPKtQ5H4URyIRH+R0aPf5q6+fZaE > Ru3/n/IfU7ZddM6jDyUvOJbwVTtUgBOkOnR1H8ziIb50KZE7wW7DloyRYfU/YxdL > 6yzptCVrxTVFl7fZaB8xvmNyUdL12ewsJ93YHWVM4roMbmqJS6BEtZyFKYBO5E0n > pXfdrKG81M+xK+50ITYS > =eifJ > -----END PGP SIGNATURE-----
If I have a laptop with VT-x and SLAT capabilities, should I ideally be creating all my TemplateVMs (including Fedora and Debian) as HVMs? Not in response to this particular issue, which I understand is being patched, but as a general best practice. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/66467e24-6125-4593-894a-aad7a0286c69%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
