XSAs released on 2022-01-25
https://www.qubes-os.org/news/2022/01/25/xsas-released-on-2022-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:
https://www.qubes-os.org/news/2022/01/25/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/
https://www.qubes-os.org/news/2022/01/25/xsas-released-on-2022-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:
https://www.qubes-os.org/news/2022/01/25/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/
QSB-075: Insufficient cleanup of passed-through device IRQs (XSA-395)
https://www.qubes-os.org/news/2022/01/25/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:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-075-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/
https://www.qubes-os.org/news/2022/01/25/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:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-075-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/
👍1
Qubes OS 4.1.0 has been released!
https://www.qubes-os.org/news/2022/02/04/qubes-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 (https://www.qubes-os.org/news/2020/03/18/gui-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 (https://www.qubes-os.org/news/2020/03/18/gui-domain/#what-will-actually-be-in-qubes-41).)
Qubes Architecture Next Steps: The New Qrexec Policy System (https://www.qubes-os.org/news/2020/06/22/new-qrexec-policy-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 (https://www.qubes-os.org/news/2020/10/05/new-gentoo-templates-and-maintenance-infrastructure/)
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 (https://www.qubes-os.org/news/2021/02/28/improvements-in-testing-and-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 (https://www.qubes-os.org/news/2021/10/08/reproducible-builds-for-debian-a-big-step-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 (https://github.com/QubesOS/qubes-issues/issues?q=milestone%3A%22Release+4.1%22+is%3Aclosed+-label%3A%22R%3A+duplicate%22+-label%3A%22R%3A+invalid%22+-label%3A%22R%3A+cannot+reproduce%22+-label%3A%22R%3A+not+an+issue%22+-label%3A%22R%3A+not+our+bug%22+-label%3A%22R%3A+won%27t+do%22+-label%3A%22R%3A+won%27t+fix%22+).
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/).
https://www.qubes-os.org/news/2022/02/04/qubes-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 (https://www.qubes-os.org/news/2020/03/18/gui-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 (https://www.qubes-os.org/news/2020/03/18/gui-domain/#what-will-actually-be-in-qubes-41).)
Qubes Architecture Next Steps: The New Qrexec Policy System (https://www.qubes-os.org/news/2020/06/22/new-qrexec-policy-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 (https://www.qubes-os.org/news/2020/10/05/new-gentoo-templates-and-maintenance-infrastructure/)
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 (https://www.qubes-os.org/news/2021/02/28/improvements-in-testing-and-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 (https://www.qubes-os.org/news/2021/10/08/reproducible-builds-for-debian-a-big-step-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 (https://github.com/QubesOS/qubes-issues/issues?q=milestone%3A%22Release+4.1%22+is%3Aclosed+-label%3A%22R%3A+duplicate%22+-label%3A%22R%3A+invalid%22+-label%3A%22R%3A+cannot+reproduce%22+-label%3A%22R%3A+not+an+issue%22+-label%3A%22R%3A+not+our+bug%22+-label%3A%22R%3A+won%27t+do%22+-label%3A%22R%3A+won%27t+fix%22+).
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/).
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 (https://www.qubes-os.org/doc/releases/4.1/release-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 (https://github.com/QubesOS/qubes-issues/issues/6364) for more
information)
Qubes firewall reworked to be more defensive (see
#5540 (https://github.com/QubesOS/qubes-issues/issues/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 (https://github.com/QubesOS/qubes-issues/issues/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 (https://github.com/QubesOS/qubes-issues/issues/4370) for
details)
qrexec protocol improvements (see
#4909 (https://github.com/QubesOS/qubes-issues/issues/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 (https://github.com/QubesOS/qubes-issues/issues/5802) and
#2624 (https://github.com/QubesOS/qubes-issues/issues/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”
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 (https://www.qubes-os.org/doc/releases/4.1/release-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 (https://github.com/QubesOS/qubes-issues/issues/6364) for more
information)
Qubes firewall reworked to be more defensive (see
#5540 (https://github.com/QubesOS/qubes-issues/issues/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 (https://github.com/QubesOS/qubes-issues/issues/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 (https://github.com/QubesOS/qubes-issues/issues/4370) for
details)
qrexec protocol improvements (see
#4909 (https://github.com/QubesOS/qubes-issues/issues/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 (https://github.com/QubesOS/qubes-issues/issues/5802) and
#2624 (https://github.com/QubesOS/qubes-issues/issues/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 denoscriptions, please see
here (https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+sort%3Aupdated-desc+milestone%3A%22Release+4.1%22+label%3A%22release+notes%22+is%3Aclosed).
/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 denoscriptions, please see
here (https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+sort%3Aupdated-desc+milestone%3A%22Release+4.1%22+label%3A%22release+notes%22+is%3Aclosed).
QSB-076: Intel microcode updates
https://www.qubes-os.org/news/2022/02/11/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:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-076-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 denoscription 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] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/main/releasenote.md#microcode-2022027
[4] https://www.intel.com/content/www/us/en/security-center/default.html
[5] https://access.redhat.com/articles/6716541
[6] https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html
[7] https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00561.html
[8] https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/fast-store-forwarding-predictor.html
https://www.qubes-os.org/news/2022/02/11/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:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-076-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 denoscription 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] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/main/releasenote.md#microcode-2022027
[4] https://www.intel.com/content/www/us/en/security-center/default.html
[5] https://access.redhat.com/articles/6716541
[6] https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html
[7] https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00561.html
[8] https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/fast-store-forwarding-predictor.html
Qubes Canary 030
https://www.qubes-os.org/news/2022/03/08/canary-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:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-030-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 (https://rss.nytimes.com/services/xml/rss/nyt/World.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
https://www.qubes-os.org/news/2022/03/08/canary-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:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-030-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 (https://rss.nytimes.com/services/xml/rss/nyt/World.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/
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/
XSAs released on 2022-03-08
https://www.qubes-os.org/news/2022/03/10/xsas-released-on-2022-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:
https://www.qubes-os.org/news/2022/03/10/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/
https://www.qubes-os.org/news/2022/03/10/xsas-released-on-2022-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:
https://www.qubes-os.org/news/2022/03/10/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/
QSB-077: Multiple speculative security issues (XSA-398)
https://www.qubes-os.org/news/2022/03/10/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:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-077-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
| https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability
| https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00598.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:
| https://grsecurity.net/amd_branch_mispredictor_part_2_where_no_cpu_has_gone_before
| https://www.amd.com/en/corporate/product-security/bulletin/amd-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:
| https://www.amd.com/en/corporate/product-security/bulletin/amd-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.
https://www.qubes-os.org/news/2022/03/10/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:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-077-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
| https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability
| https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00598.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:
| https://grsecurity.net/amd_branch_mispredictor_part_2_where_no_cpu_has_gone_before
| https://www.amd.com/en/corporate/product-security/bulletin/amd-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:
| https://www.amd.com/en/corporate/product-security/bulletin/amd-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.
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/
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/
Whonix support for Qubes 4.0 extended
https://www.qubes-os.org/news/2022/03/17/whonix-support-for-qubes-4-0-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 (https://www.qubes-os.org/news/2022/02/04/qubes-4-1-0/).
How does Whonix support work?
While Qubes OS releases are supported for six months (https://www.qubes-os.org/doc/supported-releases/#qubes-os) following each
subsequent major or minor release, Whonix templates have their own
support policy (https://www.qubes-os.org/doc/supported-releases/#note-on-whonix-support) 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.
https://www.qubes-os.org/news/2022/03/17/whonix-support-for-qubes-4-0-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 (https://www.qubes-os.org/news/2022/02/04/qubes-4-1-0/).
How does Whonix support work?
While Qubes OS releases are supported for six months (https://www.qubes-os.org/doc/supported-releases/#qubes-os) following each
subsequent major or minor release, Whonix templates have their own
support policy (https://www.qubes-os.org/doc/supported-releases/#note-on-whonix-support) 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.
Qubes OS configuration survey! (5-10 minutes)
https://www.qubes-os.org/news/2022/03/23/qubes-os-configuration-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
https://www.qubes-os.org/news/2022/03/23/qubes-os-configuration-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
MirageOS Announces Latest Release v4.0, dedicated to Lars Kurth
https://xenproject.org/2022/03/30/mirageos-announces-latest-release-v4-0-dedicated-to-lars-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...
https://xenproject.org/2022/03/30/mirageos-announces-latest-release-v4-0-dedicated-to-lars-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...
XSAs released on 2022-04-05
https://www.qubes-os.org/news/2022/04/05/xsas-released-on-2022-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:
https://www.qubes-os.org/news/2022/04/05/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/
https://www.qubes-os.org/news/2022/04/05/xsas-released-on-2022-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:
https://www.qubes-os.org/news/2022/04/05/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/
QSB-079: Two IOMMU-related Xen issues (XSA-399, XSA-400)
https://www.qubes-os.org/news/2022/04/05/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:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-079-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/
https://www.qubes-os.org/news/2022/04/05/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:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-079-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/
⚠️ This channel is updated ASAP after devs make an announcement to the project.
Help?
English Group: t.me/joinchat/B8FHpkEToMfgdREGV7wzRQ
German Group: @QubesOS_user_de
Help?
English Group: t.me/joinchat/B8FHpkEToMfgdREGV7wzRQ
German Group: @QubesOS_user_de
Telegram
QubesOS Chat
(Community Support)
Alternative community instead of online forum and discord.
@QubesOS
>No spam/ads/NSFW/shit posts/spam bots
>Respect others
>Stay on topic
>Be transparent
If you need help ask!
Rules are enforced with ban or restrictions.
Alternative community instead of online forum and discord.
@QubesOS
>No spam/ads/NSFW/shit posts/spam bots
>Respect others
>Stay on topic
>Be transparent
If you need help ask!
Rules are enforced with ban or restrictions.
Windows integration work in Qubes 4.1 by the tabit-pro team
https://www.qubes-os.org/news/2022/04/10/windows-integration-by-tabit-pro/
Editor’s note: This is a guest article by Ivan Kardykov from
tabit-pro (https://tabit.pro/). We’ve invited Ivan to explain the work
the tabit-pro team contributed to Qubes 4.1. Welcome, Ivan!
In this article, I’ll briefly describe the code contributions we made to
the latest Qubes 4.1 release, most of which focus on improving Windows
integration.
OEM activation support
When Windows comes preinstalled on a computer, license activation is
based on a certificate embedded in the hardware. Technically, this uses
one of the ACPI tables called “SLIC,” which is readable by the host OS.
This option is not available in Qubes OS, since each qube is a Xen
virtual machine (VM) that has no physical hardware of its own. However,
a small change in Xen allowed us to copy the necessary data onto the
appropriate memory partition of the VM (thanks to OpenXT for the working
patch). This can be done simply by extending the VM configuration with
the SLIC data via the libvirt template
extension (https://github.com/QubesOS/qubes-issues/issues/5279#issuecomment-525947408).
This fix has been included in stable packages for a long time. In fact,
it is also available for Qubes 4.0 users.
Audio support
Audio virtualization in Qubes OS is based on communication between
PulseAudio services running in each VM, including dom0 (described in
more detail here (https://www.qubes-os.org/doc/audio-virtualization/)). Unfortunately, this
method is problematic in the case of Windows VMs due to the lack of
PulseAudio support in Windows, and attempting to support it
independently seems like too time-consuming of a task (see
#2624 (https://github.com/QubesOS/qubes-issues/issues/2624)).
An alternative is to use QEMU, which allows for the emulation of
different audio devices and docking with PulseAudio. In our case, the
main obstacle for this method is the complexity of the connection to
QEMU, which is isolated by a stubdomain. We developed a patch that
allows for building and starting the necessary components for PulseAudio
in a minimal environment with vchan support. We also worked out a
separate version for building the stubdomain image with extended
functionality (the xen-hvm-stubdom-linux-full package). This mode is
activated in HVMs by setting the audio-model feature (using
qvm-features) and specifying the type of audio device, for example,
ich6. (Device variants are described in the QEMU documentation.)
USB support
We used a similar approach to improve support for USB devices. In the
extended stubdomain, we proposed including qrexec and USB-proxy services
and including libusb features in QEMU (see
qubes-app-linux-usb-proxy (https://github.com/QubesOS/qubes-app-linux-usb-proxy)).
As a result, we didn’t even need to increase the available memory in
order to achieve stable operation of the extended stubdomain, although
it may be a problem when using some devices (e.g., webcams). There was a
question of which controller type QEMU should emulate. After
experimenting with different devices, we settled on the NEC XHCI, in
part due to the availability of Windows 7 drivers. The activation of
this emulation mode in HVMs is done by setting the stubdom-qrexec
property (using qvm-features). Details of user testing can be found on
the Qubes
Forum (https://forum.qubes-os.org/t/windows-usb-integration-with-r4-1/5001).
Not only Windows
The advantage of this approach is that there is no need to install guest
tools for attaching audio and USB devices, which allows the emulation to
be used not only with Windows, but with any OS (e.g., Linux live images,
Android x86, and probably ReactOS). At the same time, there are also
disadvantages. In particular, the additional workload can slow down the
VM and affect the sound quality. (Even at minimum workload, you may
notice crackling.)
Qubes Windows Tools
https://www.qubes-os.org/news/2022/04/10/windows-integration-by-tabit-pro/
Editor’s note: This is a guest article by Ivan Kardykov from
tabit-pro (https://tabit.pro/). We’ve invited Ivan to explain the work
the tabit-pro team contributed to Qubes 4.1. Welcome, Ivan!
In this article, I’ll briefly describe the code contributions we made to
the latest Qubes 4.1 release, most of which focus on improving Windows
integration.
OEM activation support
When Windows comes preinstalled on a computer, license activation is
based on a certificate embedded in the hardware. Technically, this uses
one of the ACPI tables called “SLIC,” which is readable by the host OS.
This option is not available in Qubes OS, since each qube is a Xen
virtual machine (VM) that has no physical hardware of its own. However,
a small change in Xen allowed us to copy the necessary data onto the
appropriate memory partition of the VM (thanks to OpenXT for the working
patch). This can be done simply by extending the VM configuration with
the SLIC data via the libvirt template
extension (https://github.com/QubesOS/qubes-issues/issues/5279#issuecomment-525947408).
This fix has been included in stable packages for a long time. In fact,
it is also available for Qubes 4.0 users.
Audio support
Audio virtualization in Qubes OS is based on communication between
PulseAudio services running in each VM, including dom0 (described in
more detail here (https://www.qubes-os.org/doc/audio-virtualization/)). Unfortunately, this
method is problematic in the case of Windows VMs due to the lack of
PulseAudio support in Windows, and attempting to support it
independently seems like too time-consuming of a task (see
#2624 (https://github.com/QubesOS/qubes-issues/issues/2624)).
An alternative is to use QEMU, which allows for the emulation of
different audio devices and docking with PulseAudio. In our case, the
main obstacle for this method is the complexity of the connection to
QEMU, which is isolated by a stubdomain. We developed a patch that
allows for building and starting the necessary components for PulseAudio
in a minimal environment with vchan support. We also worked out a
separate version for building the stubdomain image with extended
functionality (the xen-hvm-stubdom-linux-full package). This mode is
activated in HVMs by setting the audio-model feature (using
qvm-features) and specifying the type of audio device, for example,
ich6. (Device variants are described in the QEMU documentation.)
USB support
We used a similar approach to improve support for USB devices. In the
extended stubdomain, we proposed including qrexec and USB-proxy services
and including libusb features in QEMU (see
qubes-app-linux-usb-proxy (https://github.com/QubesOS/qubes-app-linux-usb-proxy)).
As a result, we didn’t even need to increase the available memory in
order to achieve stable operation of the extended stubdomain, although
it may be a problem when using some devices (e.g., webcams). There was a
question of which controller type QEMU should emulate. After
experimenting with different devices, we settled on the NEC XHCI, in
part due to the availability of Windows 7 drivers. The activation of
this emulation mode in HVMs is done by setting the stubdom-qrexec
property (using qvm-features). Details of user testing can be found on
the Qubes
Forum (https://forum.qubes-os.org/t/windows-usb-integration-with-r4-1/5001).
Not only Windows
The advantage of this approach is that there is no need to install guest
tools for attaching audio and USB devices, which allows the emulation to
be used not only with Windows, but with any OS (e.g., Linux live images,
Android x86, and probably ReactOS). At the same time, there are also
disadvantages. In particular, the additional workload can slow down the
VM and affect the sound quality. (Even at minimum workload, you may
notice crackling.)
Qubes Windows Tools
A relatively long time ago, we proposed building all the components of
Qubes Windows Tools (QWT) in a Linux environment using MinGW and Wine,
which allows us to use our existing CI tools and simplify the
maintenance of changes. We also worked a lot on improving the stability
of all the components, in particular, eliminating the causes of freezes
and performance degradation. In recent weeks, all of our proposed
changes have been approved and merged, and the
cross-build (https://github.com/QubesOS/qubes-windows-tools-cross)
project has been added as a Qubes OS component. I’m sure everything will
be available in the stable repositories soon.
Conclusion
The result of our work is full integration of Windows 7, 10, and 11 in
Qubes OS and significant improvements in usability for even
inexperienced users.
Thanks to all members of the tabit-pro team, especially Dmitriy Fedorov
(@easydozen (https://github.com/easydozen)). Many thanks to Marek
Marczykowski-Górecki for his assistance and the Qubes dev team as a
whole for their daily work. Special thanks to the Qubes community,
especially for their kind words of support.
Ivan Kardykov
tabit.pro (https://tabit.pro/)
Qubes Windows Tools (QWT) in a Linux environment using MinGW and Wine,
which allows us to use our existing CI tools and simplify the
maintenance of changes. We also worked a lot on improving the stability
of all the components, in particular, eliminating the causes of freezes
and performance degradation. In recent weeks, all of our proposed
changes have been approved and merged, and the
cross-build (https://github.com/QubesOS/qubes-windows-tools-cross)
project has been added as a Qubes OS component. I’m sure everything will
be available in the stable repositories soon.
Conclusion
The result of our work is full integration of Windows 7, 10, and 11 in
Qubes OS and significant improvements in usability for even
inexperienced users.
Thanks to all members of the tabit-pro team, especially Dmitriy Fedorov
(@easydozen (https://github.com/easydozen)). Many thanks to Marek
Marczykowski-Górecki for his assistance and the Qubes dev team as a
whole for their daily work. Special thanks to the Qubes community,
especially for their kind words of support.
Ivan Kardykov
tabit.pro (https://tabit.pro/)
🔥3