-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear Qubes community,
We have just published Qubes Security Bulletin (QSB) #28: Debian update mechanism vulnerability. The current text of this QSB is reproduced below. The latest version, including any future corrections, will always be available in the Qubes Security Pack (qubes-secpack). View QSB #28 in the qubes-secpack: https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-028-2016.txt Learn about the qubes-secpack, including how to obtain, verify, and read it: https://www.qubes-os.org/doc/security-pack/ View all past QSBs: https://www.qubes-os.org/doc/security-bulletins/ - -------------------------------------------------------------------------------- ---===[ 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/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJYWQyWAAoJENuP0xzK19csPP8H/iQ3HlIoL262L/xytkdKEYtF +dHaxAovFpOQ6Ixs9zokR0r2q0JAJDg/QC3qgSlr8c3fkJ5reOTa8JcVrZNJFbKX hZz7nRyzmw67y2H2SY0liC1kIYJ2idfBJsFSAT8ImrDNqi30cj7mDBKpCjeRXGDH 1hzlDWrALUJrP5V9qIgIQ3FmotXUSMxvq8OO7ammJtgN+QqHfYSYNjL2Wf22BC4t ZNTYxeIr//uYCmsI4oi8x/qwBk8KhWCGncQBLsVt9TzYwwccTx5fEPFlmOIp8c1w qt90IoT1nrEOxSHkUKjTYee5YGZoRjOnHd2hzrLgoDfH5TVpDz2GDWVtPcRt65I= =snpd -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20161220104853.GS1239%40mail-itl. For more options, visit https://groups.google.com/d/optout.