Qubes OS📢. Страница 7

QSB-079: Two IOMMU-related Xen issues (XSA-399, XSA-400) www.qubes-os.org/news/20…/qsb-079 We have just published Qubes Security Bulletin (QSB) 079: Two IOMMU-related Xen issues (XSA-399, XSA-400). 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-079 in the qubes-secpack: github.com/QubesOS…2022.txt In addition, you may wish to: Get the qubes-secpack: https://www.qubes-os.org/security/pack/ View all past QSBs: https://www.qubes-os.org/security/qsb/ View the XSA Tracker: https://www.qubes-os.org/security/xsa/ ---===[ Qubes Security Bulletin 079 ]===--- 2022-04-05 Two IOMMU-related Xen issues (XSA-399, XSA-400) User action required --------------------- Users must install the following specific packages in order to address the issues discussed in this bulletin: For Qubes 4.0, in dom0: - Xen packages, version 4.8.5-39 For Qubes 4.1, in dom0: - Xen packages, version 4.14.4-4 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. [1] Once available, the packages are to be installed via the Qubes Update tool or its command-line equivalents. [2] Dom0 must be restarted afterward in order for the updates to take effect. If you use Anti Evil Maid, you will need to reseal your secret passphrase to new PCR values, as PCR18+19 will change due to the new Xen binaries. Summary -------- The following security advisories were published on 2022-04-05: XSA-399 [3] "race in VT-d domain ID cleanup": | Xen domain IDs are up to 15 bits wide. VT-d hardware may allow for only | less than 15 bits to hold a domain ID associating a physical device with | a particular domain. Therefore internally Xen domain IDs are mapped to | the smaller value range. The cleaning up of the housekeeping structures | has a race, allowing for VT-d domain IDs to be leaked and flushes to be | bypassed. XSA-400 [4] "IOMMU: RMRR (VT-d) and unity map (AMD-Vi) handling issues": | Certain PCI devices in a system might be assigned Reserved Memory | Regions (specified via Reserved Memory Region Reporting, "RMRR") for | Intel VT-d or Unity Mapping ranges for AMD-Vi. These are typically used | for platform tasks such as legacy USB emulation. | | Since the precise purpose of these regions is unknown, once a device | associated with such a region is active, the mappings of these regions | need to remain continuouly accessible by the device. This requirement | has been violated. | | Subsequent DMA or interrupts from the device may have unpredictable | behaviour, ranging from IOMMU faults to memory corruption. Impact ------- The precise impact of XSA-399 and XSA-400 is system-specific but would typically be a denial of service (DoS) affecting the entire host. Privilege escalation and information leaks cannot be ruled out. XSA-399 affects only Qubes OS 4.1. Qubes OS 4.0 is not affected due to the version of Xen it uses. This issue affects only qubes with assigned PCI devices, which are sys-net and sys-usb in the default Qubes OS configuration. XSA-400 affects both Qubes OS 4.0 and 4.1. It affects only qubes with assigned PCI devices that have an associated RMRR or unity map. This usually applies to USB controllers, which are assigned to the sys-usb qube in the default Qubes OS configuration. Credits -------- See the original Xen Security Advisory. References ----------- [1] https://www.qubes-os.org/doc/testing/ [2] https://www.qubes-os.org/doc/how-to-update/ [3] https://xenbits.xen.org/xsa/advisory-399.html [4] https://xenbits.xen.org/xsa/advisory-400.html -- The Qubes Security Team https://www.qubes-os.org/security/

