QSB-067: Multiple RPM vulnerabilities https://www.qubes-os.org | Qubes OS📢

QSB-067: Multiple RPM vulnerabilities
https://www.qubes-os.org/news/2021/03/19/qsb-067/

We have just published Qubes Security Bulletin (QSB) 067: Multiple RPM vulnerabilities.
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack (qubes-secpack).

View QSB-067 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-067-2021.txt

Learn about the qubes-secpack, including how to obtain, verify, and read it:

https://www.qubes-os.org/security/pack/

View all past QSBs:

https://www.qubes-os.org/security/bulletins/



---===[ Qubes Security Bulletin 067 ]===---

2021-03-19


Multiple RPM vulnerabilities


User action required
=====================

Users must install the following specific packages in order to address
the issues discussed in this bulletin:

For Qubes 4.0:
- rpm 4.14.2.1 (plus rebuilt packages to link with the new rpm)
- qubes-core-dom0-linux 4.0.29
- qubes-mgmt-salt-dom0-update 4.0.10

For Qubes 4.1:
- qubes-core-dom0-linux 4.1.10
- qubes-mgmt-salt-dom0-update 4.1.6

The packages are to be installed in dom0 via the Qubes Update tool [4]
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

After installing the updates in dom0, it is necessary to install updates
in Fedora-based TemplateVMs and StandaloneVMs. This can be
done via the Qubes Update tool [4] or using qubesctl (salt) as follows:

$ sudo qubesctl --skip-dom0 --templates --standalones state.sls update.qubes-vm

These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.


Summary
========

Demi M. Obenour has discovered several issues in the RPM package
manager:

- CVE-2021-20271[1] RPM: Signature checks bypass via corrupted RPM
package
- CVE-2021-3421[2] RPM: unsigned signature header leads to string
injection into an RPM database
- CVE-2021-20266[3] RPM: missing length checks in hdrblobInit()

These issues allow an attacker who controls packages the user downloads
to inject malicious content that, under some conditions, may not be
detected by signature verification. Specifically, they allow the
attacker to modify parts of the package header that are not protected by
the signature and that are later integrated into the RPM database. This
allows for corrupting the RPM database and preventing further updates of
select packages. In the case of Fedora TemplateVMs, this also allows
for arbitrary code execution.

The CVE-2021-20271 exploit takes advantage of multiple headers in the
RPM package format. In a proper RPM package, the signature is placed in
a separate header (called the "signature header") and, if present, is
verified by librpm when loading the file (according to the requested
verification level). An RPM package also contains a "main header" that
includes all the other package metadata. The main header is protected by
a signature in the signature header. The payload is protected either by
a signature in the signature header or by a SHA-256 hash located in the
main header. The ability to distinguish between these two headers is
available to librpm internals but not to external librpm users.

A malformed package may contain a signature in the main header instead
of the signature header. Librpm will reject such a package only if a
strict signature check was requested. Otherwise, it will treat the
package as unsigned. DNF, on the other hand, has no way to check whether
the signature was in the correct header. It will load the package and,
seeing a signature, will assume that it was verified by librpm. This