Allele Security Alert
Insecure default DisposableVM networking configuration
Invisible Things Lab
Qubes OS 4.0
For Qubes OS 4.0:
– qubes-core-dom0 version 4.0.39
– qubes-manager version 4.0.28
Proof of concept
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, 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, we still consider this type of potentially ineffective network isolation to be a problem.
In Qubes 4.0, each DisposableVM is based on a DVM Template 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.
Vít ‘v6ak’ Šesták
QSB #47: Insecure default DisposableVM networking configuration
If there is any error in this alert or you wish a comprehensive analysis, let us know.
Last modified: February 25, 2019