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

                             2019-10-31


    Xen issues affecting PCI passthrough and PV domains (XSA-299, XSA-302)

Summary
========

On 2019-10-31, the Xen Security Team published the following Xen
Security Advisories (XSAs):


XSA-299 [1] "Issues with restartable PV type change operations":
| To avoid using shadow pagetables for PV guests, Xen exposes the actual
| hardware pagetables to the guest.  In order to prevent the guest from
| modifying these page tables directly, Xen keeps track of how pages are
| used using a type system; pages must be "promoted" before being used
| as a pagetable, and "demoted" before being used for any other type.
| Xen also allows for "recursive" promotions: i.e., an operating system
| promoting a page to an L4 pagetable may end up causing pages to be
| promoted to L3s, which may in turn cause pages to be promoted to L2s,
| and so on.  These operations may take an arbitrarily large amount of
| time, and so must be re-startable.
| 
| Unfortunately, making recursive pagetable promotion and demotion
| operations restartable is incredibly complicated, and the code
| contains several races which, if triggered, can cause Xen to drop or
| retain extra type counts, potentially allowing guests to get write
| access to in-use pagetables.
| 
| A malicious PV guest administrator may be able to escalate their
| privilege to that of the host.

XSA-302 [2] "passed through PCI devices may corrupt host memory after
deassignment":
| When a PCI device is assigned to an untrusted domain, it is possible
| for that domain to program the device to DMA to an arbitrary address.
| The IOMMU is used to protect the host from malicious DMA by making
| sure that the device addresses can only target memory assigned to the
| guest. However, when the guest domain is torn down the device is
| assigned back to dom0, thus allowing any in-flight DMA to potentially
| target critical host data.
| 
| An untrusted domain with access to a physical device can DMA into host
| memory, leading to privilege escalation.


Impact
=======

XSA-299 applies only to PV domains. Most of the domains in Qubes 4.0 are
PVH or HVM domains and are therefore not affected by XSA-299. However,
PV domains are still supported in Qubes 4.0, and they are specifically
used to host Qemu-instance-supporting HVM domains.

In the default Qubes 4.0 setup, several attacks would have to be chained
together in order to exploit this vulnerability. Specifically, an
attacker would have to:

1. Take control of an HVM domain, e.g., sys-usb, sys-net, or a
   user-created HVM domain. (Most user domains are PVH and are therefore
   not affected.)

2. Successfully attack a Qemu instance running in an associated PV
   stubdomain.

3. Finally, find some way to exploit the vulnerability described in
   XSA-299.

Moreover, since this vulnerability is a race condition, it is an
unreliable attack vector in real world scenarios.

XSA-302 also affects a limited set of domains in Qubes, namely, only
those with PCI devices assigned (sys-net and sys-usb in the default
configuration).

In order to exploit this vulnerability, an attacker would have to
control a cooperating device that could be programmed to perform a DMA
(direct memory access) attack with a sufficient delay (on the order of
seconds) such that the device had been reassigned to dom0 by the time
the attack occured.

Depending on internal connections, it may be also necessary for the
cooperating device to lack proper support for Function Level Reset
(FLR). (Most USB controllers do, in fact, lack proper support for FLR.)

While XSA-299 is unreliable to exploit in practice, XSA-302 can be
reliably exploited so long as all the aforementioned conditions are met.


Discussion
===========

The patches below isolate PCI devices out of dom0 using IOMMU, even
after those devices have been de-assigned from other domains (typically
less trusted domains like sys-net and sys-usb).

However, PCI devices can still perform DMA into most of the host memory
during early system startup (before dom0 assigns them to specific
domains). If the attacker were to program such a device to perform a DMA
attack in this window of opportunity during system startup, the
attacker could still compromise the system, even with the XSA-302
patches applied.

In practice, this means that devices containing internal writable
firmware or configuration storage are worse for system security than
those that have read-only storage and require firmware to be loaded
externally by a driver. Many people consider devices that require
loading "firmware blobs" to be less freedom-friendly, but the effect on
system trustworthiness is exactly the opposite. Such devices are
actually more trustworthy than those that have (possibly mutable)
firmware stored internally.

In addition, it's easier to reason about the firmware when it is
accessible to the user. Even if the firmware is in a binary form, it is
at least possible to verify its authenticity and that it wasn't modified
maliciously to target your specific device (e.g., by comparing hashes
against a public database). Naturally, a device with open-source
firmware (still loaded externally) would be even better. In the vast
majority of cases, however, a device that doesn't require loading
external firmware actually still has such firmware -- it's just hidden
inside and impossible to attest.


Patching
=========

The specific packages that resolve the problems discussed in this
bulletin are as follows:

  For Qubes OS 4.0:
  - Xen packages version 4.8.5-11

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

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

See the original Xen Security Advisories.


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

[1] https://xenbits.xen.org/xsa/advisory-299.html
[2] https://xenbits.xen.org/xsa/advisory-302.html

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