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

This time, the 3mdeb’s stage belonged to Piotr Król (CEO of 3mdeb) who presented his adventures using Qubes OS as an everyday device, talking about USB camera and cryptocurrency wallets. Of course firmware-related topics could not be missing and Piotr also showed continuation of his previous year’s efforts of securing the VMs with SRTM and Secure Boot. The future of Qubes OS Summits Finally, the time has come when we may meet together in person, after three years! The Qubes OS Summit 2022 is fast approaching, with only a few days left before the start of the event in Berlin. As it is no longer held only virtually (but still possible to attend remotely for those who can’t be with us in person) the organization is more complicated, both from the logistics and presentations side. Every year we try our best to dig into hardcore security topics on the verge of firmware and operating systems. All this time we have been gradually building plans and ideas, and getting closer and closer to the goal of improving the security of Qubes OS, especially in areas we feel best at, i.e. SRTM and DRTM (AEM). In the upcoming event, we have prepared a few interesting projects and ideas around Anti Evil Maid support and open-source firmware on modern hardware. Here (cfp.3mdeb.com/qubes-o…schedule) you may find the full schedule. Among others we welcome the following speakers: Wessel Klein Snakenborg from Novacustom with a story of open-source on modern laptops as a candidate to Qubes OS certification Brent Cowing from Protectli talking about security of his small form factor computers also running open-source firmware Jan Suhr from Nitrokey talking about how enterprise requirements tied to Windows can be met with Qubes OS Arthur Rasmusson from Arc Compute talking about GPU virtualization and its possible benefits to Qubes oS Puck Meerburg from Spectrum OS telling about the power of Wayland for GUI isolation and how it benefits systems like Qubes OS or Spectrum OS And everyone from 3mdeb, Qubes OS team, and others We hope that the event and community around it and the Qubes OS project will grow in the future, bringing reasonable trustworthiness and collaboration for everybody. Definitely, 3mdeb will try its best to co-organize the event in the upcoming years. Summary By a mere coincidence, meeting Marek Marczykowski-Górecki gave birth to a fascinating series of Qubes OS Summits and led us to this day. Together with Invisible Things Lab we (3mdeb) are very proud to be the co-organizers of the 4th edition of the event. Looking forward to seeing each other again, but most important to talk and share knowledge and passion with everyone again after a long time. Many thanks to the Qubes OS team for holding up the tradition with us. See you all in Berlin!

----------- [1] https://www.qubes-os.org/doc/testing/ [2] https://www.qubes-os.org/doc/how-to-update/ [3] https://www.qubes-os.org/doc/split-gpg/ -- The Qubes Security Team https://www.qubes-os.org/security/