XSAs released on 2022-04-05 www.qubes-os.org/news/20…22-04-05 The Xen Project has released one or more Xen Security Advisories (XSAs). The security of Qubes OS is affected. Therefore, user action is required. XSAs that affect the security of Qubes OS (user action required) The following XSAs do affect the security of Qubes OS: XSA-399 XSA-400 Please see QSB-079 for the actions users must take in order to protect themselves, as well as further details about these XSAs: www.qubes-os.org/news/20…/qsb-079 XSAs that do not affect the security of Qubes OS (no user action required) The following XSAs do not affect the security of Qubes OS, and no user action is necessary: XSA-397 (denial of service only) Related links Xen XSA list: https://xenbits.xen.org/xsa/ Qubes XSA tracker: https://www.qubes-os.org/security/xsa/ Qubes security pack (qubes-secpack): https://www.qubes-os.org/security/pack/ Qubes security bulletins (QSBs): https://www.qubes-os.org/security/qsb/

MirageOS Announces Latest Release v4.0, dedicated to Lars Kurth xenproject.org/2022/03…rs-kurth MirageOS core maintainers and the Linux Foundation announced the release of MirageOS version 4.0, the latest update since version 3.10 in December, 2020. SAN FRANCISCO, March 29, 2022 — The MirageOS...

Qubes OS configuration survey! (5-10 minutes) www.qubes-os.org/news/20…n-survey We’re working on a simpler, more user-friendly Qubes OS configuration experience. We invite you all to lend us 5-10 minutes of your time to participate in this 100% anonymous survey. Your participation will help us build better GUI tools for system configuration that meet real user needs. This survey will remain live for 28 days. Thank you! https://survey.qubes-os.org/index.php?r=survey/index&sid=762843&lang=en

Whonix support for Qubes 4.0 extended www.qubes-os.org/news/20…extended The Whonix Project has extended its support for Whonix templates on Qubes 4.0 by an additional month to 2022-04-20. This comes after an initial 16-day extension when the release of Qubes 4.1 was originally announced (www.qubes-os.org/news/20…es-4-1-0). How does Whonix support work? While Qubes OS releases are supported for six months (www.qubes-os.org/doc/sup…releases) following each subsequent major or minor release, Whonix templates have their own support policy (www.qubes-os.org/doc/sup…releases) set by the Whonix Project. This policy requires Whonix template users to stay reasonably close to the cutting edge by upgrading to new stable releases of Qubes OS and Whonix templates within a month of their respective releases. To be precise: One month after a new stable version of Qubes OS is released, Whonix templates are no longer supported on any older release of Qubes OS. This means that users who wish to continue using Whonix templates on Qubes are usually required to upgrade to the latest stable Qubes OS version within one month of its release (unless the deadline is extended, as it has been in this case). One month after new stable versions of Whonix templates are released, older releases of Whonix templates are no longer supported. This means that users who wish to continue using Whonix templates on Qubes are usually required to upgrade to the latest stable Whonix template versions within one month of their release. (This point doesn’t apply to the present situation, since this announcement pertains to a new Qubes OS release, not a new Whonix template release. However, I’m mentioning it here for the sake of completeness, as it’s part of the Whonix support policy.) What does this mean for you? If you haven’t upgraded from Qubes 4.0 to Qubes 4.1 yet, and you use Whonix templates, this extension means you have a bit more time to upgrade before your Whonix templates are no longer supported. You should aim to upgrade to Qubes 4.1 (or discontinue use of Whonix templates) by 2022-04-20. If you’re already on Qubes 4.1 or you don’t use Whonix templates, you’re all set. This announcement doesn’t change anything for you.

On affected systems, an attacker might be able to infer the contents of arbitrary host memory, including memory assigned to other guests. Credits -------- See the original Xen Security Advisory. References ----------- [1] https://www.qubes-os.org/doc/testing/ [2] https://www.qubes-os.org/doc/how-to-update/ [3] https://xenbits.xen.org/xsa/advisory-398.html -- The Qubes Security Team https://www.qubes-os.org/security/

