---===[ Qubes Security Bulletin #28 ]===---

                          December 19, 2016


                Debian update mechanism vulnerability


Quick Summary
==============

The Debian Security Team has announced a security bug (DSA-3733-1) in
the signature verification of repository metadata, which could lead to
privilege escalation [1] within a Debian-based 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, and non-Debian-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 of the bug
=======================

As described in [1]:

| Jann Horn of Google Project Zero discovered that APT, the high level
| package manager, does not properly handle errors when validating
| signatures on InRelease files. An attacker able to man-in-the-middle
| HTTP requests to an apt repository that uses InRelease files
| (clearsigned Release files), can take advantage of this flaw to
| circumvent the signature of the InRelease file, leading to arbitrary
| code execution.

The Debian APT repository format includes the InRelease file, which is
a clearsigned Release file. APT, while verifying the file, splits it
into two files, `Release` and `Release.gpg`, in order to verify the
signature. However, it then splits the initial `InRelease` file again
in order to strip the signature (along with any potential leading or
trailing garbage) to get the actual `Release` file. Jann Horn
discovered that even though APT uses exactly the same code to split the
file in both cases, it can be tricked into outputting different results
in those two calls. The loop processing input looks like this:

    bool SplitClearSignedFile(std::string const &InFile, FileFd * const ContentFile,
          std::vector<std::string> * const ContentHeader, FileFd * const SignatureFile)
    {
       FILE *in = fopen(InFile.c_str(), "r");
       if (in == NULL)
          return _error->Errno("fopen", "can not open %s", InFile.c_str());
	(...)
	   char *buf = NULL;
	   size_t buf_size = 0;
	   while (getline(&buf, &buf_size, in) != -1)
	   {

	(...)

According to the getline documentation, it may return -1 only in the
case of:

 - invalid arguments
 - end of file

Authors believe that arguments are correct, so the only other case
considered is end of file. It turns out, however, that '-1' can also be
triggered by an out-of-memory error. This will result in the output
file being truncated. If this happens during the second InRelease
split, before APT finds the beginning of the signed data (the part
which would normally be discarded), then APT will use the found
(unverified) data as the Release file directly.

An attacker controlling a repository (by performing a man-in-the-middle
attack, breaking into the server, or simply being the server
administrator) could try to exploit this vulnerability in order to
substitute a normal package with a malicious one. Since a package can
contain post-installation scripts that APT will run automatically,
a malicious package can compromise the operating system into which it
is installed. In the case of Qubes OS, an attacker could try to use
this method to compromise a Debian-based TemplateVM (and, consequently,
all VMs based on it).

To trigger an out-of-memory condition during one call but not the
other, the discoverer used [2] very long lines, which may not fit into
the limited address space on a 32-bit system, additionally constrained
by ASLR. This attack vector allows successful exploitation in about one
out of four attempts.

The same attack vector isn't feasible for 64-bit systems (such as
Qubes VMs), because the address space is much larger. In particular,
it's larger than the available memory. But an attacker may try to hit a
real out-of-memory condition. This is a much less reliable approach and
should be easy to spot by the user, since the operation will likely
take a very long time and disk use will be very high (due to writing
data to swap).

Impact
=======

In theory, this bug allows an attacker to take over any Debian 8 or
Debian 9 template (which includes Whonix templates [3]) and,
consequently, any VMs based on those templates. However, for the
reasons explained above, the configuration used in Qubes OS happens to
makes 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.

Additional 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 has been 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 (before 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 Debian updater 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 use the FirewallVM to 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
Firewall VM). 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 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
=========

The specific packages that resolve the problem discussed in this
bulletin have been released by the Debian Security Team to the
appropriate repository. See the upstream advisory [1] for more details.

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 [5]. (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:
* qubes-template-debian-8-3.0.6-201612171620
* qubes-template-whonix-gw-3.0.6-201612182342
* qubes-template-whonix-ws-3.0.6-201612190628

For Qubes 3.1:
* qubes-template-debian-8-3.0.6-201612171837
* qubes-template-whonix-gw-3.0.6-201612190009
* qubes-template-whonix-ws-3.0.6-201612190633


Alternative patching, for non-critical TemplateVMs
===================================================

Users who do not rely on Debian-based VMs for any critical tasks may
instead opt just to install fixed APT packages. As the bug is present
in the update mechanism itself, special care should be taken while
performing the update:

1. Open a terminal in the affected TemplateVM.

2. Download repository metadata:

    sudo apt-get update

3. Check whether any of the downloaded `InRelease` files contain lines
   longer than 1024 characters [4]:

    wc -L /var/lib/apt/lists/*InRelease

4. If no lines are longer than 1024 characters, continue with the
   update:

    sudo apt-get dist-upgrade

Repeat this procedure for every non-critical affected TemplateVM.

Credits
========

This bug was found by Jonn Horn of Google Project Zero and
reported to the Debian Security Team.

Discussion of the bug and exploitation provided by Marek
Marczykowski-Górecki of the Qubes OS project.

Additional discussion of the bug's importance for Qubes OS
by Joanna Rutkowska of the Qubes OS project.

Revision and editing of this bulletin by Andrew David Wong
of the Qubes OS project.

References
===========

[1] https://www.debian.org/security/2016/dsa-3733
[2] https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467
[3] https://www.whonix.org/wiki/CVE-2016-1252
[4] https://lists.debian.org/debian-security/2016/12/msg00010.html
[5]
https://www.qubes-os.org/doc/reinstall-template/#manual-reinstallation-method

-- 
The Qubes Security Team
https://www.qubes-os.org/security/