---===[ 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/