-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #47: Insecure default DisposableVM networking configuration. 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 #47 in the qubes-secpack: <https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-047-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/> ``` ---===[ Qubes Security Bulletin #47 ]===--- 2019-02-19 Insecure default DisposableVM networking configuration Summary ======== In Qubes OS, one can attempt to limit the network access of a qube by either completely disconnecting it from any NetVM or by setting its firewall rules to disallow access. A malicious qube can circumvent these limits by launching a DisposableVM [1], which, in the default configuration, would have unrestricted network access. Moreover, even when a non-default DisposableVM is configured to have no network access (or limited access), other DisposableVMs started from _that_ DisposableVM can have full network access (unless explicitly configured otherwise). While limiting network access in this manner should not be considered to be an effective leak-prevention mechanism [1], we still consider this type of potentially ineffective network isolation to be a problem. Details ======== In Qubes 4.0, each DisposableVM is based on a DVM Template [2] with the `template_for_dispvm` property set to "True". The DisposableVM inherits all of its settings from the DVM Template, including the `netvm` property and firewall rules. Neither the network settings nor any other settings of the calling qube are considered. This design is intentional, as it allows much more flexibility over the previous model. For example, one could create different DVM Templates for different purposes, such as opening links (internet access), viewing documents (offline), printing (drivers installed), etc. Each DVM Template has appropriate network settings for its purpose. The important part of this design is the `default_dispvm` qube property. The value of this property is the DVM Template that will be used when starting new DisposableVMs from that qube. In the default configuration, Qubes OS has one default DVM Template, which has unrestricted network access. The default DVM Template is the default value of the global `default_dispvm` property, which is accessible via "Global settings" in the Qube Manager or via the `qubes-prefs` tool. This global property serves as the default value for the `default_dispvm` property for every qube. If the user creates a non-default DVM Template with limited network access, the user must also set the `default_dispvm` value (either globally or on a per-qube basis) in order for any new DisposableVM to be based on this non-default DVM Template. In the Whonix configuration shipped with Qubes, this issue is avoided by creating a separate DVM Template that uses the Whonix Gateway (`sys-whonix`) as its NetVM. The `default_dispvm` property of this DVM Template is set to itself. This DVM Template is the value of the `default_dispvm` property for every Whonix Workstation. This problem is partially mitigated when restoring a backup from Qubes 3.2. For each qube that has the `dispvm_netvm` property set to "none", a separate DVM Template named `disp-no-netvm` is created. This DVM Template has no direct network access. However, this DVM Template itself has the default value for its own `default_dispvm` property, so DisposableVMs started from it or from DisposableVMs based on it would have full network access. Vulnerable systems ================== This issue affects only Qubes 4.0. In Qubes 3.2, the network settings of DisposableVM are inherited from the calling qube's settings (more specifically, from its `dispvm_netvm` property, which defaults to the `netvm` property's value). The Whonix configuration shipped with Qubes 4.0 is not affected by this issue. If you have installed Whonix using a method other than the recommended `qubesctl` command [4], you should review the settings of your Whonix qubes. Specifically: - whonix-ws-14-dvm should have `netvm` set to sys-whonix - whonix-ws-14-dvm should have `default_dispvm` set to whonix-ws-14-dvm - anon-whonix and any other Whonix Workstations should have `default_dispvm` set to whonix-ws-14-dvm See the Whonix documentation [4] for details. Systems in which the default DVM Template is disconnected from the network (by settings its `netvm` property to "none") are not affected by this issue. Resolution ========== To mitigate this problem, we are implementing two changes: 1. When a DisposableVM is started, automatically set its `default_dispvm` to the DVM Template on which it is based. This means that, when a DisposableVM is started from another DisposableVM, they will both be based on the same DVM Template. Hence, they will have all the same settings, including the same network settings. This change will not affect DVM Templates for which user has manually modified the `default_dispvm` property. 2. Add a warning message in the Qube Settings GUI when the NetVM of a qube in the "Basic" tab is set to a different value than the NetVM of the default DVM Template set in the "Advanced" tab. Note that these changes concern only NetVM settings, not firewall settings. If you want your DisposableVMs to have the same firewall settings as the calling qube, you must adjust the firewall settings of appropriate DVM Template yourself. In the next version of Qubes, we will ship two DVM Templates by default: one with network access and one without. This was already previously discussed in issue #1121 [5]. Patching ========= The specific packages that resolve the problems discussed in this bulletin are as follows: For Qubes OS 4.0: - qubes-core-dom0 version 4.0.39 - qubes-manager version 4.0.28 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. Credits ======== The issue was reported by Vít 'v6ak' Šesták. References =========== [1] https://www.qubes-os.org/doc/disposablevm/ [2] https://www.qubes-os.org/doc/data-leaks/ [3] https://www.qubes-os.org/doc/glossary/#dvm-template [4] https://www.whonix.org/wiki/Qubes/Install [5] https://github.com/QubesOS/qubes-issues/issues/1121 - -- 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/THMrX1ywFAlxsitkACgkQ24/THMrX 1yy3CAf/f8Su5jWjDH6zDgCh9fLY6phWQXYZvTwU13kzCKAIBYzxUIs4cLZ1JRpG G52KmcOD62J5qgM3GBTZREYRfeI6Q0dZd8OBi4UxSfJ9BNgDAaIrTJf5J0FKfISC k+PfcxnVawrcXPjMB6rYEGbfFNp1Ykx8Tb2n0bHbgbz282kY7CgyXRlPnL9opknt ff7TmGqmPHs9qFLXZgmaPLF8VPKcTYT0OfeljvIzGGNkYVQQvoWpZVZggDJ7HbC+ 102PcExgkgkXbd+uPkDPEUynOpdXi84k8XD5r/BvglWm/qNi47OQPbg8WUOxjQWJ lBbxLpEiQxCslDwNo5xlaTJgO/I/9w== =K6hy -----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 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/20190219230145.GF9610%40mail-itl. For more options, visit https://groups.google.com/d/optout.