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/