-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #052: Xen issues affecting PCI passthrough and PV domains (XSA-299, XSA-302). 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 #052 in the qubes-secpack: https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-052-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/bulletins/ View the Xen Security Advisory (XSA) Tracker: https://www.qubes-os.org/security/xsa/ ``` ---===[ 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/ ``` - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl27CAkACgkQ24/THMrX 1yyVYQf+OBmOSFrr5l5fSLMfqrPWCxiq8rb1O1SXQ6lN1akxEfx7GO36fbpV47/K Qu7S3MZhfVUf7y9xWcKrcYdUtnXhRvV5az17gF9JOYSinHIxHPnOyXTu/vWtTQPW 057d2ZnQiTijN22ELlNQy6yRHzutUxSfT9vpRH0BCuoM3yR7Q9EUNKMIy/A5lF6q L1Hkdtnu+1j+2kzsaE5/HrjvN/lQ0KRBgDpYXWrExgQOYYnAigvUeRefH4/dDERF BISdEo4w49pyU2Hb54YjTit+NbgfkVVIyuU8wC63reImmbrCQHT5hdWUpP2c1ymt AWadPawOVgGmDDFeFaHfCbTYoU0ahg== =MUDq -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191031161258.GX1410%40mail-itl.
