2021-03-19 13:42:27
allows for bypassing package signature verification.
The other bugs (CVE-2021-20266, CVE-2021-3421) concern incorrect parsing
of the signature header (which, while it contains the signature, is
itself unsigned). These bugs lead either to crashing or to corrupting
the RPM database (if such a malformed package is installed).
While Fedora will release its own patches in due course, we apply a
mitigation that prevents the privilege escalation aspect of these
issues. We configure RPM to always verify package signatures, even if a
higher level package manager (like DNF) does not explicitly request it.
This way, bypassing the signature check in DNF is not enough to
compromise an entire TemplateVM. Note that this change also prevents the
installation of unsigned RPM packages, even when explicitly requested.
See the "Side effects" section below.
For the dom0 aspect of these issues in Qubes 4.0, we update RPM to a
version that is not vulnerable. We have decided to update to the next
major version of RPM (from 4.13 to 4.14). This is because, besides the
security fix itself (which could be backported), version 4.14 has
significantly improved integrity verification. In 4.14, the macro
_pkgverify_level can be used to require that all packages be signed by a
trusted key. It defaults to "digest", meaning that only checksums must
be present, but we have set it to "all", requiring that all packages be
signed. Additionally, the checks performed before importing a package
have been significantly enhanced, which substantially reduces the attack
surface prior to integrity verification.
In the near future, we will also deploy an extra tool to perform
preliminary validation of all RPM packages in dom0 before handing them
over to RPM.
Impact
=======
The impact differs between Fedora templates and dom0:
1. For Fedora templates, an attacker who controls packages that the user
downloads can completely bypass package signature verification and
fully compromise Fedora templates.
2. For dom0, an attacker who controls packages that the user downloads
can corrupt the RPM database and (almost silently) prevent further
updates of select packages.
The attack requires control over the contents of downloaded packages.
This requirement differs slightly between Fedora templates and dom0:
1. For Fedora templates, the attacker would either have to
a. compromise the Fedora infrastructure that is serving updates or
b. perform a man-in-the-middle attack on the HTTPS connection used to
download the repository metadata (which contains package hashes).
2. For dom0, the attacker would either have to attack the user's
repository access (as in the Fedora template case) or compromise the
UpdateVM (sys-firewall in the default configuration).
Side effects
=============
The mitigation forces signature verification in RPM regardless of other
options. This means that RPM will refuse to install packages that are
unsigned (or signed with an untrusted signature), even when explicitly
requested to do so. This breaks use cases such as installing
locally-built packages and installing manually-downloaded packages the
integrity of which was verified separately (which is often the case for
closed-source software).
In such cases, neither `dnf install /path/to/the/package.rpm` nor `rpm
-i /path/to/the/package.rpm` will work any longer. Instead, to install a
package without a trusted signature (that has been verified by other
means), use the following command:
rpm --define '_pkgverify_level digest' -i /path/to/the/package.rpm
If the package has any dependencies, the above command will list them,
and they will have to be installed with `dnf` manually.
Credits
========
These issues were discovered and reported by Demi M. Obenour.
References
===========
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1934125
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1927747
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1927741
517 views10:42
Q
