---===[ 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/