Client-side software update verification failures
Exploitable vulnerabilities in client-side software update mechanisms that could have been mitigated by secure transport (TLS). Contributions welcome. All text taken from the vulnerability descriptions themselves, with additional emphasis mine.
- I consider exploitation or privilege escalation of the package tool/system itself (that would have been mitigated by secure transport) to be in scope.
- Issues only described as being triggered by malicious mirrors are assumed to also be vulnerable to MITM.
- Failure to verify the software update at all is currently provisionally in scope if it could have been mitigated by secure transport, but I'm waffling about it. Most of these are actual signature verification failures, and my original purpose was to highlight cases where claims of "It's OK to be HTTP because verification!" seem to me to be specious.
- Software components regularly used to verify integrity in other software pipelines are in scope.
Out of scope:
- Transport downgrade attacks - that force a connection from being encrypted to being unencrypted - are strongly related, but in my judgment are a different class of problem and so are considered out of scope. When an error in client-side verification is coupled with a transport encryption downgrade, it highlights the importance of both.
And to be clear, I'm a fan of both verification and transport encryption. I feel that each can help mitigate potential issues with the other. Both are necessary, but neither is sufficient.
As @martijn_grooten points out, TLS-intercepting middleboxes can break TLS-protected updates. This is a fair point. I would like to list any mitigations for that here as well.
- ASUS WebStorage
- Debian: 15 since 2009, latest in 2019
- None yet known, but since dl.amnesia.boum.org/tails defaults to HTTP, it's only a matter of time
- Note that you can manually change the URL to HTTPS, but the cert is for kernel.org or whatever mirror is used
- Trend Micro Email Encryption Gateway
- YAST - cross-Linux-distro package manager
- Attack tools
"The worst of these bugs, the subject of this blog post, allows a network man-in-the-middle (or a malicious package mirror) to execute arbitrary code on the user’s machine. This is especially bad because packages aren’t served over TLS when using the default repositories."
pacman prior to version 5.1.3 allows directory traversal when installing a remote package via a specified URL "pacman -U " due to an unsanitized file name received from a Content-Disposition header. pacman renames the downloaded package file to match the name given in this header. However, pacman did not sanitize this name, which may contain slashes, before calling rename(). A malicious server (or a network MitM if downloading over HTTP) can send a Content-Disposition header to make pacman place the file anywhere in the filesystem, potentially leading to arbitrary root code execution. Notably, this bypasses pacman's package signature checking. This occurs in curl_download_internal in lib/libalpm/dload.c.
The ASUS WebStorage software is vulnerable to a man-in-the-middle attack (MitM). Namely, the software update is requested and transferred using HTTP; once an update is downloaded and ready to execute, the software doesn’t validate its authenticity before execution. Thus, if the update process is intercepted by attackers, they are able to push a malicious update.
apt-get in apt before 0.7.21 does not check for the correct error code from gpgv, which causes apt to treat a repository as valid even when it has been signed with a key that has been revoked or expired, which might allow remote attackers to trick apt into installing malicious repositories.
APT before 0.8.15.2 does not properly validate inline GPG signatures, which allows man-in-the-middle attackers to install modified packages via vectors involving lack of an initial clearsigned message.
The pkgAcqMetaClearSig::Failed method in apt-pkg/acquire-item.cc in Advanced Package Tool (APT) 0.8.11 through 0.8.15.10 and 0.8.16 before 0.8.16~exp13, when updating from repositories that use InRelease files, allows man-in-the-middle attackers to install arbitrary packages by preventing a user from downloading the new InRelease file, which leaves the original InRelease file active and makes it more difficult to detect that the Packages file is modified and unsigned.
APT 0.7.x before 0.7.25 and 0.8.x before 0.8.16, when using the apt-key net-update to import keyrings, relies on GnuPG argument order and does not check GPG subkeys, which might allow remote attackers to install Trojan horse packages via a man-in-the-middle (MITM) attack.
APT 0.7.x before 0.7.25 and 0.8.x before 0.8.16, when using the apt-key net-update to import keyrings, relies on GnuPG argument order and does not check GPG subkeys, which might allow remote attackers to install altered packages via a man-in-the-middle (MITM) attack. NOTE: this vulnerability exists because of an incomplete fix for CVE-2012-3587.
apt 0.8.16, 0.9.7, and possibly other versions does not properly handle InRelease files, which allows man-in-the-middle attackers to modify packages before installation via unknown vectors, possibly related to integrity checking and the use of third-party repositories.
APT before 1.0.4 does not properly validate source packages, which allows man-in-the-middle attackers to download and install Trojan horse packages by removing the Release signature.
APT before 1.0.9 does not "invalidate repository data" when moving from an unauthenticated to authenticated state, which allows remote attackers to have unspecified impact via crafted repository data.
APT before 1.0.9 does not verify downloaded files if they have been modified as indicated using the If-Modified-Since header, which has unspecified impact and attack vectors.
APT before 1.0.9, when the Acquire::GzipIndexes option is enabled, does not validate checksums, which allows remote attackers to execute arbitrary code via a crafted package.
The apt-get download command in APT before 1.0.9 does not properly validate signatures for packages, which allows remote attackers to execute arbitrary code via a crafted package.
unattended-upgrades before 0.86.1 does not properly authenticate packages when the (1) force-confold or (2) force-confnew dpkg options are enabled in the DPkg::Options::* apt configuration, which allows remote man-in-the-middle attackers to upload and execute arbitrary packages via unspecified vectors.
The apt package in Debian jessie before 220.127.116.11.4, in Debian unstable before 1.4~beta2, in Ubuntu 14.04 LTS before 1.0.1ubuntu2.17, in Ubuntu 16.04 LTS before 1.2.15ubuntu0.2, and in Ubuntu 16.10 before 1.3.2ubuntu0.1 allows man-in-the-middle attackers to bypass a repository-signing protection mechanism by leveraging improper error handling when validating InRelease file signatures.
The mirror:// method implementation in Advanced Package Tool (APT) 1.6.x before 1.6.4 and 1.7.x before 1.7.0~alpha3 mishandles gpg signature verification for the InRelease file of a fallback mirror, aka mirrorfail.
Content injection in APT http method when using redirects.
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.
Dell UEFI BIOS https stack leveraged by the Dell BIOSConnect feature and Dell HTTPS Boot feature contains an improper certificate validation vulnerability. A remote unauthenticated attacker may exploit this vulnerability using a person-in-the-middle attack which may lead to a denial of service and payload tampering. [...] Dell BIOSConnect feature contains a buffer overflow vulnerability. An authenticated malicious admin user with local access to the system may potentially exploit this vulnerability to run arbitrary code and bypass UEFI restrictions.
The bootstrap tool is not secure on releases prior to 10.0 due to not checking the signature and could result in having an unofficial pkg(7) installed due to MITM attacks.
When signature_type specified in pkg.conf(5) is set to an unsupported method, the pkg(7) bootstrap utility would behave as if signature_type is set to "none" [...] MITM attackers may be able to use this vulnerability and bypass validation, installing their own version of pkg(8).
An attacker who can control the patch file can cause a crash or run arbitrary code under the credentials of the user who runs bspatch, in many cases, root. [in scope because freebsd-update and portsnap run bspatch; credit to @blakkheim]
An attacker who can control the patch file can cause a crash or run arbitrary code under the credentials of the user who runs bspatch, in many cases, root. [...] This issue was partially addressed in FreeBSD-SA-16:25.bspatch, but some possible integer overflows remained. [in scope because freebsd-update and portsnap run bspatch; credit to @blakkheim]
An attacker who can conduct man in the middle attack on the network at the time when portsnap is run can cause portsnap to execute arbitrary commands under the credentials of the user who runs portsnap, typically root.
libfetch(3) is a multi-protocol file transfer library included with FreeBSD and used by the fetch(1) command-line tool, pkg(8) package manager, and others.
An attacker in control of the URL to be fetched (possibly via HTTP redirect) may cause a heap buffer overflow, resulting in program misbehavior or malicious code execution.
This update to the Intel® Driver Update Utility mitigates the use of a non-SSL URL. Intel has released a new version of the software that provides mitigation of this issue.
The automatic update feature in KeePass 2.33 and earlier allows man-in-the-middle attackers to execute arbitrary code by spoofing the version check response and supplying a crafted update.
A bug in the fork of the opkg package manager before 2020-01-25 prevents correct parsing of embedded checksums in the signed repository index, allowing a man-in-the-middle attacker to inject arbitrary package payloads (which are installed without verification).
Trend Micro Email Encryption Gateway
An unvalidated software update vulnerability in Trend Micro Email Encryption Gateway 5.5 could allow a man-in-the-middle attacker to tamper with an update file and inject their own.
It was discovered that APT incorrectly handled certain filenames during package installation. If an attacker could provide a specially crafted package to be installed by the system administrator, this could cause APT to crash.
In libzypp before 20170803 it was possible to add unsigned YUM repositories without warning to the user that could lead to man in the middle or malicious servers to inject malicious RPM packages into a users system.
In libzypp before 20170803 it was possible to retrieve unsigned packages without a warning to the user which could lead to man in the middle or malicious servers to inject malicious RPM packages into a users system.
In libzypp before August 2018 GPG keys attached to YUM repositories were not correctly pinned, allowing malicious repository mirrors to silently downgrade to unsigned repositories with potential malicious content.
Attacks and attack tools
- General package managers and update systems
- Secure Software Updates: Disappointments and New Challenges (Bellissimo, Burgess, and Fu, 2006)
- A Look In the Mirror: Attacks on Package Managers (Samuel and Kappos, 2008)
- Package managers still vulnerable: how to protect your systems (S&K, 2009)
- Attacks on package managers (LWN summary of S&K work, Koen Vervloesem 2009)
- Survivable Key Compromise in Software Update Systems (Samuel, Mathewson, Cappos, and Dingledine, 2010)
- Reducing metadata leakage from software updates (Guardian Project, 2014)
- Secure distribution of RPM packages (Florian Weimer, 2015)
- NYU's Secure Systems Laboratory
- FreeBSD upgrade/ports/packages issues (assembled by @blakkheim)
- Sparkle (macOS software updater framework that relies solely on signing)
- VLC (uses Sparkle, but VLC asserts that manual verification is a suitable workaround for lack of TLS)
- VLC Update occurs over HTTP - issue 19987 (2014) - closed as WONTFIX