| layout | title | date | categories |
|---|---|---|---|
post |
QSB #30: Critical Xen bugs related to PV memory virtualization (XSA-213, XSA-214) |
2017-05-02 |
security |
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:
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/qsb/
View XSA-213 and XSA-214 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#213
https://www.qubes-os.org/security/xsa/#214
---===[ 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/qsb/
[16] https://www.qubes-os.org/doc/mgmt/
--
The Qubes Security Team
https://www.qubes-os.org/security/