On 2019-10-31 12:12, Marek Marczykowski-Górecki wrote: > 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 > >
Enigmail reports that this message has a bad signature. Is this because I am using an incorrect key to verify it? Sincerely, Demi -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/4bd051dc-f425-899f-adca-ef8ab079835d%40gmail.com.
signature.asc
Description: OpenPGP digital signature