QSB-077: Multiple speculative security issues (XSA-398) www.qubes-os.org/news/20…/qsb-077 We have just published Qubes Security Bulletin (QSB) 077: Multiple speculative security issues (XSA-398). 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-077 in the qubes-secpack: github.com/QubesOS…2022.txt In addition, you may wish to: Get the qubes-secpack: https://www.qubes-os.org/security/pack/ View all past QSBs: https://www.qubes-os.org/security/qsb/ View the XSA Tracker: https://www.qubes-os.org/security/xsa/ ---===[ Qubes Security Bulletin 077 ]===--- 2022-03-09 Multiple speculative security issues (XSA-398) User action required --------------------- Users must install the following specific packages in order to address the issues discussed in this bulletin: For Qubes 4.0, in dom0: - Xen packages, version 4.8.5-38 For Qubes 4.1, in dom0: - Xen packages, version 4.14.4-2 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. [1] Once available, the packages are to be installed via the Qubes Update tool or its command-line equivalents. [2] Dom0 must be restarted afterward in order for the updates to take effect. If you use Anti Evil Maid, you will need to reseal your secret passphrase to new PCR values, as PCR18+19 will change due to the new Xen binaries. Note: As of the publication date of this QSB, the Xen Project's patches for XSA-398 are incomplete. Specifically, they do not protect systems running on CET-capable Intel platforms (11th generation and later). This limitation affects Qubes 4.1 but not Qubes 4.0. In light of this situation, we have decided to push both the complete 4.0 patches and the incomplete 4.1 patches to the security-testing repository immediately. The Xen Project expects to make complete patches available in the near future. We will push the complete 4.1 patches as soon as possible after they become available to us. Summary -------- On 2022-03-08, the Xen Project published XSA-398, "Multiple speculative security issues" [3]: | 1) Researchers at VU Amsterdam have discovered Spectre-BHB, pertaining | to the use of Branch History between privilege levels. | | ARM have assigned CVE-2022-23960. Intel have assigned CVE-2022-0001 | (Branch History Injection) and CVE-2022-0002 (Intra-mode BTI). AMD | have no statement at the time of writing. | | For more details, see: | https://vusec.net/projects/bhi-spectre-bhb | developer.arm.com/support…rability | www.intel.com/content…598.html | | 2) Researchers at Open Source Security, Inc. have discovered that AMD | CPUs may speculate beyond direct branches. | | AMD have assigned CVE-2021-26341. | | For more details, see: | grsecurity.net/amd_bra…e_before | www.amd.com/en/corp…-sb-1026 | | 3) Researchers at Intel have discovered that previous Spectre-v2 | recommendations of using lfence/jmp is incomplete. | | AMD have assigned CVE-2021-26401. | | For more details, see: | www.amd.com/en/corp…-sb-1036 | Impact ------- The Xen Project's summary above enumerates three security issues. The first one, in practice, affects only newer Intel systems (11th generation and later). For other systems, previous mitigations are already sufficient. The second issue does not, in practice, affect any configuration supported by Qubes OS. The third issue affects only AMD systems.

XSAs released on 2022-03-08 www.qubes-os.org/news/20…22-03-08 The Xen Project has released one or more Xen Security Advisories (XSAs). The security of Qubes OS is affected. Therefore, user action is required. XSAs that affect the security of Qubes OS (user action required) The following XSAs do affect the security of Qubes OS: XSA-398 Please see QSB-077 for the actions users must take in order to protect themselves, as well as further details about these XSAs: www.qubes-os.org/news/20…/qsb-077 XSAs that do not affect the security of Qubes OS (no user action required) The following XSAs do not affect the security of Qubes OS, and no user action is necessary: (None) Related links Xen XSA list: https://xenbits.xen.org/xsa/ Qubes XSA tracker: https://www.qubes-os.org/security/xsa/ Qubes security pack (qubes-secpack): https://www.qubes-os.org/security/pack/ Qubes security bulletins (QSBs): https://www.qubes-os.org/security/qsb/

