We have just published Qubes Security Bulletin (QSB) #054: Xen fix for XSA-302 found ineffective in Qubes configuration (XSA-306). The text of this QSB is reproduced below. This QSB and its accompanying signatures will always be available in the Qubes Security Pack (qubes-secpack).

View QSB #054 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-054-2019.txt

Learn about the qubes-secpack, including how to obtain, verify, and read it:

https://www.qubes-os.org/security/pack/

View all past QSBs:

https://www.qubes-os.org/security/qsb/

View XSA-306 in the XSA Tracker:

https://www.qubes-os.org/security/xsa/#306



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

                             2019-11-26


Xen fix for XSA-302 found ineffective in Qubes configuration (XSA-306)

Summary
========

In the course of re-verifying the fixes for QSB #52 (XSA-299, XSA-302)
[1], the Qubes Security Team discovered that the fix released by the
Xen Project for XSA-302 [2] is not effective for the configuration used
in Qubes OS.

On 2019-11-26, the Xen Security Team published the following Xen
Security Advisory (XSA):

XSA-306 [3] "Device quarantine for alternate pci assignment methods":
| XSA-302 relies on the use of libxl's "assignable-add" feature to
| prepare devices to be assigned to untrusted guests.
| 
| Unfortunately, this is not considered a strictly required step for
| device assignment.  The PCI passthrough documentation on the wiki
| describes alternate ways of preparing devices for assignment, and
| libvirt uses its own ways as well.  Hosts where these "alternate"
| methods are used will still leave the system in a vulnerable state
| after the device comes back from a guest.
| 
| An untrusted domain with access to a physical device can DMA into host
| memory, leading to privilege escalation.


Impact
=======

The original XSA-302 fix provided by the Xen Project is ineffective for
the configuration used in Qubes OS. Therefore, the impact is the same as
as the XSA-302 impact originally reported in QSB #52 (XSA-299, XSA-302).


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

The Qubes Security Team discovered this issue while re-verifying the Xen
Project's fixes for XSA-302. At that time, both XSA-302 and QSB #52 had
already been made public. Whether a disclosure has been made public is
significant to the Xen Security Policy [4]. Therefore, after discussion
with the Xen Security Team, we have decided to treat this as a separate
security issue, with a separate XSA, QSB, and embargo period.

From a security perspective, the new proposed fix for PCI device
isolation is much less fragile, since it no longer depends on toolstack
(libxl) behavior anymore.


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

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://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-052-2019.txt
[2] https://xenbits.xen.org/xsa/advisory-302.html
[3] https://xenbits.xen.org/xsa/advisory-306.html
[4] https://xenproject.org/developers/security-policy/

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