---===[ Qubes Security Bulletin #46 ]===--- 2019-01-23 APT update mechanism vulnerability Summary ======== The Debian Security Team has announced a security vulnerability (DSA-4371-1) in the Advanced Package Tool (APT). The vulnerability lies in the way APT performs HTTP redirect handling when downloading packages. Exploitation of this vulnerability could lead to privilege escalation [1] inside an APT-based VM, such as a Debian or Whonix VM. This bug does _not_ allow escape from any VM or enable any attacks on other parts of the Qubes system. In particular, this bug does _not_ affect dom0, the Xen hypervisor, or any non-APT-based VMs. Nevertheless, we have decided to release this bulletin, because if a TemplateVM is affected, then every VM based on that template is affected. Description ============ As described in [1]: | Max Justicz discovered a vulnerability in APT, the high level package | manager. The code handling HTTP redirects in the HTTP transport | method doesn't properly sanitize fields transmitted over the wire. | This vulnerability could be used by an attacker located as a | man-in-the-middle between APT and a mirror to inject malicious content | in the HTTP connection. This content could then be recognized as a | valid package by APT and used later for code execution with root | privileges on the target machine. Impact ======= Users who use Debian or Whonix VMs are affected. Users who use only Fedora VMs are not affected. Although we do not provide any other official or community APT-based templates, any other APT-based VMs that users have installed on their own should also be assumed to be affected. Discussion =========== Normally, we do not release Qubes Security Bulletins (QSBs) to address vulnerabilities that only affect VMs internally without affecting the rest of the Qubes system, i.e. vulnerabilities that do not undermine the Qubes security model. For example, we do not release QSBs to address bugs in Firefox or Linux kernel USB stacks, because Qubes OS was designed under the primary assumption that in a typical desktop OS there will be countless such bugs and that humankind will never be able to patch all of them promptly (at least not as quickly as developers introduce new bugs). This is, in fact, the very reason we designed Qubes OS as an implementation of the security-by-compartmentalization approach. The APT update bug discussed today is, however, somewhat special. While it is indeed a bug that only affects VMs internally, it could allow an attacker to compromise TemplateVMs, which are used as a basis for creating other VMs, such as AppVMs and ServiceVMs. If a TemplateVM is compromised, then all the VMs based on that TemplateVM will be compromised. Since AppVMs operate directly on user data, and since ServiceVMs can be critical to user privacy (especially in the case of Whonix and VPN ProxyVMs), this is a serious matter. In Qubes OS, we take special precautions to make TemplateVMs difficult to compromise. For example, we block all network connections to and from templates, with one exception: We allow templates to connect to the so-called "Update Proxy" (which runs in the NetVM). This allows the TemplateVM to retrieve updates while protecting users from accidentally using TemplateVMs to perform risky activities, such as browsing the web. Since the bug under discussion has the potential to subvert this very protection mechanism, we've decided to issue this QSB. We would like to point out, however, that Qubes OS does a good job of mitigating this kind of a vulnerability. Instead of having to reinstall the whole operating system from scratch, Qubes users may need only to reinstall the affected template(s). If users are concerned that potential attackers may have compromised not only the root filesystem of the template, but also attempted to infect user files in AppVM filesystems (e.g. ~/.bashrc or a Web browser profile directory), Qubes allows for mounting each of the suspected AppVM private images into a different, trusted VM, based on a trusted template, for "offline" analysis and cleanup, allowing users to preserve their data. Patching ========= If you are a Qubes user, you should remove all APT-based (including Debian and Whonix) TemplateVMs and StandaloneVMs, then install fresh ones. You can do this by performing the following steps on each such TemplateVM: 1. Note any customizations you have made to the target TemplateVM. 2. Temporarily change all VMs based on the target TemplateVM to a different template, or remove them. Temporarily switching to a different template 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 are compromised, you may want to remove them instead. You can remove them in Qube(s) Manager by right-clicking on the VM and clicking "Remove VM" or "Delete qube," or you can use this command in dom0: $ qvm-remove <vm-name> 3. Uninstall the target TemplateVM from dom0: $ sudo dnf remove <template-package-name> This requires specifying the template package name (not the TemplateVM's name). A list of affected template package names is provided below. For example, to uninstall the whonix-gw-14 template: $ sudo dnf remove qubes-template-whonix-gw-14 4. Reinstall the target TemplateVM in dom0: $ sudo qubes-dom0-update --enablerepo=<optional-additional-repo> \ <template-package-name> This requires specifying the template package name (not the TemplateVM's name). A list of new (fixed) template package names is provided below. For example, to install the whonix-gw-14 template: $ sudo qubes-dom0-update --enablerepo=qubes-templates-community \ qubes-template-whonix-gw-14 Then verify the right version was installed: $ rpm -q qubes-template-whonix-gw-14 qubes-template-whonix-gw-14-4.0.1-201901231238.noarch In accordance with our standard policy, new (fixed) template packages will first reside in the testing repositories for approximately two weeks before migrating to the stable repositories. In order to install a templates package from its testing repository, you must enable that repository. For example, to install the whonix-gw-14 template from its testing repository: $ sudo qubes-dom0-update --enablerepo=qubes-templates*testing \ qubes-template-whonix-gw-14 5. If you removed the "sys-whonix" and "anon-whonix" VMs in step 2 and wish to re-create them: $ sudo qubesctl state.sls qvm.anon-whonix 6. If you temporarily changed all VMs based on the target TemplateVM to a different template in step 2, change them back to the fresh TemplateVM now. If you instead removed all VMs based on the old TemplateVM, you can recreate your desired VMs from the fresh TemplateVM now. 7. If you noted any template customizations in step 1, clone the target TemplateVM, then reapply your customizations to the clone. Old (vulnerable) and new (fixed) Qubes TemplateVM packages are listed for each supported Qubes OS version in the tables below: Qubes 4.0: +------------------------------------------------------------------------------+ | Old (Vulnerable) | New (Fixed) | | --------------------------- | ---------------------------------------------- | | qubes-template-debian-8 | qubes-template-debian-8-4.0.1-201901231241 | | qubes-template-debian-9 | qubes-template-debian-9-4.0.1-201901230644 | | qubes-template-whonix-gw-14 | qubes-template-whonix-gw-14-4.0.1-201901231238 | | qubes-template-whonix-ws-14 | qubes-template-whonix-ws-14-4.0.1-201901231238 | +------------------------------------------------------------------------------+ Qubes 3.2: +--------------------------------------------------------------------------+ | Old (Vulnerable) | New (Fixed) | | --------------------------- | ------------------------------------------ | | qubes-template-debian-8 | qubes-template-debian-8-4.0.1-201901230645 | | qubes-template-debian-9 | qubes-template-debian-9-4.0.1-201901230645 | | qubes-template-whonix-gw-14 | not supported | | qubes-template-whonix-ws-14 | not supported | +--------------------------------------------------------------------------+ Alternative patching for non-critical TemplateVMs ================================================== Users who do not rely on APT-based VMs for any critical tasks may instead opt just to install fixed APT packages. This is _not_ secure if the template has already been compromised. If you are not willing to take the risk that the template may already be compromised, you should instead follow the instructions in the previous section to completely remove the template, then install a fresh one. As the bug is present in the update mechanism itself, special care should be taken while performing the update, as described in [1]. We include those steps in GUI tools used to update, so updating the GUI tools and performing the template update with either of them will also apply the fix in a safe way, as long as the TemplateVM is not already compromised. Important: Listed below are the minimum package versions that will perform APT updates safely. However, after installing these packages, you must also update all APT-based TemplateVMs normally through the Qubes VM Manager. Installing the packages listed below is not enough. Qubes 4.0: - qubes-desktop-linux-manager 4.0.14 (updates widget) - qubes-manager 4.0.27 (Qube Manager) Qubes 3.2: - qubes-manager 3.2.14 (Qubes VM Manager) 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 Now you can safely update your APT-based TemplateVMs through the Qubes VM Manger. Credits ======== This vulnerability was discovered by Max Justicz and reported to the Debian Security Team. References =========== [1] https://www.debian.org/security/2019/dsa-4371 -- The Qubes Security Team https://www.qubes-os.org/security/