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_6945bc33 marmarek_sec_6613fd2b marmarek_sec_5539bfe8 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_735d08c4 marmarek_sec_696e531c marmarek_sec_692db79a marmarek_sec_688f1623 marmarek_sec_201e4cc3 marmarek_sec_160b7a0b marmarek_sec_113cf714 marmarek_sec_109b6fdf marmarek_sec_97f1428a marmarek_sec_93f129d7 marmarek_sec_91c22ed5 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_55a292c9 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_5fb232ea marmarek_sec_5f208b29 marmarek_sec_5e61a5a6 marmarek_sec_5ddbd92b marmarek_sec_5c986968 marmarek_sec_5c9616cd marmarek_sec_5c995e08 marmarek_sec_5b6117ae
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
168 lines (129 sloc) 6.66 KB
---===[ Qubes Security Bulletin #29 ]===---
April 4, 2017
Critical Xen bug in PV memory virtualization code (XSA-212)
Quick Summary
The Xen Security Team has discovered a serious security bug (XSA-212)
in the hypervisor code handling memory virtualization for
paravirtualized (PV) VMs [1]:
| The XSA-29 fix introduced an insufficient check on XENMEM_exchange
| input, allowing the caller to drive hypervisor memory accesses outside
| of the guest provided input/output arrays.
| A malicious or buggy 64-bit PV guest may be able to access all of
| system memory, allowing for all of privilege escalation, host crashes,
| and information leaks.
An attacker who exploits this bug 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.
Description of the bug
Arguments of XENMEM_exchange hypercall contains array of page numbers
to be exchanged and array for exchanged page numbers. Validation of
those arrays (supposedly living in guest memory) assumes a certain
memory layout -- that Xen memory is just above non-canonical addresses.
It also assumes that array accesses are sequential starting from the
beginning of the array. With this assumption, validation code checks
only the address of the first array element and assumes (thanks to
sequential access) that further code will hit a non-canonical address,
resulting in page fault, before reaching Xen memory.
Relevant part of xen/include/asm-x86/x86_64/uaccess.h:
* Valid if in +ve half of 48-bit address space, or above Xen-reserved area.
* This is also valid for range checks (addr, addr+size). As long as the
* start address is outside the Xen-reserved area, sequential accesses
* (starting at addr) will hit a non-canonical address (and thus fault)
* before ever reaching VIRT_START.
#define __addr_ok(addr) \
(((unsigned long)(addr) < (1UL<<47)) || \
((unsigned long)(addr) >= HYPERVISOR_VIRT_END))
#define access_ok(addr, size) \
(__addr_ok(addr) || is_compat_arg_xlat_range(addr, size))
#define array_access_ok(addr, count, size) \
(access_ok(addr, (count)*(size)))
Unfortunately, this assumption is false in XENMEM_exchange. The caller
of this hypercall has full control over the place at which array
processing starts (using the exch.nr_exchanged argument). This means
that the caller can trick the Xen hypervisor into reading input page
numbers from the Xen memory area or write exchanged page numbers into
the Xen memory area. The attacker does not directly control values
written there, but using, for example, balloon driver, can influence
what pages will be available in the system and later chosen for
allocation by XENMEM_exchange.
This means that a sufficiently determined attacker can use this bug to
write arbitrary data into arbitrary places in Xen memory and thereby
take full control of the system.
This is another bug resulting from the overly-complex memory
virtualization required for PV in Xen. As we announced last year [5],
the upcoming Qubes OS 4.0 will no longer use PV. Instead, we will be
switching to HVM-based virtualization:
| One of the most important security improvements that we plan to
| introduce with the release of Qubes 4 is to ditch paravirtualization
| (PV) technology and replace it with hardware-enforced memory
| virtualization, which recent processors have made possible thanks to
| so-called Second Level Address Translation (SLAT), also known as EPT
| in Intel parlance. SLAT (EPT) is an extension to Intel VT-x
| virtualization, which originally was capable of only CPU
| virtualization but not memory virtualization and hence required a
| complex Shadow Page Tables approach (which we believed back then was
| actually less attractive than the PV approach). We hope that embracing
| SLAT-based memory virtualization will allow us to prevent disastrous
| security bugs, such as the infamous XSA 148, publicly disclosed in
| October of last year, which unlike many other major Xen bugs
| regrettably did affect Qubes OS. Consequently, we will be requiring
| SLAT support of all certified hardware for Qubes OS 4 and later.
At the same time, we would like to point out that the security of Qubes
OS has so far been affected by less than 10% of publicly disclosed Xen
bugs, as tracked by the recently created Xen Security Advisory (XSA)
Tracker. [6]
Availability of patches
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. [3] 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 XSA-212
embargo has been lifted. [4] 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.
Thanks to the new infrastructure, it's also much easier for us handle
updates. Because of this, we've decided to release fixed packages
for Qubes OS 3.1, even though it recently reached EOL. Both Qubes OS
3.1 and Qubes OS 3.2 use the same Xen version, so this requires no
additional work.
The specific packages that resolve the problem discussed in this
bulletin will be uploaded to the security-testing repository:
For Qubes 3.1 and 3.2:
* Xen packages, version 4.6.4-26
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.
This issue was discovered by Jann Horn of Google Project Zero and
reported to the Xen Security Team.
The Qubes Security Team