Hi, I've tried to install the updates. Even after removing systemtap and when using --clean, I am unable to install it. IIUC, I am trying to install it too soon:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing --clean Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time... 40 files removed Fedora 25 - x86_64 - Updates 272 kB/s | 24 MB 01:29 Fedora 25 - x86_64 3.6 MB/s | 50 MB 00:14 Qubes Dom0 Repository (updates) 1.3 MB/s | 1.3 MB 00:01 Qubes Dom0 Repository (security-testing) 1.5 MB/s | 3.0 MB 00:02 determining the fastest mirror (14 hosts).. done.-- B/s | 0 B --:-- ETA Qubes Templates repository 2.2 kB/s | 5.9 kB 00:02 Error: Problem 1: problem with installed package satyr-0.21-2.fc25.x86_64 - cannot install the best update candidate for package satyr-0.21-2.fc25.x86_64 - nothing provides librpm.so.8()(64bit) needed by satyr-0.21-2.1.fc25.x86_64 Problem 2: problem with installed package qubes-core-dom0-linux-4.0.28-1.fc25.x86_64 - cannot install the best update candidate for package qubes-core-dom0-linux-4.0.28-1.fc25.x86_64 - nothing provides rpm >= 4.14 needed by qubes-core-dom0-linux-4.0.29-1.fc25.x86_64 Problem 3: problem with installed package python3-hawkey-0.6.4-3.fc25.x86_64 - cannot install the best update candidate for package python3-hawkey-0.6.4-3.fc25.x86_64 - nothing provides librpm.so.8()(64bit) needed by python3-hawkey-0.6.4-3.1.fc25.x86_64 - nothing provides librpmio.so.8()(64bit) needed by python3-hawkey-0.6.4-3.1.fc25.x86_64 Problem 4: problem with installed package libsolv-0.6.29-2.fc25.x86_64 - cannot install the best update candidate for package libsolv-0.6.29-2.fc25.x86_64 - nothing provides librpm.so.8()(64bit) needed by libsolv-0.6.29-2.1.fc25.x86_64 Problem 5: problem with installed package hawkey-0.6.4-3.fc25.x86_64 - cannot install the best update candidate for package hawkey-0.6.4-3.fc25.x86_64 - nothing provides librpm.so.8()(64bit) needed by hawkey-0.6.4-3.1.fc25.x86_64 - nothing provides librpmio.so.8()(64bit) needed by hawkey-0.6.4-3.1.fc25.x86_64 Problem 6: problem with installed package drpm-0.3.0-3.fc25.x86_64 - cannot install the best update candidate for package drpm-0.3.0-3.fc25.x86_64 - nothing provides librpm.so.8()(64bit) needed by drpm-0.3.0-3.1.fc25.x86_64 - nothing provides librpmio.so.8()(64bit) needed by drpm-0.3.0-3.1.fc25.x86_64 Problem 7: problem with installed package deltarpm-3.6-17.fc25.x86_64 - cannot install the best update candidate for package deltarpm-3.6-17.fc25.x86_64 - nothing provides librpm.so.8()(64bit) needed by deltarpm-3.6-17.1.fc25.x86_64 - nothing provides librpmio.so.8()(64bit) needed by deltarpm-3.6-17.1.fc25.x86_64 Problem 8: problem with installed package createrepo_c-libs-0.10.0-6.fc25.x86_64 - cannot install the best update candidate for package createrepo_c-libs-0.10.0-6.fc25.x86_64 - nothing provides librpm.so.8()(64bit) needed by createrepo_c-libs-0.10.0-6.1.fc25.x86_64 - nothing provides librpmio.so.8()(64bit) needed by createrepo_c-libs-0.10.0-6.1.fc25.x86_64 Problem 9: problem with installed package createrepo_c-0.10.0-6.fc25.x86_64 - cannot install the best update candidate for package createrepo_c-0.10.0-6.fc25.x86_64 - nothing provides librpm.so.8()(64bit) needed by createrepo_c-0.10.0-6.1.fc25.x86_64 - nothing provides librpmio.so.8()(64bit) needed by createrepo_c-0.10.0-6.1.fc25.x86_64 Problem 10: problem with installed package PackageKit-1.1.5-1.fc25.x86_64 - cannot install the best update candidate for package PackageKit-1.1.5-1.fc25.x86_64 - nothing provides librpm.so.8()(64bit) needed by PackageKit-1.1.5-1.1.fc25.x86_64 - nothing provides librpmio.so.8()(64bit) needed by PackageKit-1.1.5-1.1.fc25.x86_64 Problem 11: problem with installed package python2-deltarpm-3.6-17.fc25.x86_64 - cannot install the best update candidate for package python2-deltarpm-3.6-17.fc25.x86_64 - package python2-deltarpm-3.6-17.1.fc25.x86_64 requires deltarpm(x86-64) = 3.6-17.1.fc25, but none of the providers can be installed - nothing provides librpm.so.8()(64bit) needed by deltarpm-3.6-17.1.fc25.x86_64 - nothing provides librpmio.so.8()(64bit) needed by deltarpm-3.6-17.1.fc25.x86_64 (try to add '--skip-broken' to skip uninstallable packages) Regards, Vít Šesták 'v6ak' On Friday, March 19, 2021 at 11:40:02 AM UTC+1 a...@qubes-os.org wrote: > Dear Qubes Community, > > 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 > 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 > [4] https://www.qubes-os.org/doc/updating-qubes-os/ > > -- > The Qubes Security Team > https://www.qubes-os.org/security/ > > ``` > > This announcement is also available on the Qubes website: > https://www.qubes-os.org/news/2021/03/19/qsb-067/ > > > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/eb9f878f-9dbb-46b1-9c7a-1dfa0adde669n%40googlegroups.com.
