---===[ Qubes Security Bulletin #39 ]===---

                            May  8, 2018


          Xen vulnerability (XSA-260) and GUI daemon issue

Summary
========

Today, the Xen Security Team released Xen Security Advisories 260
through 262. Among these, only XSA-260 affects the security of Qubes
OS. The bug described in XSA-260 allows an attacker controlling a PV
domain to break out to dom0. This is a critical bug for Qubes 3.2, but
for Qubes 4.0 is much less severe, since all the domains that run
untrusted code in Qubes 4.0 are either PVH or HVM by default.

Additionally, Christoffer Kugg Jerkeby discovered a situation in which
Qubes GUI virtualization could allow a VM to produce a window with
borders that are white instead of the color of the VM's label. (In
Qubes, border colors are used as front-line indicators of trust.)
However, a VM cannot use this vulnerability to draw borders with a
non-white color other than the correct one. A very similar bug was
fixed as part of QSB #34 [1], but the fix missed this one case, as
described below.

Technical details
==================

Xen issues
-----------

Xen Security Advisory 260 [2]:

| When switching stacks, it is critical to have a matching stack segment
| and stack pointer.  To allow an atomic update from what would otherwise
| be two adjacent instructions, an update which changes the stack segment
| (either a mov or pop instruction with %ss encoded as the destination
| register) sets the movss shadow for one instruction.
| 
| The exact behaviour of the movss shadow is poorly understood.
| 
| In practice, a movss shadow delays some debug exceptions (e.g. from a
| hardware breakpoint) until the subsequent instruction has completed.  If
| the subsequent instruction normally transitions to supervisor mode
| (e.g. a system call), then the debug exception will be taken after the
| transition to ring0 is completed.
| 
| For most transitions to supervisor mode, this only confuses Xen into
| printing a lot of debugging information.  For the syscall instruction
| however, the exception gets taken before the syscall handler can move
| off the guest stack.
| 
| A malicious PV guest can escalate their privilege to that of the
| hypervisor.


GUI daemon issue
----------------

In QSB #34, we reported a similar bug involving the Qubes GUI daemon.
Whenever a VM displays a borderless window in Qubes, the GUI daemon is
responsible for drawing a colored border around it. In particular,
whenever a window content update is sent for the border area of a
borderless window, the GUI daemon is supposed to draw a 2px border in
that location.

The bug reported in QSB #34 occurred when a VM showed a borderless
splash screen window with a custom shape. While custom window shapes are
not supported in Qubes OS, VMs do not know this.  The VM still thought
the custom-shaped window was there, so it never sent window content
updates outside of the custom shape. Hence, it never sent window content
updates for the border areas of custom-shaped windows.  Since there were
no window content updates for the border areas, the GUI daemon failed to
recognize that it should draw colored borders in those locations. As a
result, custom-shaped splash screen windows had no borders at all. From
the GUI daemon's perspective, all VMs are untrusted insofar as they
cannot be relied upon to cooperate in drawing the correct colored
borders around their windows.  Therefore, the blame for this bug lies
solely with the GUI daemon, not with the VM that failed to send window
content updates.

While the patch for QSB #34 fixed the case just described, it failed to
fix the case in which no window image is sent at all before mapping the
window. In this latter case, the argument sanitization section of the
do_shm_update function is skipped, resulting in arguments being ignored.
This, in turn, results in the entire window, including its borders,
appearing as a solid white rectangle on the screen.

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-40
  - qubes-gui-dom0, version 3.2.13

  For Qubes 4.0:
  - Xen packages, version 4.8.2-7
  - qubes-gui-dom0, version 4.0.8

The packages are to be installed in dom0 via the Qubes VM Manager or via
the qubes-dom0-update command as follows:

  For updates from the stable repository (not immediately available):
  $ sudo qubes-dom0-update

  For updates from the security-testing repository:
  $ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing

A system restart will be required afterwards.

These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.

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 binaries.

Credits
========

The GUI issue was discovered by Christoffer Kugg Jerkeby.
For other issues, see the original Xen Security Advisories.

References
===========

[1] https://www.qubes-os.org/news/2017/10/12/qsb-34/
[2] https://xenbits.xen.org/xsa/advisory-260.html

--
The Qubes Security Team
https://www.qubes-os.org/security/