Switch branches/tags
w_49cc5d5a mm_78525939 mm_61621ebb mm_51660c83 mm_15143d72 mm_692db79a mm_201e4cc3 mm_109b6fdf mm_89af9f06 mm_49cc5d5a mm_40b3338e mm_7c825880 mm_5f208b29 mm_3bd7fe2e mm_2beab537 mm_1e390705 mm_d9c2f7df mm_d5a7241a mm_a4e175f3 marmarek_sec_84308824 marmarek_sec_78525939 marmarek_sec_46658321 marmarek_sec_24681439 marmarek_sec_6325034c marmarek_sec_4472371a marmarek_sec_539649d9 marmarek_sec_0311584c marmarek_sec_287158a9 marmarek_sec_162930b6 marmarek_sec_81194e72 marmarek_sec_61621ebb marmarek_sec_51660c83 marmarek_sec_43373e67 marmarek_sec_42521f68 marmarek_sec_15143d72 marmarek_sec_9097bd53 marmarek_sec_8487a05e marmarek_sec_4506ce8d marmarek_sec_2245aeed marmarek_sec_1302b8c6 marmarek_sec_880c1d9d marmarek_sec_848e7753 marmarek_sec_813f2ae3 marmarek_sec_806ab1a4 marmarek_sec_786ae750 marmarek_sec_696e531c marmarek_sec_692db79a marmarek_sec_688f1623 marmarek_sec_201e4cc3 marmarek_sec_160b7a0b marmarek_sec_113cf714 marmarek_sec_109b6fdf marmarek_sec_93f129d7 marmarek_sec_89af9f06 marmarek_sec_85d18bac marmarek_sec_81ac5fe4 marmarek_sec_77c18513 marmarek_sec_71eeb2ea marmarek_sec_68fa5cee marmarek_sec_66c7326e marmarek_sec_65c0e16e marmarek_sec_64f3338c marmarek_sec_55f7b189 marmarek_sec_49cc5d5a marmarek_sec_45f79323 marmarek_sec_41b90963 marmarek_sec_40b3338e marmarek_sec_35d7e6f1 marmarek_sec_33c90326 marmarek_sec_22c5fe0d marmarek_sec_20fc0746 marmarek_sec_16c2b497 marmarek_sec_15ac3d41 marmarek_sec_9ffb5883 marmarek_sec_9f43f503 marmarek_sec_9e64bee1 marmarek_sec_9d85918c marmarek_sec_9d2ab5db marmarek_sec_9ce311f5 marmarek_sec_8db2fb5d marmarek_sec_7f76bce3 marmarek_sec_7cdffb89 marmarek_sec_7bea266a marmarek_sec_7b063902 marmarek_sec_6be15b69 marmarek_sec_5f208b29 marmarek_sec_5e61a5a6 marmarek_sec_5ddbd92b marmarek_sec_5c986968 marmarek_sec_5c9616cd marmarek_sec_5c995e08 marmarek_sec_5b6117ae marmarek_sec_4c58f8fb marmarek_sec_4b1d1114 marmarek_sec_3bd7fe2e marmarek_sec_3bacccfc marmarek_sec_3a5b80b5 marmarek_sec_2d58fc13 marmarek_sec_2bb7f0b9 marmarek_sec_1e390705
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
199 lines (157 sloc) 8.76 KB
---===[ Qubes Security Bulletin #30 ]===---
May 2, 2017
Critical Xen bugs related to PV memory virtualization (XSA-213, XSA-214)
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
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
These packages will migrate to the current (stable) repository over the
coming days after being tested by the community.
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-182) 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!
See original Xen Security Advisories:
- XSA-213 [1]
- XSA-214 [2]
The Qubes Security Team