Qubes Canary 030 www.qubes-os.org/news/20…nary-030 We have published Qubes Canary 030. The text of this canary is reproduced below. This canary and its accompanying signatures will always be available in the Qubes security pack (qubes-secpack). View Qubes Canary 030 in the qubes-secpack: github.com/QubesOS…2022.txt Learn how to obtain and authenticate the qubes-secpack and all the signatures it contains: https://www.qubes-os.org/security/pack/ View all past canaries: https://www.qubes-os.org/security/canary/ ---===[ Qubes Canary 030 ]===--- Statements ----------- The Qubes security team members who have digitally signed this file [1] state the following: 1. The date of issue of this canary is March 08, 2022. 2. There have been 76 Qubes security bulletins published so far. 3. The Qubes Master Signing Key fingerprint is: 427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494 4. No warrants have ever been served to us with regard to the Qubes OS Project (e.g. to hand out the private signing keys or to introduce backdoors). 5. We plan to publish the next of these canary statements in the first fourteen days of June 2022. Special note should be taken if no new canary is published by that time or if the list of statements changes without plausible explanation. Special announcements ---------------------- None. Disclaimers and notes ---------------------- We would like to remind you that Qubes OS has been designed under the assumption that all relevant infrastructure is permanently compromised. This means that we assume NO trust in any of the servers or services which host or provide any Qubes-related data, in particular, software updates, source code repositories, and Qubes ISO downloads. This canary scheme is not infallible. Although signing the declaration makes it very difficult for a third party to produce arbitrary declarations, it does not prevent them from using force or other means, like blackmail or compromising the signers' laptops, to coerce us to produce false declarations. The proof of freshness provided below serves to demonstrate that this canary could not have been created prior to the date stated. It shows that a series of canaries was not created in advance. This declaration is merely a best effort and is provided without any guarantee or warranty. It is not legally binding in any way to anybody. None of the signers should be ever held legally responsible for any of the statements made here. Proof of freshness ------------------- Tue, 08 Mar 2022 04:12:58 +0000 Source: DER SPIEGEL - International (https://www.spiegel.de/international/index.rss) Yuval Noah Harari on the Ukraine War: "Human Stupidity Should Never Be Underestimated" Josep Borrell on Russia's war in Ukraine and what Europe needs to do about it Ukraine: Kyiv Residents Prepare for the Arrival of the Russians Russia-Ukraine-War: How Vladimir Putin Brought the West Together The Ukrainian Heartland Prepares for War: "I'm Not Leaving My Home!" Source: NYT > World News (rss.nytimes.com/service…orld.xml) Ukraine Live Updates: Third Round of Talks Raise Hopes for Evacuation Routes With New Limits on Media, Putin Closes a Door on Russia’s ‘Openness’ Once Victims in Southeast Europe, Jews Come to Aid Fleeing Ukrainians Baltics, in Russia's Shadow, Demand Tougher Stance From West These Syrian Refugees Can't Stay in Denmark, but They Can't Go Home Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml) War in Ukraine: Russia says it may cut gas supplies if oil ban goes ahead War in Ukraine: Crisis is unleashing 'hell on earth' for food prices War in Ukraine: World Bank approves $723m financial package War in Ukraine: 'It's hell, it's really hell' - Families flee bombs in Irpin Ukraine war: Chernobyl workers' 12-day ordeal under Russian guard Source: Blockchain.info

00000000000000000003c2fb54d0cb10b7730ca540bcd201beabacce179976cd Footnotes ---------- [1] This file should be signed in two ways: (1) via detached PGP signatures by each of the signers, distributed together with this canary in the qubes-secpack.git repo, and (2) via digital signatures on the corresponding qubes-secpack.git repo tags. [2] [2] Don't just trust the contents of this file blindly! Verify the digital signatures! Instructions for doing so are documented here: https://www.qubes-os.org/security/pack/ -- The Qubes Security Team https://www.qubes-os.org/security/