QSB-084: Split GPG: GnuPG file descriptor confusion and file existence leak www.qubes-os.org/news/20…/qsb-084 We have just published Qubes Security Bulletin (QSB) 084: Split GPG: GnuPG file descriptor confusion and file existence leak (github.com/QubesOS…2022.txt). 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) (https://www.qubes-os.org/security/pack/). More information about QSBs, including a complete historical list, is available here (https://www.qubes-os.org/security/qsb/). ---===[ Qubes Security Bulletin 084 ]===--- 2022-08-06 Split GPG: GnuPG file descriptor confusion and file existence leak User action required --------------------- Users must install the following specific packages in order to address the issues discussed in this bulletin: For Qubes 4.1, in templates and standalones: - qubes-gpg-split 2.0.63 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] Summary -------- Split GPG [3] is designed to isolate private keys from the application using them in order to protect them from being extracted and to allow the user to retain control over when they are used. This isolation is implemented by forwarding calls from an application in a frontend qube, where `qubes-gpg-client` is executed, to an instance of `gpg` in a backend qube that holds the private keys, all while allowing only specific `gpg` options. This option filtering mechanism is designed to reject options like `--export-secret-keys` that might leak private keys to the frontend qube. However, it has been discovered that certain combinations of options allow the frontend qube to access data in the backend qube in unintended ways. Two separate types of attack were discovered: 1. Interaction via `--command-fd` allows the frontend qube to check for the existence of arbitrary files in the backend qube, including files unrelated to GnuPG. 2. Using the same `--*-fd` option several times allows the frontend qube to redirect GnuPG input and output to the wrong file descriptor. This can be used to: - Corrupt files used by GnuPG. (We have confirmed this only in the case of `trustdb`, but other files cannot be ruled out.) - Issue arbitrary commands to `gpg-agent`, which can be used to perform actions like generating new secret keys and deleting existing keys. - Set various environment variables for the `pinentry` process, thereby providing an indirect avenue of attack against this process. However, our testing did not reveal any way to exploit this vulnerability in order to read `gpg-agent`'s responses, which means that certain actions, such as extracting secret keys, should not be possible. Impact ------- An attacker controlling a Split GPG frontend qube can check for the existence of arbitrary files in a backend qube, corrupt the `trustdb` file in a backend qube, issue arbitrary commands to `gpg-agent` in a backend qube, and issue arbitrary commands to a smart card daemon in a backend qube. While this vulnerability can be exploited in order to generate and delete keys in the backend qube (or on a smart card attached to the backend qube), it is unlikely that it can be used to exfiltrate private keys out of the backend qube (or off of a smart card attached to the backend qube). If this vulnerability were to be chained with a hypothetical vulnerability in `gpg-agent`, `scdaemon`, or `pinentry` (or in one of the libraries they use), then arbitrary code execution could be possible. Credits -------- This issue was discovered by Demi Marie Obenour. References

Qubes OS 4.0 has reached EOL www.qubes-os.org/news/20…ched-eol As previously announced (www.qubes-os.org/news/20…22-08-04), all releases in the Qubes 4.0 series (which includes the most recent 4.0.4 patch release) have officially reached EOL (end-of-life) as of today, 2022-08-04. We strongly urge all remaining Qubes 4.0 users to upgrade to Qubes 4.1 (https://www.qubes-os.org/doc/upgrade/4.1/) immediately. As always, the support statuses of all Qubes OS and template releases are available on the supported releases (https://www.qubes-os.org/doc/supported-releases/) page, and the latest release is available to download on the downloads (https://www.qubes-os.org/downloads/) page. What should I do? If you’re already using Qubes 4.1, then no action is required on your part. This announcement concerns only the 4.0 minor release series. If you’re still using Qubes 4.0 (including the most recent 4.0.4 patch release), then you should upgrade to 4.1 immediately. You have two options: Perform a clean reinstallation using the latest stable Qubes 4.1.1 ISO (www.qubes-os.org/downloa…ownloads), which was published on 2022-07-18 (www.qubes-os.org/news/20…es-4-1-1). Perform an in-place upgrade (www.qubes-os.org/doc/upg…rade/4.1) to 4.1. Both of these options are covered in further detail in the Qubes 4.0 to 4.1 upgrade guide (https://www.qubes-os.org/doc/upgrade/4.1/). If you need help, please consult our help and support (https://www.qubes-os.org/support/) page.

Qubes OS Summit 2022: September 9-11 in Berlin www.qubes-os.org/news/20…mit-2022 In conjunction with 3mdeb (https://3mdeb.com/), the fourth edition of our Qubes OS Summit will be held live this year from September 9 to 11 in Berlin, Germany! For more information about this event, including the CFP (which is open until August 29), please see: https://qubesos.3mdeb.com (https://qubesos.3mdeb.com/)

XSAs released on 2022-07-26 www.qubes-os.org/news/20…22-07-26 The Xen Project has released one or more Xen Security Advisories (XSAs). The security of Qubes OS is not affected. Therefore, no 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: (none) 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-408 (shadow mode is disabled at build time) 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.1 has been released! www.qubes-os.org/news/20…es-4-1-1 We’re pleased to announce the stable release of Qubes 4.1.1! This release aims to consolidate all the security patches, bug fixes, and upstream template OS upgrades that have occurred since the initial Qubes 4.1.0 release in February. Our goal is to provide a secure and convenient way for users to install (or reinstall) the latest stable Qubes release with an up-to-date ISO. Qubes 4.1.1 is available on the downloads (https://www.qubes-os.org/downloads/) page. Reminder: Qubes 4.0 approaching end-of-life As we recently announced (www.qubes-os.org/news/20…22-08-04), Qubes 4.0 reaches EOL (end-of-life) on 2022-08-04. If you’re using Qubes 4.0 and have been waiting for an opportunity to upgrade to Qubes 4.1 via the clean reinstallation (www.qubes-os.org/doc/upg…rade/4.1) method, we strongly recommend using this Qubes 4.1.1 release to do so, as this is the last Qubes 4.1 patch release before Qubes 4.0 reaches EOL. Existing Qubes 4.1.0 and release candidate users If you are already using Qubes 4.1.0 or Qubes 4.1.1-rc1 (www.qubes-os.org/news/20…-1-1-rc1), then you should simply update normally (https://www.qubes-os.org/doc/how-to-update/) (which includes upgrading any EOL templates (www.qubes-os.org/doc/how…o-update) you might have) in order to make your system essentially equivalent to this stable Qubes 4.1.1 release. No special action is required on your part. What’s new in Qubes 4.1.1? Qubes 4.1.1 includes numerous updates over the initial 4.1.0 release, in particular: All 4.1.0 dom0 updates to date Fedora 36 template (upgraded from Fedora 34) Linux kernel 5.15 (upgraded from 5.10) What is a patch release? The Qubes OS Project uses the semantic versioning (https://semver.org/) standard. Version numbers are written as ... Hence, we refer to releases that increment the third number as “patch releases.” A patch release does not designate a separate, new major or minor release of Qubes OS. Rather, it designates its respective major or minor release (in this case, 4.1.0) inclusive of all updates up to a certain point. Installing Qubes 4.1.0 and fully updating it results in essentially the same system as installing Qubes 4.1.1. You can learn more about how Qubes release versioning works in the version scheme (https://www.qubes-os.org/doc/version-scheme/) documentation.

[2] https://www.qubes-os.org/doc/how-to-update/ [3] https://xenbits.xen.org/xsa/advisory-407.html [4] Unlike other 5xxxU models, Ryzen 3 5300U, Ryzen 5 5500U and Ryzen 7 5700U are Zen 2, not Zen 3. See https://en.wikipedia.org/wiki/Zen2 https://en.wikipedia.org/wiki/Zen3 -- The Qubes Security Team https://www.qubes-os.org/security/

QSB-083: Retbleed: Arbitrary speculative code execution with return instructions (XSA-407) www.qubes-os.org/news/20…/qsb-083 We have just published Qubes Security Bulletin (QSB) 083: Retbleed: Arbitrary speculative code execution with return instructions (XSA-407). 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-083 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 083 ]===--- 2022-07-12 Retbleed Arbitrary speculative code execution with return instructions (XSA-407) 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-43 For Qubes 4.1, in dom0: - Xen packages, version 4.14.5-6 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-07-12, the Xen Project published XSA-407, "Retbleed - arbitrary speculative code execution with return instructions" [3]: | Researchers at ETH Zurich have discovered Retbleed, allowing for | arbitrary speculative execution in a victim context. | | For more details, see: | https://comsec.ethz.ch/retbleed | | ETH Zurich have allocated CVE-2022-29900 for AMD and CVE-2022-29901 for | Intel. | | Despite the similar preconditions, these are very different | microarchitectural behaviours between vendors. | | On AMD CPUs, Retbleed is one specific instance of a more general | microarchitectural behaviour called Branch Type Confusion. AMD have | assigned CVE-2022-23816 (Retbleed) and CVE-2022-23825 (Branch Type | Confusion). | | For more details, see: | www.amd.com/en/corp…-sb-1037 | | On Intel CPUs, Retbleed is not a new vulnerability; it is only | applicable to software which did not follow Intel's original | Spectre-v2 guidance. Intel are using the ETH Zurich allocated | CVE-2022-29901. | | For more details, see: | www.intel.com/content…702.html | www.intel.com/content…low.html | | ARM have indicated existing guidance on Spectre-v2 is sufficient. Impact ------- This is yet another speculative execution issue, which allows an attacker to infer content of memory they shouldn't have access to. This includes one VM extracting secrets from another. Any VM can perform this attack on an affected hardware. AMD systems based on Zen 1 - Zen 2 microarchitectures are affected. Specifically those are AMD Ryzen processors with model names 1xxx - 4xxx and some 5xxxU [4]. Zen 3 microarchitecture (AMD Ryzen 5xxx or newer) are not affected. Pre-existing Xen mitigations on Intel machines are effective to prevent this issue, so Intel systems are not affected. Credits -------- See the original Xen Security Advisory. References ----------- [1] https://www.qubes-os.org/doc/testing/

XSAs released on 2022-07-12 www.qubes-os.org/news/20…22-07-12 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-407 Please see QSB-083 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-083 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/

QSB-082: Memory management issues in PV frontend drivers www.qubes-os.org/news/20…/qsb-082 We have just published Qubes Security Bulletin (QSB) 082: Memory management issues in PV frontend drivers. 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-082 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 082 ]===--- 2022-07-05 Memory management issues in PV frontend drivers 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-42 - Linux kernel packages (kernel*-qubes-vm), versions 5.4.203, 5.8.9, 4.19.250 For Qubes 4.1, in dom0: - Xen packages, version 4.14.5-5 - Linux kernel packages (kernel*-qubes-vm), versions 5.15.52, 5.8.9, 5.10.128 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 and Linux binaries. Summary -------- The following security advisories were published on 2022-07-05: XSA-403 [3] "Linux disk/nic frontends data leaks": | Linux Block and Network PV device frontends don't zero memory regions | before sharing them with the backend. Additionally the granularity of | the grant table doesn't allow sharing less than a 4K page, leading to | unrelated data residing in the same 4K page as data shared with a | backend being accessible by such backend. | | An untrusted backend can access data not intended to be shared. If | such mappings are made with write permissions the backend could also | cause malfunctions and/or crashes to consumers of contiguous data in | the shared pages. XSA-405 [4] "The PV network backend may cause Linux netfront to use freed SKBs": | While adding logic to support XDP (eXpress Data Path), a code label | was moved in a way allowing for SKBs having references (pointers) | retained for further processing to nevertheless be freed. | | A misbehaving or malicious backend may cause a Denial of Service (DoS) | in the guest. Information leaks or privilege escalation cannot be | ruled out. Impact ------- These vulnerabilities, if exploited, could allow a malicious VM that serves as a network or a block backend to leak data from its frontend. The ability to execute code in the frontend cannot be ruled out. In the default Qubes OS configuration, this means that sys-net could attack sys-firewall, and sys-firewall could attack qubes connected to it. Furthermore, a qube to which a block device is assigned from an untrusted backend qube can be attacked by that backend. (For example, sys-usb could attack qubes to which a USB drive is attached as a block device.) Qubes that do not have any NetVM set and to which no block devices are assigned are not affected. 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-403.html [4] https://xenbits.xen.org/xsa/advisory-405.html -- The Qubes Security Team https://www.qubes-os.org/security/

XSAs released on 2022-07-05 www.qubes-os.org/news/20…22-07-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-403 XSA-405 Please see QSB-082 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-082 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-406 (ARM architecture 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.0 reaches EOL on 2022-08-04 www.qubes-os.org/news/20…22-08-04 Qubes OS 4.0 is scheduled to reach end-of-life (EOL) on 2022-08-04 — one month from the date of this announcement. What about patch releases? The Qubes OS Project uses the semantic versioning (https://semver.org/) standard. Version numbers are written as ... When a major or minor release reaches EOL, all of its patch releases also reach EOL. For example, in this case, when we say that “Qubes 4.0” (without specifying a number) is approaching EOL, we’re specifying a particular minor release, inclusive of all patch releases within it. This means that Qubes 4.0.0, 4.0.1, 4.0.2, 4.0.3, and 4.0.4 will all reach EOL at the same time (on 2022-08-04), since they are all just patch releases of the same minor release. How are EOL dates determined? According to our support policy (https://www.qubes-os.org/doc/supported-releases/), stable Qubes OS releases are supported for six months after each subsequent major or minor release (https://www.qubes-os.org/doc/version-scheme/). This means that Qubes 4.0 reaches EOL six months after Qubes 4.1 was released. Since Qubes 4.1.0 was released on 2022-02-04 (www.qubes-os.org/news/20…es-4-1-0), Qubes 4.0’s EOL date is six months later, on 2022-08-04. Fun fact: Qubes 4.0.0 was initially released on 2018-03-28 (www.qubes-os.org/news/20…qubes-40), which means that it will be four years, four months, and one week old when it reaches EOL. That’s the longest support period for a stable Qubes release in our project’s history! What should I do? First off, if you’re already using Qubes 4.1, then you don’t have to do anything. This announcement doesn’t affect you. However, if you’ve stood by the venerable Qubes 4.0 till now, then you’ll want to make sure you upgrade to Qubes 4.1 by 2022-08-04. When you upgrade, though, depends on a few factors. You have several options (in no particular order): Perform an in-place upgrade (www.qubes-os.org/doc/upg…rade/4.1) any time between now and 2022-08-04. Perform a clean install now using the stable Qubes 4.1.0 ISO (www.qubes-os.org/downloa…ownloads), which was published on 2022-02-04 (www.qubes-os.org/news/20…es-4-1-0). Perform a clean install now using the first release candidate for Qubes 4.1.1 (www.qubes-os.org/news/20…-1-1-rc1). Wait to see whether the stable Qubes 4.1.1 ISO is published within the next month. Allow me to explain what I mean by the last option: While we certainly hope to be able to announce the stable 4.1.1 release within the next few weeks, we cannot guarantee that outcome. After all, the entire point of having release candidates is because sometimes major bugs are discovered in builds that were thought to be nearly ready for release. While we don’t expect any, we can never be certain that no such bug will be found. So, for those looking for a clean installation option, the main advantage of the existing 4.1.0 ISO is that it is already available right now, while there’s a decent chance but no guarantee that the stable 4.1.1 ISO will be ready in time. Meanwhile, the release candidate is intended for testers and adventurous types who don’t mind a bit of risk. The release candidates are not intended for cases in which system reliability is required for important work. The main disadvantage of the existing 4.1.0 ISO is that it’s quite old by now. It’s missing some security updates (which you should download immediately after installing, if you choose to go that route) and comes with an old Fedora template that has already reached EOL (which you should upgrade immediately after installing or refrain from using in favor of other templates). If you’re not in any particular hurry to upgrade (and, if you’ve been content

to stick with 4.0 until now, then you’re probably not), one strategy is simply to wait until closer to the EOL date, and see whether the stable 4.1.1 ISO arrives in time. If it does, great! You can preform a clean install using that. If it doesn’t, then you haven’t lost anything. You still have the same choices you have right now. Just make sure you to leave yourself enough time to upgrade one way or another!

Qubes OS 4.1.1-rc1 has been released! www.qubes-os.org/news/20…-1-1-rc1 We’re pleased to announce the first release candidate for Qubes 4.1.1! This release aims to consolidate all the security patches, bug fixes, and upstream template OS upgrades that have occurred since the initial Qubes 4.1.0 release in February. Our goal is to provide a secure and convenient way for users to install (or reinstall) the latest stable Qubes release with an up-to-date ISO. Qubes 4.1.1-rc1 is available on the downloads (https://www.qubes-os.org/downloads/) page. What is a release candidate? A release candidate (RC) is a software build that has the potential to become a stable release, unless significant bugs are discovered in testing. Release candidates are intended for more advanced (or adventurous!) users who are comfortable testing early versions of software that are potentially buggier than stable releases. You can read more about the Qubes OS release process in the version scheme (https://www.qubes-os.org/doc/version-scheme/) documentation. What is a patch release? The Qubes OS Project uses the semantic versioning (https://semver.org/) standard. Version numbers are written as ... Hence, we refer to releases that increment the third number as “patch releases.” A patch release does not designate a separate, new major or minor release of Qubes OS. Rather, it designates its respective major or minor release (in this case, 4.1.0) inclusive of all updates up to a certain point. Installing Qubes 4.1.0 and fully updating it results in essentially the same system as installing Qubes 4.1.1. You can learn more about how Qubes release versioning works in the version scheme (https://www.qubes-os.org/doc/version-scheme/) documentation. What’s new in Qubes 4.1.1? Qubes 4.1.1-rc1 includes numerous updates over the initial 4.1.0 release, in particular: All 4.1.0 dom0 updates to date Fedora 36 template (upgraded from Fedora 34) Linux kernel 5.15 (upgraded from 5.10) How to test Qubes 4.1.1-rc1 If you’re willing to test (https://www.qubes-os.org/doc/testing/) this release candidate, you can help to improve the eventual stable release by reporting any bugs you encounter (https://www.qubes-os.org/doc/issue-tracking/). We strongly encourage experience users to join the testing team (forum.qubes-os.org/t/joini…eam/5190)! Release candidate planning If no significant bugs are discovered in 4.1.1-rc1, we expect to announce the stable release of 4.1.1 in two to three weeks.

QSB-081: x86: MMIO Stale Data vulnerabilities (XSA-404) www.qubes-os.org/news/20…/qsb-081 We have just published Qubes Security Bulletin (QSB) 081: x86: MMIO Stale Data vulnerabilities (XSA-404). 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-081 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 081 ]===--- 2022-06-17 x86: MMIO Stale Data vulnerabilities (XSA-404) User action required --------------------- Users with appropriate hardware (see the "affected hardware" section below) 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-41 For Qubes 4.1, in dom0: - Xen packages, version 4.14.5-3 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-06-14, the Xen Project published XSA-404, "x86: MMIO Stale Data vulnerabilities" [3]: | This issue is related to the SRBDS, TAA and MDS vulnerabilities. | Please see: | | https://xenbits.xen.org/xsa/advisory-320.html (SRBDS) | https://xenbits.xen.org/xsa/advisory-305.html (TAA) | https://xenbits.xen.org/xsa/advisory-297.html (MDS) | | Please see Intel's whitepaper: | | www.intel.com/content…ies.html Impact ------- An adversary who controls a VM with an assigned PCI device can infer the memory content of other guests or Xen itself. This could allow the adversary to read information that should be accessible only to Xen or another VM and to use that information to launch further attacks. In the default Qubes OS configuration, only sys-net and sys-usb can be used to perform this attack. Affected hardware ------------------ All Intel systems are affected. While mitigations are available, they are available only for some Intel CPU models. Normally, it should be a simple matter to look up a given CPU model number in a table to see whether it is affected and whether it is eligible for any mitigations. Indeed, Intel has published a table [4] that claims to serve this purpose. Unfortunately, however, we have found several inaccuracies in this table. Since we cannot rely on the table, we have had to devise an alternative method using other published Intel technical documents that appear to be more accurate. This has turned out to be quite complex. Our best evidence indicates that mitigations are available for all and only those CPUs that are both eligible for and updated with the Intel microcode update released in May 2022. [5] Since going through all the complicated technical steps of checking this manually would be excessively cumbersome for most users, we have written a tool that does it for you. Please note that this tool is entirely optional and is *not* required for any security updates to take effect. Rather, its intended purpose is to satisfy the curiosity of users who wish to know whether their own CPUs are eligible for mitigations and who would struggle to

make that determination manually. This tool is included in the `qubes-core-dom0-linux-4.0.35` package for Qubes 4.0 and the `qubes-core-dom0-linux-4.1.23` package for Qubes 4.1. 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] After installing the required updates, you will be able to execute `sudo cpu-microcode-info` in a dom0 terminal. This will output a table of information about the logical CPUs (aka CPU "cores") in your system. The "F-M-S/PI" column lists the "Family-Model-Stepping/Platform ID" codes that Intel uses in its microcode documentation, [5] which is explained in further detail in Intel's README. [6] (The manual process of checking would involve extracting your CPU information, converting it to hexadecimal, and looking it up in the appropriate table in this document.) The "Loaded microcode version" column lists the microcode versions currently loaded for each CPU. The "20220510 update available" column lists whether the required May 2022 microcode update is *available* for each CPU. The "20220510 update installed" column lists whether the required May 2022 microcode update is *installed* in each CPU. In order for the updates associated with this bulletin to successfully mitigate XSA-404, a value of "yes" is required in both of these last two "20220510 update" columns. If the "available" column has a "yes" while the "installed" column has a "no," then the May 2022 microcode update must be installed first. If both columns have "no" values, then this CPU remains vulnerable, and there is no known mitigation available. If your system has such a CPU, then installing The Xen packages listed in the "user action required" section above is *not* expected to mitigate the problem described in this bulletin. Unfortunately, there is simply nothing we can do for these CPUs in terms of patching unless we receive a fix from Intel or receive new information about which CPUs are affected. Nonetheless, we still recommend installing the updates anyway (once available), since they will not make the problem any worse, keeping up-to-date with all security updates is a general best practice, and future updates will be based on the latest version. However, hope is not entirely lost for users whose CPUs are not eligible for software mitigations. Since the vulnerability discussed in this bulletin does not affect VMs without PCI passthrough devices, users still have the option of altering their habits to treat VMs like sys-usb and sys-net as more trusted. While this can be especially challenging in the case of sys-net, it at least affords users *some* latitude in working around the problem by being mindful of when such VMs are running, how trusted their templates are, and similar considerations. Further plans regarding PCI passthrough ---------------------------------------- This is yet another issue affecting only VMs with access to PCI devices. This pattern of vulnerabilities has prompted us to research more secure ways of handling such VMs in future Qubes releases. Eventually, we plan to treat them as more privileged VMs that require additional protection. Specific protective measures will be discussed with the community as part of our ongoing research and development efforts. 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-404.html [4] www.intel.com/content…del.html [5] github.com/intel/I…enote.md

[6] github.com/intel/I…ta-Files -- The Qubes Security Team https://www.qubes-os.org/security/