On Thursday, January 11, 2018 at 10:26:53 PM UTC-5, cooloutac wrote: > On Thursday, January 11, 2018 at 9:57:50 AM UTC-5, Andrew David Wong wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > 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----- > > > > iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpXe0cACgkQ203TvDlQ > > MDDtmxAAwyTkRWQm2HWcQtcNog4ni/KcR1fVUS/iI/GTe9NE3ikbljQ2HKoGhMWF > > C9/R14FyIYdSnRXWAP4FGb8tH0Pf4WFyQNegD3sDLPOxUIaSoaclLKWLLcWWpkJS > > +zyomfsalpuHQ4AZZtd2PDTqpeslHy9GHvmTDDw8Pqq1Ih1d0ij4LtnRsyHWDt1B > > kP6A9dC0zAsXFQnu2dSJNQcCltAdKTdD1myJ+08ot7+f1hiaWU2sllqJEO+QM/Jh > > 68TXEBB82XeBB4ad2nuKmTCyaYKJQB9oWi6yHVFknOM/QcNdhmAEB2YkQCNplGyD > > QLfoQWJGidhu7wLzsqhtoZJC+vVg+wN1+i8h54jPwNMGnqnhhgiy4gf2QghOsZ7q > > 5/McepdncZ0tRuXzE4FkDhyl2h5v2rZhrPDQxcyfWLon22uW0xws5vJsyJy7xMRY > > Fp4J4j+jSJjq61Hd9oCiCvFzs08y/p6vVHThcV6iy+MYJTS4QiTqf7w1JqR/GYxh > > jMzTJyEUhUUVKUV/rlJTPg6CxUiC5V441iEShfRqS/LSHXNUvj2l+7TPhe8U93yU > > L74qJysYcZsPJxEoAois6j8AKjcP1WCqhoDaxdFjkEBHjEm40JMzJJDCJk9eaFSL > > oz9uCLCvB1IGRvYKYfbiU16NwIZ4vRFax/HRtOBicq/p1wad2X4= > > =pAsX > > -----END PGP SIGNATURE----- > > so people saying the intel meltdown bios patch slows performance. I got an > increase in performance lmao. probably depends on os though.
but also in my particular case they also addressed other bugs, but intel pushed the bios patch for meltdown, so worth a check from your boards manufacturer site. -- 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/8a5e3a6a-2519-48e0-ac7d-302a305d7be3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