QSB-076: Intel microcode updates www.qubes-os.org/news/20…/qsb-076 We have just published Qubes Security Bulletin (QSB) 076: Intel microcode updates. 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-076 in the qubes-secpack: github.com/QubesOS…2022.txt In addition, you may wish to: Get the qubes-secpack: https://www.qubes-os.org/security/pack/ View all past QSBs: https://www.qubes-os.org/security/qsb/ View the XSA Tracker: https://www.qubes-os.org/security/xsa/ ---===[ Qubes Security Bulletin 076 ]===--- 2022-02-11 Intel microcode updates User action required --------------------- Users must install the following specific packages in order to address the issues discussed in this bulletin: For Qubes 4.0, in dom0: - microcode_ctl package, version 2.1-34.qubes1 For Qubes 4.1, in dom0: - microcode_ctl package, version 2.1-34.qubes1 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. [1] Once available, the packages are to be installed via the Qubes Update tool or its command-line equivalents. [2] Dom0 must be restarted afterward in order for the updates to take effect. If you use Anti Evil Maid, you will need to reseal your secret passphrase to new PCR values, as PCR19 will change due to the new microcode in the initramfs. Summary -------- On 2022-02-08, Intel published microcode updates [3] for some of their CPUs that fix security issues [4]. INTEL-SA-00561 (CVE-2021-0145) [7][8] affects Qubes installations on hardware with affected CPU models. Red Hat provides a good overview [5]: | A flaw was found in microcode. Fast store forwarding prediction in one | domain could be controlled by software previously executed in another | domain. Such control helps a malicious program running in user mode | (or guest VM) to trigger transient execution gadgets in supervisor | mode (or VMM), potentially leading to sensitive data disclosure. There is also a separate vulnerability -- INTEL-SA-00589 (CVE-2021-33120) [9] -- that seems to affect mainly low-power architecture CPUs, e.g., Atom. However, due to the sparse description of the issue, we cannot judge whether it affects Qubes OS. Impact ------- INTEL-SA-00561 (CVE-2021-0145) is another CPU vulnerability related to speculative execution (also called transient execution). If successfully exploited, it could allow an attacker to read information across security boundaries. In this case, the successful exploitation could allow an attacker-controlled VM to read information that should be accessible only to the hypervisor. This affects at least 10th generation mobile and 11th generation mobile and desktop Intel Core CPUs. For a full list of affected CPU models, see Intel's table [6] or Red Hat's summary [5]. Credits -------- See the original security advisories. Additional thanks to Red Hat for their helpful overview of the microcode updates. References ----------- [1] https://www.qubes-os.org/doc/testing/ [2] https://www.qubes-os.org/doc/how-to-update/ [3] github.com/intel/I…enote.md [4] www.intel.com/content…ult.html [5] https://access.redhat.com/articles/6716541 [6] www.intel.com/content…del.html [7] www.intel.com/content…561.html [8] www.intel.com/content…tor.html

[9] www.intel.com/content…589.html -- The Qubes Security Team https://www.qubes-os.org/security/

