Permalink
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_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 marmarek_sec_4c58f8fb marmarek_sec_4b1d1114
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
179 lines (140 sloc) 7.16 KB
---===[ Qubes Security Bulletin #32 ]===---
August 15, 2017
Xen hypervisor and Linux kernel vulnerabilities (XSA-226 through XSA-230)
Summary
========
The Xen Security Team released several Xen Security Advisories today (XSA-226
through XSA-230) related to the grant tables mechanism used to share memory
between domains. The impact of these advisories ranges from data leaks to
system crashes and privilege escalations. See our commentary below for details.
Technical details
==================
Xen Security Advisory 226 [1]:
| Code to handle copy operations on transitive grants has built in retry
| logic, involving a function reinvoking itself with unchanged
| parameters. Such use assumes that the compiler would also translate
| this to a so called "tail call" when generating machine code.
| Empirically, this is not commonly the case, allowing for theoretically
| unbounded nesting of such function calls.
|
| A malicious or buggy guest may be able to crash Xen. Privilege
| escalation and information leaks cannot be ruled out.
Xen Security Advisory 227 [2]:
| When mapping a grant reference, a guest must inform Xen of where it
| would like the grant mapped. For PV guests, this is done by nominating
| an existing linear address, or an L1 pagetable entry, to be altered.
|
| Neither of these PV paths check for alignment of the passed parameter.
| The linear address path suitably truncates the linear address when
| calculating the L1 entry to use, but the path which uses a directly
| nominated L1 entry performs no checks.
|
| This causes Xen to make an incorrectly-aligned update to a pagetable,
| which corrupts both the intended entry and the subsequent entry with
| values which are largely guest controlled. If the misaligned value
| crosses a page boundary, then an arbitrary other heap page is
| corrupted.
|
| A PV guest can elevate its privilege to that of the host.
Xen Security Advisory 228 [3]:
| The grant table code in Xen has a bespoke semi-lockfree allocator for
| recording grant mappings ("maptrack" entries). This allocator has a
| race which allows the free list to be corrupted.
|
| Specifically: the code for removing an entry from the free list, prior
| to use, assumes (without locking) that if inspecting head item shows
| that it is not the tail, it will continue to not be the tail of the
| list if it is later found to be still the head and removed with
| cmpxchg. But the entry might have been removed and replaced, with the
| result that it might be the tail by then. (The invariants for the
| semi-lockfree data structure were never formally documented.)
|
| Additionally, a stolen entry is put on the free list with an incorrect
| link field, which will very likely corrupt the list.
|
| A malicious guest administrator can crash the host, and can probably
| escalate their privilege to that of the host.
Xen Security Advisory 229 [4]:
| The block layer in Linux may choose to merge adjacent block IO requests.
| When Linux is running as a Xen guest, the default merging algorithm is
| replaced with a Xen-specific one. When Linux is running as an x86 PV
| guest, some BIO's are erroneously merged, corrupting the data stream
| to/from the block device.
|
| This can result in incorrect access to an uncontrolled adjacent frame.
|
| A buggy or malicious guest can cause Linux to read or write incorrect
| memory when processing a block stream. This could leak information from
| other guests in the system or from Xen itself, or be used to DoS or
| escalate privilege within the system.
Xen Security Advisory 230 [5]:
| Xen maintains the _GTF_{read,writ}ing bits as appropriate, to inform the
| guest that a grant is in use. A guest is expected not to modify the
| grant details while it is in use, whereas the guest is free to
| modify/reuse the grant entry when it is not in use.
|
| Under some circumstances, Xen will clear the status bits too early,
| incorrectly informing the guest that the grant is no longer in use.
|
| A guest may prematurely believe that a granted frame is safely private
| again, and reuse it in a way which contains sensitive information, while
| the domain on the far end of the grant is still using the grant.
Commentary from the Qubes Security Team
========================================
It looks like the most severe of the vulnerabilities published today is
XSA-227, which is another example of a bug in memory management code for
para-virtualized (PV) VMs. As discussed before, in Qubes 4.0 [6], we've decided
to retire the use of PV virtualization mode in favour of fully virtualized VMs,
precisely in order to to prevent this class of vulnerabilities from affecting
the security of Qubes OS. We note however, that Qubes 3.2 uses PV for all VMs
by default.
XSA-228 seems to be another potentially serious vulnerability. While this does
not seem to be limited only to PV virtualization, we should note that it is a
race condition type of bug. Such types of vulnerabilities are typically
significantly more difficult to reliably exploit in practice.
The remaining vulnerabilities (XSA-229 and XSA-230) look even more theoretical.
We should also note that XSA-229 is a vulnerability in the Linux kernel's
implementation of the Xen PV block (disk) backend, not in the Xen hypervisor.
The Qubes architecture partly mitigates potential successful attacks exploiting
this vulnerability thanks to offloading some of the storage backend to USB and
(optionally) other VMs. The main system block backend still runs in dom0,
however, hence the inclusion of this bug in the bulletin.
Compromise Recovery
====================
Starting with Qubes 3.2, we offer Paranoid Backup Restore Mode, which was
designed specifically to aid in the recovery of a (potentially) compromised
Qubes OS system. Thus, if you believe your system might have been compromised
(perhaps because of the bugs discussed in this bulletin), then you should read
and follow the procedure described here:
https://www.qubes-os.org/news/2017/04/26/qubes-compromise-recovery/
Patching
=========
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes 3.2:
- Xen packages, version 4.6.6-29
- Kernel packages, version 4.9.35-20
For Qubes 4.0:
- Xen packages, version 4.8.1-5
- Kernel packages, version 4.9.35-20
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+19 will change due to the new Xen and kernel binaries,
and because of the regenerated initramfs.
These packages will migrate to the current (stable) repository over the next
two weeks after being tested by the community.
Credits
========
See the original Xen Security Advisories.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-226.html
[2] https://xenbits.xen.org/xsa/advisory-227.html
[3] https://xenbits.xen.org/xsa/advisory-228.html
[4] https://xenbits.xen.org/xsa/advisory-229.html
[5] https://xenbits.xen.org/xsa/advisory-230.html
[6] https://www.qubes-os.org/news/2017/07/31/qubes-40-rc1/
--
The Qubes Security Team
https://www.qubes-os.org/security/