It seems to have been fixed now. The dom0 updates have passed. The DomU Fedora updates have succeeded with updating the macros.qubes file, which is supposingly the workaround by Qubes team.
Regards, Vít Šesták 'v6ak' On Friday, March 19, 2021 at 1:59:48 PM UTC+1 a...@qubes-os.org wrote: > On 3/19/21 4:41 AM, Vít Šesták wrote: > > 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' > > > > Yes, I'm seeing the same thing. I have already notified the team > directly about this. > > > > > 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/ > >> > >> > >> > > > > > -- > Andrew David Wong (Axon) > Community Manager, Qubes OS > https://www.qubes-os.org > > -- 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/72c100a2-a35c-4032-904d-e6d0179d2dc5n%40googlegroups.com.