Thank you to our partners, donors, contributors, and testers! This release would not be possible without generous support from our partners (https://www.qubes-os.org/partners/) and donors (https://www.qubes-os.org/donate/), as well as contributions (https://www.qubes-os.org/doc/contributing/) from our active community members, especially bug reports (https://www.qubes-os.org/doc/issue-tracking/) from our testers (https://www.qubes-os.org/doc/testing/). We are eternally grateful to our excellent community for making the Qubes OS Project a great example of open-source collaboration. Release notes The following list is also available on the Qubes OS 4.1 release notes (www.qubes-os.org/doc/rel…se-notes) page. Optional qubes-remote-support package now available from repositories (strictly opt-in, no package installed by default; no new ports or network connections open by default; requires explicit connection initiation by the user, then requires sharing a code word with the remote party before a connection can be established; see #6364 (github.com/QubesOS…ues/6364) for more information) Qubes firewall reworked to be more defensive (see #5540 (github.com/QubesOS…ues/5540) for details) Xen upgraded to version 4.14 Dom0 operating system upgraded to Fedora 32 Default desktop environment upgraded to Xfce 4.14 Upgraded default template releases Experimental support for GUI running outside of dom0 (hybrid mode GUI domain without real GPU passthrough; see #5662 (github.com/QubesOS…ues/5662) for details) Experimental support for audio server running outside of dom0 (“Audio domain”) sys-firewall and sys-usb are now disposables by default UEFI boot now loads GRUB, which in turn loads Xen, making the boot path similar to legacy boot and allowing the user to modify boot parameters or choose an alternate boot menu entry New qrexec policy format (see #4370 (github.com/QubesOS…ues/4370) for details) qrexec protocol improvements (see #4909 (github.com/QubesOS…ues/4909) for details) New qrexec-policy daemon Simplified using in-qube kernels Windows USB and audio support courtesy of tabit-pro (https://github.com/tabit-pro) (see #5802 (github.com/QubesOS…ues/5802) and #2624 (github.com/QubesOS…ues/2624)) Clarified disposable-related terminology and properties Default kernelopts can now be specified by a kernel package Improved support for high-resolution displays Improved notifications when a system drive runs out of free space Support for different cursor shapes “Paranoid mode” backup restore option now properly supported using disposables Users can now choose between Debian and Fedora in the installer Certain files and applications are now opened in disposables, e.g., Thunderbird email attachments New graphical interface for managing testing repository updates New “Cute Qube” icon family (replaces padlock icons) Disposable qube types now use the disposable icon New Template Manager tool for installing, removing, and updating templates (meanwhile, the tool previously known as the “Template Manager,” which was for mass template switching, has been integrated into the Qube Manager) The “file” storage driver has been deprecated in Qubes 4.1 and will be removed in Qubes 4.2 property-del event renamed to property-reset to avoid confusion qrexec no longer supports non-executable files in /etc/qubes-rpc qrexec components have been reorganized into the core-qrexec repository The qvm-pool argument parser has been rewritten and improved Removed the need for the out-of-tree u2mfn kernel module Qrexec services can now run as a socket server Improved template distribution mechanism Now possible to restart qrexec-agent The term “VM” has largely been replaced by “qube”

GUI daemon is now configured using qvm-features tool, /etc/qubes/guid.conf file is no longer used qvm-run tool got --no-shell option to run a single command without using a shell inside the qube For a full list, including more detailed descriptions, please see here (github.com/QubesOS…s/issues).

Qubes OS 4.1.0 has been released! www.qubes-os.org/news/20…es-4-1-0 At long last, the Qubes 4.1.0 stable release has arrived! The culmination of years of development, this release brings a host of new features, major improvements, and numerous bug fixes. Read on to find out what’s new, how to install or upgrade to the new release, and all the noteworthy changes it includes. What’s new in Qubes 4.1.0? In case you still haven’t heard, Qubes 4.1.0 includes several major new features, each of which is explained in depth in its own article. Qubes Architecture Next Steps: The GUI Domain (www.qubes-os.org/news/20…i-domain) The GUI domain is a qube separate from dom0 that handles all display-related tasks and some system management. This separation allows us to more securely isolate dom0 while granting the user more flexibility with respect to graphical interfaces. (Note: The GUI domain is still experimental, so it’s an opt-in feature in Qubes 4.1.0 (www.qubes-os.org/news/20…i-domain).) Qubes Architecture Next Steps: The New Qrexec Policy System (www.qubes-os.org/news/20…y-system) Qrexec is is an RPC (remote procedure call) mechanism that allows one qube to do something inside another qube. The qrexec policy system enforces “who can do what and where.” Qubes 4.1 brings a new qrexec policy format, significant performance improvements, support for socket services, and policy notifications that make it easier to detect problems. New Gentoo templates and maintenance infrastructure (www.qubes-os.org/news/20…tructure) There are three new flavors of Gentoo templates, as well as an advanced infrastructure for automated building and testing, which also supports Linux kernel and Arch Linux building and testing. Improvements in testing and building: GitLab CI and reproducible builds (www.qubes-os.org/news/20…building) This article explains our work on continuous integration (CI), which automates and improves several aspects of the development process, and reproducible builds, which improves the security of the build and verification process. Reproducible builds for Debian: a big step forward (www.qubes-os.org/news/20…-forward) This article explains the tools and infrastructure we’ve built to verify official package builds by rebuilding them. While this was supposed to be possible in theory, making it a reality required significant work, including rewriting certain components from scratch. More improvements, bug fixes, and updated components In addition to the articles above, there are also numerous other improvements and bug fixes listed in the release notes (https://www.qubes-os.org/#release-notes) and in the issue tracker (github.com/QubesOS…s/issues). Finally, Qubes 4.1.0 features the following updated default components: Xen 4.14 Fedora 32 in dom0 Fedora 34 template Debian 11 template Whonix 16 Gateway and Workstation templates Linux kernel 5.10 How to install or upgrade to Qubes 4.1.0 To perform a fresh install, download (https://www.qubes-os.org/downloads/) Qubes 4.1.0, then follow the installation guide (https://www.qubes-os.org/doc/installation-guide/). If you’re currently on Qubes 4.0, please see how to upgrade to Qubes 4.1 (https://www.qubes-os.org/doc/upgrade/4.1/). If you’re already on any 4.1.0 release candidate, simply perform a normal update (https://www.qubes-os.org/doc/how-to-update/).

QSB-075: Insufficient cleanup of passed-through device IRQs (XSA-395) www.qubes-os.org/news/20…/qsb-075 We have just published Qubes Security Bulletin (QSB) 075: Insufficient cleanup of passed-through device IRQs (XSA-395). 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-075 in the qubes-secpack: github.com/QubesOS…2022.txt In addition, you may wish to: Get the qubes-secpack: https://www.qubes-os.org/security/pack/ View all past QSBs: https://www.qubes-os.org/security/qsb/ View the XSA Tracker: https://www.qubes-os.org/security/xsa/ ---===[ Qubes Security Bulletin 075 ]===--- 2022-01-25 Insufficient cleanup of passed-through device IRQs (XSA-395) User action required --------------------- Users must install the following specific packages in order to address the issues discussed in this bulletin: For Qubes 4.0, in dom0: - Xen packages, version 4.8.5-37 For Qubes 4.1, in dom0: - Xen packages, version 4.14.3-8 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. [1] Once available, the packages are to be installed via the Qubes Update tool or its command-line equivalents. [2] Dom0 must be restarted afterward in order for the updates to take effect. If you use Anti Evil Maid, you will need to reseal your secret passphrase to new PCR values, as PCR18+19 will change due to the new Xen binaries. Summary -------- On 2022-01-25, the Xen project published XSA-395, "Insufficient cleanup of passed-through device IRQs" [3]: | The management of IRQs associated with physical devices exposed to x86 | HVM guests involves an iterative operation in particular when cleaning | up after the guest's use of the device. In the case where an | interrupt is not quiescent yet at the time this cleanup gets invoked, | the cleanup attempt may be scheduled to be retried. When multiple | interrupts are involved, this scheduling of a retry may get | erroneously skipped. At the same time pointers may get cleared | (resulting in a de-reference of NULL) and freed (resulting in a | use-after-free), while other code would continue to assume them to be | valid. Impact ------- The precise impact is system-specific but would typically be a denial of service (DoS) affecting the entire host. Privilege escalation and information leaks cannot be ruled out. Only x86 HVM guests with one or more passed-through physical devices using multiple physical interrupts together can exploit this vulnerability. In Qubes, this generally applies to sys-usb and sys-net, but whether the relevant devices use multiple interrupts together is system-specific. Credits -------- See the original Xen Security Advisory. References ----------- [1] https://www.qubes-os.org/doc/testing/ [2] https://www.qubes-os.org/doc/how-to-update/ [3] https://xenbits.xen.org/xsa/advisory-395.html -- The Qubes Security Team https://www.qubes-os.org/security/

XSAs released on 2022-01-25 www.qubes-os.org/news/20…22-01-25 The Xen Project has released one or more Xen Security Advisories (XSAs). The security of Qubes OS is affected. Therefore, user action is required. XSAs that affect the security of Qubes OS (user action required) The following XSAs do affect the security of Qubes OS: XSA-395 Please see QSB-075 for the actions users must take in order to protect themselves, as well as further details about these XSAs: www.qubes-os.org/news/20…/qsb-075 XSAs that do not affect the security of Qubes OS (no user action required) The following XSAs do not affect the security of Qubes OS, and no user action is necessary: XSA-393 (ARM architectures only) XSA-394 (denial-of-service only) Related links Xen XSA list: https://xenbits.xen.org/xsa/ Qubes XSA tracker: https://www.qubes-os.org/security/xsa/ Qubes security pack (qubes-secpack): https://www.qubes-os.org/security/pack/ Qubes security bulletins (QSBs): https://www.qubes-os.org/security/qsb/

Qubes OS 4.1.0-rc4 has been released! www.qubes-os.org/news/20…-1-0-rc4 The fourth release candidate for Qubes 4.1.0 is here! There are no major changes to report. We’ve just focused on fixing bugs that were discovered and reported in the third release candidate. If you’re currently using any Qubes 4.1.0 release candidate, a regular update (https://www.qubes-os.org/doc/how-to-update/) is sufficient to upgrade to the latest one. Otherwise, read on for more about how to get started with testing Qubes 4.1.0-rc4. What’s new in Qubes 4.1.0? In case you still haven’t heard, Qubes 4.1.0 includes several major new features, each of which is explained in depth in its own article: Qubes Architecture Next Steps: The GUI Domain (www.qubes-os.org/news/20…i-domain) Qubes Architecture Next Steps: The New Qrexec Policy System (www.qubes-os.org/news/20…y-system) New Gentoo templates and maintenance infrastructure (www.qubes-os.org/news/20…tructure) Reproducible builds for Debian: a big step forward (www.qubes-os.org/news/20…-forward) There are also numerous other improvements and bug fixes listed in the release notes (www.qubes-os.org/doc/rel…se-notes) and in the issue tracker (github.com/QubesOS…s/issues). Finally, Qubes 4.1.0 features the following updated default components: Xen 4.14 Fedora 32 in dom0 Fedora 34 template Debian 11 template Whonix 16 Gateway and Workstation templates Linux kernel 5.10 How to test Qubes 4.1.0-rc4 If you’re willing to test (https://www.qubes-os.org/doc/testing/) this release candidate, you can help to improve the stable release by reporting any bugs you encounter (https://www.qubes-os.org/doc/issue-tracking/). Experienced users are strongly encouraged to join the testing team (forum.qubes-os.org/t/joini…eam/5190)! How to migrate to 4.1.0-rc4: If you’re already on any 4.1.0 release candidate, simply perform a normal update (https://www.qubes-os.org/doc/how-to-update/). If you’re not on a 4.1.0 release candidate yet, you have two options: Back up (www.qubes-os.org/doc/how…-migrate) your current installation, download (https://www.qubes-os.org/downloads/) 4.1.0-rc4, perform a fresh install (https://www.qubes-os.org/doc/installation-guide/), then restore (www.qubes-os.org/doc/how…-migrate) from your backup. Perform an in-place upgrade (https://www.qubes-os.org/doc/upgrade/4.1/). Release candidate planning With each new release candidate, Qubes 4.1.0 becomes more stable as testers report bugs and our developers fix them. As explained in our general release schedule (www.qubes-os.org/doc/ver…n-scheme), this cycle will continue until no major bugs are discovered, at which point the last release candidate will be declared the stable 4.1.0 release. Until then, we plan to have new release candidates approximately every five weeks.