On 2018-01-23 23:29, Andrew David Wong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Dear Qubes Community, > > We have just updated Qubes Security Bulletin (QSB) #37: > Information leaks due to processor speculative execution bugs. > > The text of the main changes are reproduced below. For the full > text, please see the complete QSB in the qubes-secpack: > > <https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-037-2018.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 XSA-254 in the XSA Tracker: > > <https://www.qubes-os.org/security/xsa/#254> > > ``` > Changelog > ========== > > 2018-01-11: Original QSB published > 2018-01-23: Updated mitigation plan to XPTI; added Xen package versions > > [...] > > (Proper) patching > ================== > > ## Qubes 4.0 > > As explained above, almost all the VMs in Qubes 4.0 are > fully-virtualized by default (specifically, they are HVMs), which > mitigates the most severe issue, Meltdown. The only PV domains in Qubes > 4.0 are stub domains, which we plan to eliminate by switching to PVH > where possible. This will be done in Qubes 4.0-rc4 and also released as > a normal update for existing Qubes 4.0 installations. The only remaining > PV stub domains will be those used for VMs with PCI devices. (In the > default configuration, these are sys-net and sys-usb.) To protect those > domains, we will provide the Xen page-table isolation (XPTI) patch, as > described in the following section on Qubes 3.2. > > ## Qubes 3.2 > > Previously, we had planned to release an update for Qubes 3.2 that would > have made almost all VMs run in PVH mode by backporting support for this > mode from Qubes 4.0. However, a much less drastic option has become > available sooner than we and the Xen Security Team anticipated: what the > Xen Security Team refers to as a "stage 1" implementation of the Xen > page-table isolation (XPTI) mitigation strategy [5]. This mitigation > will make the most sensitive memory regions (including all of physical > memory mapped into Xen address space) immune to the Meltdown attack. In > addition, this mitigation will work on systems that lack VT-x support. > (By contrast, our original plan to backport PVH would have worked only > when the hardware supported VT-x or equivalent technology.) > > Please note that this mitigation is expected to have a noticeable > performance impact. While there will be an option to disable the > mitigation (and thereby avoid the performance impact), doing so will > return the system to a vulnerable state. > > The following packages contain the patches described above: > > - Xen packages, version 4.6.6-36 > > [...] > > Here is an overview of the VM modes that correspond to each Qubes OS > version: > > VM type \ Qubes OS version | 3.2 | 4.0-rc1-3 | 4.0-rc4 | > - ---------------------------------- | --- | --------- | ------- | > Default VMs without PCI devices | PV | HVM | PVH | > Default VMs with PCI devices | PV | HVM | HVM | > Stub domains - Default VMs w/o PCI | N/A | PV | N/A | > Stub domains - Default VMs w/ PCI | N/A | PV | PV | > Stub domains - HVMs | PV | PV | PV | > > ``` > > On 2018-01-11 08:57, Andrew David Wong wrote: >> Dear Qubes Community, >> >> We have just published Qubes Security Bulletin (QSB) #37: >> Information leaks due to processor speculative execution bugs. >> 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 #37 in the qubes-secpack: >> >> <https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-037-2018.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 XSA-254 in the XSA Tracker: >> >> <https://www.qubes-os.org/security/xsa/#254> >> >> ``` >> ---===[ Qubes Security Bulletin #37 ]===--- >> >> January 11, 2018 >> >> >> Information leaks due to processor speculative execution bugs >> >> Summary >> ======== >> >> On the night of January 3, two independent groups of researchers >> announced the results of their months-long work into abusing modern >> processors' so-called speculative mode to leak secrets from the system's >> privileged memory [1][2][3][4]. As a response, the Xen Security Team >> published Xen Security Advisory 254 [5]. The Xen Security Team did _not_ >> previously share information about these problems via their (non-public) >> security pre-disclosure list, of which the Qubes Security Team is a >> member. >> >> In the limited time we've had to analyze the issue, we've come to the >> following conclusions about the practical impact on Qubes OS users and >> possible remedies. We'll also share a plan to address the issues in a >> more systematic way in the coming weeks. >> >> Practical impact and limiting factors for Qubes users >> ====================================================== >> >> ## Fully virtualized VMs offer significant protection against Meltdown >> >> Meltdown, the most reliable attack of the three discussed, cannot be >> exploited _from_ a fully-virtualized (i.e. HVM or PVH) VM. It does not >> matter whether the _target_ VM (i.e. the one from which the attacker >> wants to steal secrets) is fully-virtualized. In Qubes 3.x, all VMs are >> para-virtualized (PV) by default, though users can choose to create >> fully-virtualized VMs. PV VMs do not protect against the Meltdown >> attack. In Qubes 4.0, almost all VMs are fully-virtualized by default >> and thus offer protection. However, the fully-virtualized VMs in Qubes >> 3.2 and in release candidates 1-3 of Qubes 4.0 still rely on PV-based >> "stub domains", making it possible for an attacker who can chain another >> exploit for qemu to attempt the Meltdown attack. >> >> ## Virtualization makes at least one variant of Spectre seem difficult >> >> Of the two Spectre variants, it _seems_ that at least one of them might >> be significantly harder to exploit under Xen than under monolithic >> systems because there are significantly fewer options for the attacker >> to interact with the hypervisor. >> >> ## All attacks are read-only >> >> It's important to stress that these attacks allow only _reading_ memory, >> not modifying it. This means that an attacker cannot use Spectre or >> Meltdown to plant any backdoors or otherwise compromise the system in >> any persistent way. Thanks to the Qubes OS template mechanism, which is >> used by default for all user and system qubes (AppVMs and ServiceVMs), >> simply restarting a VM should bring it back to a good known state for >> most attacks, wiping out the potential attacking code in the >> TemplateBasedVM (unless an attacker found a way to put triggers within >> the user's home directory; please see [8] for more discussion). >> >> ## Only running VMs are vulnerable >> >> Since Qubes OS is a memory-hungry system, it seems that an attacker >> would only be able to steal secrets from VMs running concurrently with >> the attacking VM. This is because any pages from shutdown VMs will >> typically very quickly get allocated to other, running VMs and get wiped >> as part of this procedure. >> >> ## PGP and other cryptographic keys are at risk >> >> For VMs that happen to be running concurrently with the attacking VM, it >> seems possible that these attacks might allow the attacker to steal >> cryptographic keys, including private PGP keys. >> >> ## Disk encryption and screenlocker passwords are at risk >> >> There is one VM that is always running concurrently with other VMs: the >> AdminVM (dom0). This VM contains at least two important user secrets: >> >> - The disk (LUKS) encryption key (and likely the passphrase) >> - The screenlocker passphrase >> >> In order to make use of these secrets, however, the attacker would have >> to conduct a physical attack on the user's computer (e.g. steal the >> laptop physically). Users who use the same passphrase to encrypt their >> backups may also be affected. >> >> Additional remedies available to Qubes users >> ============================================= >> >> Thanks to the explicit Qubes partitioning model, it should be >> straightforward for users to implement additional hygiene by ensuring >> that, whenever less trusted VMs are running, highly sensitive VMs are >> shut down. >> >> Additionally, for some of the VMs that must run anyway (e.g. networking >> and USB qubes), it is possible to recreate the VM each time the user >> suspects it may have been compromised, e.g. after disconnecting from a >> less trusted Wi-Fi network, or unplugging an untrusted USB device. In >> Qubes 4.0, this is even easier, since Disposable VMs can now be used for >> the networking and USB VMs (see [10]). >> >> The Qubes firewalling and networking systems also make it easy to limit >> the networking resources VMs can reach, including making VMs completely >> offline. While firewalling in Qubes is not intended to be a >> leak-prevention mechanism, it likely has this effect in a broad class >> class of attack scenarios. Moreover, making a VM completely offline >> (i.e. setting its NetVM to "none") is a more robust way to limit the >> ability of an attacker to leak secrets stolen from memory to the outside >> world. While this mechanism should not be considered bullet-proof -- it >> is still possible to mount a specialized attack that exploits a covert >> channel to leak the data -- it could be considered as an additional >> layer of defense. >> >> Finally, Qubes offers mechanisms to allow for additional protection of >> user secrets, especially cryptographic keys, such as PGP keys used for >> encryption and signing. Qubes Split GPG [6] allows the user to keep >> these keys in an isolated VM. So, for example, the user might be running >> her "development" qube in parallel with a compromised qube, while >> keeping the GPG backend VM (where she keeps the signing key that she >> uses to sign her software releases) shut down most of the time (because >> it's only needed when a release is being made). This way, the software >> signing keys will be protected from the attack. >> >> The user could take this further by using Qubes Split GPG with a backend >> qube running on a physically separate computer, as has been demonstrated >> with the Qubes USB Armory project [7]. >> >> (Proper) patching >> ================== >> >> Mitigations against the CPU bugs discussed here are in development but >> have not yet been released. The Xen Project is working on a set of >> patches (see XSA 254 [5] for updates). At the same time, we are working >> on similar mitigations where feasible. >> >> ## Qubes 4.0 >> >> As explained above, almost all the VMs in Qubes 4.0 are >> fully-virtualized by default (specifically, they are HVMs), which >> mitigates the most severe issue, Meltdown. The only PV domains in >> Qubes 4.0 are stub domains, which we plan to eliminate by switching to >> PVH where possible. This will be done in Qubes 4.0-rc4 and also >> released as a normal update for existing Qubes 4.0 installations. The >> only remaining PV stub domains will be those used for VMs with PCI >> devices. (In the default configuration, these are sys-net and >> sys-usb.) The Xen Project has not yet provided any solution for this >> [9]. >> >> ## Qubes 3.2 >> >> For Qubes 3.2, we plan to release an update that will make almost all >> VMs run in a fully-virtualized mode. Specifically, we plan to backport >> PVH support from Qubes 4.0 and enable it for all VMs without PCI >> devices. After this update, all VMs that previously ran in PV mode (and >> that do not have PCI devices) will subsequently run in PVH mode, with >> the exception of stub domains. Any HVMs will continue to run in HVM >> mode. >> >> There are two important points regarding the Qubes 3.2 update. First, >> this update will work only when the hardware supports VT-x or equivalent >> technology. Qubes 3.2 will continue to work on systems without VT-x, but >> there will be no mitigation against Meltdown on such systems. Users on >> systems that do not support VT-x are advised to take this into >> consideration when assessing the trustworthiness of their systems. >> >> Second, the Qubes 3.2 update will also switch any VMs that use a custom >> kernel to PVH mode, which will temporarily prevent them from working. >> This is a deliberate security choice to protect the system as a whole >> (rather than leaving VMs with custom kernels in PV mode, which would >> allow attackers to use them to mount Meltdown attacks). In order to use >> a VM with a custom kernel after the update (whether the custom kernel >> was installed in dom0 or inside the VM), users must either manually >> change the VM back to PV or change the kernel that the VM uses. (Kernel >>> =4.11 is required, and booting an in-VM kernel is not supported in PVH >> mode.) >> >> We'll update this bulletin and issue a separate announcement once >> patches are available. >> >> Suggested actions after patching >> ================================= >> >> While the potential attacks discussed in this bulletin are severe, >> recovering from these potential attacks should be easier than in the >> case of an exploit that allows the attacker to perform arbitrary code >> execution, resulting in a full system compromise. Specifically, we don't >> believe it is necessary to use Qubes Paranoid Backup Restore Mode to >> address these vulnerabilities because of the strict read-only character >> of the attacks discussed. Instead, users who believe they are affected >> should consider taking the following actions: >> >> 1. Changing the screenlocker passphrase. >> >> 2. Changing the disk encryption (LUKS) passphrase. >> >> 3. Re-encrypting the disk to force a change of the disk encryption >> _key_. (In practice, this can be done by reinstalling Qubes and >> restoring from a backup.) >> >> 4. Evaluating the odds that other secrets have been compromised, >> such as other passwords and cryptographic keys (e.g. private >> PGP, SSH, or TLS keys), and generate new secrets. It is unclear >> how easy it might be for attackers to steal such data in a >> real world Qubes environment. >> >> Technical discussion >> ===================== >> >> - From a (high-level) architecture point of view, the attacks discussed in >> this bulletin should not concern Qubes OS much. This is because, >> architecture-wise, there should be no secrets or other sensitive data in >> the hypervisor memory. This is in stark contrast to traditional >> monolithic systems, where there is an abundance of sensitive information >> living in the kernel (supervisor). >> >> Unfortunately, for rather accidental reasons, the implementation of the >> particular hypervisor we happen to be using to implement isolation for >> Qubes, i.e. the Xen hypervisor, undermines this clean architecture by >> internally mapping all physical memory pages into its address space. Of >> course, under normal circumstances, this isn't a security problem, >> because no one is able to read the hypervisor memory. However, the bugs >> we're discussing today might allow an attacker to do just that. This is >> a great example of how difficult it can be to analyze the security >> impact of a feature when limiting oneself to only one layer of >> abstraction, especially a high-level one (also known as the "PowerPoint >> level"). >> >> At the same time, we should point out that the use of full >> virtualization prevents at least one of the attacks, and incidentally >> the most powerful one, i.e. the Meltdown attack. >> >> However, we should also point out that, in Qubes 3.2, even HVMs still >> rely on PV stub domains to provide I/O emulation (qemu). In the case of >> an additional vulnerability within qemu, an attacker might compromise >> the PV stub domain and attempt to perform the Meltdown attack from >> there. >> >> This limitation also applies to HVMs in release candidates 1-3 of Qubes >> 4.0. Qubes 4.0-rc4, which we plan to release next week, should be using >> PVH instead of HVM for almost all VMs without PCI devices by default, >> thus eliminating this avenue of attack. As discussed in the Patching >> section, VMs with PCI devices will be the exception, which means that >> the Meltdown attack could in theory still be conducted if the attacker >> compromises a VM with PCI devices and afterward compromises the >> corresponding stub domain via a hypothetical qemu exploit. >> Unfortunately, there is not much we can do about this without >> cooperation from the Xen project [9][11]. >> >> Here is an overview of the VM modes that correspond to each Qubes OS >> version: >> >> VM type \ Qubes OS version | 3.2 | 3.2+ | 4.0-rc1-3 | 4.0-rc4 | >> ---------------------------------- | --- | ---- | --------- | ------- | >> Default VMs without PCI devices | PV | PVH | HVM | PVH | >> Default VMs with PCI devices | PV | PV | HVM | HVM | >> Stub domains - VMs w/o PCI devices | PV | N/A | PV | N/A | >> Stub domains - VMs w/ PCI devices | PV | PV | PV | PV | >> >> ("3.2+" denotes Qubes 3.2 after applying the update discussed above, >> which will result in most VMs running in PVH mode. "N/A" means "not >> applicable," since PVH VMs do not require stub domains.) >> >> Credits >> ======== >> >> See the original Xen Security Advisory. >> >> References >> =========== >> >> [1] >> https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html >> [2] https://meltdownattack.com/ >> [3] https://meltdownattack.com/meltdown.pdf >> [4] https://spectreattack.com/spectre.pdf >> [5] https://xenbits.xen.org/xsa/advisory-254.html >> [6] https://www.qubes-os.org/doc/split-gpg/ >> [7] https://github.com/inversepath/qubes-qrexec-to-tcp >> [8] https://www.qubes-os.org/news/2017/04/26/qubes-compromise-recovery/ >> [9] >> https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00403.html >> [10] https://www.qubes-os.org/news/2017/10/03/core3/ >> [11] https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ >> >> -- >> The Qubes Security Team >> https://www.qubes-os.org/security/ >> ``` > > - -- > Andrew David Wong (Axon) > Community Manager, Qubes OS > https://www.qubes-os.org > > -----BEGIN PGP SIGNATURE----- > > iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpoUcIACgkQ203TvDlQ > MDBAAxAAn2mtJMs44kCMKVWmuTEunqOy/mbOLnWnSvCN4e1pT8RnujvErUrVk7OO > j7lARLXX9GoNQZcmr3ex+7qWXxN/FWarU8/C8yGDWBEhZYl6kB4B53LtgWB1Ggbn > J+3q1nzoyBtohXmuUECMciHTnTnmGSboawts33yH8+ayxgJcWHF0x+XZl2Cnh2cT > bftJBtX57nVQaNSyWN2tPMe9toceX2kd/M9HGYpib9M8tDatrK/SB6H7hL/ZjaTM > wpmJOvzwLCwRLA7f0jWP7OBMua400bd7xmSgJS+yvOGZLKUF40RrEnSoylT91kHj > 3zMTvvjycPH59Qy4NGtrbTKBro1I7uzvxXt01aRstaGRYPebn6IckV99ORx/aWx9 > RxFlnzDKOoY9j0DEGzuCe9xHgWGVR6WpmKbofN8Kl9c0DAa29ZVVA3T/OF5uDkuk > SXGT1RRFIGbTKt8NQxXzmbYq07uK05X5yy16yoD1h9nPpXvXR/GmXuEC+xyErhMw > FmpixIYIy596xhKrws64xZpB5563krYe9A7yZVbR118v7dJzG7CdJpQ9erotqEio > xQLnZVPva8LoYDrLvVm33o6VkZW4fi6fpeI3kkQIBmYCfptVx7walbGgREeZOoLa > FIGnKlKpvolgse6f2WdFIySwM8ecNcfh6gHmJWrswpSRwpWExOw= > =JtlX > -----END PGP SIGNATURE-----
So... there are packages *to be released *at some undefined point in the near future? -- The following packages contain the patches described above: - Xen packages, version 4.6.6-36 -- via the normal dom0 update process ? would be nice to see it in simple English -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/421ee92be7e0524bb9c812e2fd6ea1b8%40riseup.net. For more options, visit https://groups.google.com/d/optout.
