because thunderbird latest version breaks enigmail. Demi M. Obenour: > 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/b67f0c30-f2f7-22cd-5fc3-2b14f5c29321%40riseup.net.
