Based on Qubes Security Bulletin #28, isn’t the safest advice to reinstall the Debian and Whonix templates from scratch using the steps below?
Assume the worst and hope for the best? Always go full Ripley:
“Nuke the entire site [Debian/Whonix Templates] from orbit–it’s the only way to be sure”
In theory, this bug allows an attacker to take over any Debian 8 or Debian 9 template (which includes Whonix templates ) and, consequently, any VMs based on those templates. However, for the reasons explained above, the configuration used in Qubes OS happens to make this bug hard to exploit. Nevertheless, one should never underestimate the creativity of exploit authors, and thus one should assume that the bug is exploitable and patch immediately, just to stay on the safe side.
As the bug affects Debian-based templates themselves, just applying updates may not be enough, if those VMs are already compromised. Users, especially those using Debian-based VMs for sensitive tasks, should remove all affected templates and install fresh ones. This also applies to any customized Debian-based templates. Users with customized Debian-based templates should first note their customizations, remove the potentially compromised templates, install fresh templates, clone them, and reapply their customizations to the cloned templates.
The procedure for removing affected templates and installing fresh ones is documented as the “Manual Reinstallation Method” in the Qubes documentation on reinstalling TemplateVMs . (Please note that the simplified template reinstallation method described in the documentation, which uses
--action=reinstall, is not sufficient, since it will download the old, vulnerable template.)
Fixed APT packages are included in templates listed below:
For Qubes 3.2:
For Qubes 3.1:
(1) (Optional) Clone the existing target TemplateVM.
This can be a good idea if you’ve customized the existing template and want to keep your customizations. On the other hand, if you suspect that this template is broken, misconfigured, or compromised, you may want to remove it without cloning it.
(2) Create a temporary dummy template:
(3) Temporarily change all VMs based on the target TemplateVM to the new dummy template, or remove them.
This can be a good idea if you have user data in these VMs that you want to keep. On the other hand, if you suspect that these VMs (or the templates on which they are based) are broken, misconfigured, or compromised, you may want to remove them instead. You can do this in Qubes Manager by right-clicking on the VM and clicking Remove VM, or you can use the command qvm-remove in dom0.
Using a dummy template as a temporary template is preferable to using another real TemplateVM because you can’t accidentally boot any VMs from the dummy template. (There is no OS in the dummy template, so the boot will fail.)
(4) Uninstall the target TemplateVM from dom0:
$ sudo yum remove
For example, to uninstall the whonix-gw template:
$ sudo yum remove qubes-template-whonix-gw
(5) Reinstall the target TemplateVM in dom0:
$ sudo qubes-dom0-update --enablerepo= \
For example, to install the whonix-gw template:
$ sudo qubes-dom0-update --enablerepo=qubes-templates-community \ qubes-template-whonix-gw
(6) If you temporarily changed all VMs based on the target TemplateVM to the dummy template in step 3, change them back to the new target TemplateVM now. If you instead removed all VMs based on the old target TemplateVM, you can recreate your desired VMs from the newly reinstalled target TemplateVM now.