QSB-067: Multiple RPM vulnerabilities
https://www.qubes-os.org/news/2021/03/19/qsb-067/
We have just published Qubes Security Bulletin (QSB) 067: Multiple RPM vulnerabilities.
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack (qubes-secpack).
View QSB-067 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-067-2021.txt
Learn about the qubes-secpack, including how to obtain, verify, and read it:
https://www.qubes-os.org/security/pack/
View all past QSBs:
https://www.qubes-os.org/security/bulletins/
---===[ Qubes Security Bulletin 067 ]===---
2021-03-19
Multiple RPM vulnerabilities
User action required
=====================
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.0:
- rpm 4.14.2.1 (plus rebuilt packages to link with the new rpm)
- qubes-core-dom0-linux 4.0.29
- qubes-mgmt-salt-dom0-update 4.0.10
For Qubes 4.1:
- qubes-core-dom0-linux 4.1.10
- qubes-mgmt-salt-dom0-update 4.1.6
The packages are to be installed in dom0 via the Qubes Update tool [4]
or via the qubes-dom0-update command as follows:
For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update
For updates from the security-testing repository:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
After installing the updates in dom0, it is necessary to install updates
in Fedora-based TemplateVMs and StandaloneVMs. This can be
done via the Qubes Update tool [4] or using qubesctl (salt) as follows:
$ sudo qubesctl --skip-dom0 --templates --standalones state.sls update.qubes-vm
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.
Summary
========
Demi M. Obenour has discovered several issues in the RPM package
manager:
- CVE-2021-20271[1] RPM: Signature checks bypass via corrupted RPM
package
- CVE-2021-3421[2] RPM: unsigned signature header leads to string
injection into an RPM database
- CVE-2021-20266[3] RPM: missing length checks in hdrblobInit()
These issues allow an attacker who controls packages the user downloads
to inject malicious content that, under some conditions, may not be
detected by signature verification. Specifically, they allow the
attacker to modify parts of the package header that are not protected by
the signature and that are later integrated into the RPM database. This
allows for corrupting the RPM database and preventing further updates of
select packages. In the case of Fedora TemplateVMs, this also allows
for arbitrary code execution.
The CVE-2021-20271 exploit takes advantage of multiple headers in the
RPM package format. In a proper RPM package, the signature is placed in
a separate header (called the "signature header") and, if present, is
verified by librpm when loading the file (according to the requested
verification level). An RPM package also contains a "main header" that
includes all the other package metadata. The main header is protected by
a signature in the signature header. The payload is protected either by
a signature in the signature header or by a SHA-256 hash located in the
main header. The ability to distinguish between these two headers is
available to librpm internals but not to external librpm users.
A malformed package may contain a signature in the main header instead
of the signature header. Librpm will reject such a package only if a
strict signature check was requested. Otherwise, it will treat the
package as unsigned. DNF, on the other hand, has no way to check whether
the signature was in the correct header. It will load the package and,
seeing a signature, will assume that it was verified by librpm. This
https://www.qubes-os.org/news/2021/03/19/qsb-067/
We have just published Qubes Security Bulletin (QSB) 067: Multiple RPM vulnerabilities.
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack (qubes-secpack).
View QSB-067 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-067-2021.txt
Learn about the qubes-secpack, including how to obtain, verify, and read it:
https://www.qubes-os.org/security/pack/
View all past QSBs:
https://www.qubes-os.org/security/bulletins/
---===[ Qubes Security Bulletin 067 ]===---
2021-03-19
Multiple RPM vulnerabilities
User action required
=====================
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.0:
- rpm 4.14.2.1 (plus rebuilt packages to link with the new rpm)
- qubes-core-dom0-linux 4.0.29
- qubes-mgmt-salt-dom0-update 4.0.10
For Qubes 4.1:
- qubes-core-dom0-linux 4.1.10
- qubes-mgmt-salt-dom0-update 4.1.6
The packages are to be installed in dom0 via the Qubes Update tool [4]
or via the qubes-dom0-update command as follows:
For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update
For updates from the security-testing repository:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
After installing the updates in dom0, it is necessary to install updates
in Fedora-based TemplateVMs and StandaloneVMs. This can be
done via the Qubes Update tool [4] or using qubesctl (salt) as follows:
$ sudo qubesctl --skip-dom0 --templates --standalones state.sls update.qubes-vm
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.
Summary
========
Demi M. Obenour has discovered several issues in the RPM package
manager:
- CVE-2021-20271[1] RPM: Signature checks bypass via corrupted RPM
package
- CVE-2021-3421[2] RPM: unsigned signature header leads to string
injection into an RPM database
- CVE-2021-20266[3] RPM: missing length checks in hdrblobInit()
These issues allow an attacker who controls packages the user downloads
to inject malicious content that, under some conditions, may not be
detected by signature verification. Specifically, they allow the
attacker to modify parts of the package header that are not protected by
the signature and that are later integrated into the RPM database. This
allows for corrupting the RPM database and preventing further updates of
select packages. In the case of Fedora TemplateVMs, this also allows
for arbitrary code execution.
The CVE-2021-20271 exploit takes advantage of multiple headers in the
RPM package format. In a proper RPM package, the signature is placed in
a separate header (called the "signature header") and, if present, is
verified by librpm when loading the file (according to the requested
verification level). An RPM package also contains a "main header" that
includes all the other package metadata. The main header is protected by
a signature in the signature header. The payload is protected either by
a signature in the signature header or by a SHA-256 hash located in the
main header. The ability to distinguish between these two headers is
available to librpm internals but not to external librpm users.
A malformed package may contain a signature in the main header instead
of the signature header. Librpm will reject such a package only if a
strict signature check was requested. Otherwise, it will treat the
package as unsigned. DNF, on the other hand, has no way to check whether
the signature was in the correct header. It will load the package and,
seeing a signature, will assume that it was verified by librpm. This
allows for bypassing package signature verification.
The other bugs (CVE-2021-20266, CVE-2021-3421) concern incorrect parsing
of the signature header (which, while it contains the signature, is
itself unsigned). These bugs lead either to crashing or to corrupting
the RPM database (if such a malformed package is installed).
While Fedora will release its own patches in due course, we apply a
mitigation that prevents the privilege escalation aspect of these
issues. We configure RPM to always verify package signatures, even if a
higher level package manager (like DNF) does not explicitly request it.
This way, bypassing the signature check in DNF is not enough to
compromise an entire TemplateVM. Note that this change also prevents the
installation of unsigned RPM packages, even when explicitly requested.
See the "Side effects" section below.
For the dom0 aspect of these issues in Qubes 4.0, we update RPM to a
version that is not vulnerable. We have decided to update to the next
major version of RPM (from 4.13 to 4.14). This is because, besides the
security fix itself (which could be backported), version 4.14 has
significantly improved integrity verification. In 4.14, the macro
_pkgverify_level can be used to require that all packages be signed by a
trusted key. It defaults to "digest", meaning that only checksums must
be present, but we have set it to "all", requiring that all packages be
signed. Additionally, the checks performed before importing a package
have been significantly enhanced, which substantially reduces the attack
surface prior to integrity verification.
In the near future, we will also deploy an extra tool to perform
preliminary validation of all RPM packages in dom0 before handing them
over to RPM.
Impact
=======
The impact differs between Fedora templates and dom0:
1. For Fedora templates, an attacker who controls packages that the user
downloads can completely bypass package signature verification and
fully compromise Fedora templates.
2. For dom0, an attacker who controls packages that the user downloads
can corrupt the RPM database and (almost silently) prevent further
updates of select packages.
The attack requires control over the contents of downloaded packages.
This requirement differs slightly between Fedora templates and dom0:
1. For Fedora templates, the attacker would either have to
a. compromise the Fedora infrastructure that is serving updates or
b. perform a man-in-the-middle attack on the HTTPS connection used to
download the repository metadata (which contains package hashes).
2. For dom0, the attacker would either have to attack the user's
repository access (as in the Fedora template case) or compromise the
UpdateVM (sys-firewall in the default configuration).
Side effects
=============
The mitigation forces signature verification in RPM regardless of other
options. This means that RPM will refuse to install packages that are
unsigned (or signed with an untrusted signature), even when explicitly
requested to do so. This breaks use cases such as installing
locally-built packages and installing manually-downloaded packages the
integrity of which was verified separately (which is often the case for
closed-source software).
In such cases, neither `dnf install /path/to/the/package.rpm` nor `rpm
-i /path/to/the/package.rpm` will work any longer. Instead, to install a
package without a trusted signature (that has been verified by other
means), use the following command:
rpm --define '_pkgverify_level digest' -i /path/to/the/package.rpm
If the package has any dependencies, the above command will list them,
and they will have to be installed with `dnf` manually.
Credits
========
These issues were discovered and reported by Demi M. Obenour.
References
===========
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1934125
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1927747
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1927741
The other bugs (CVE-2021-20266, CVE-2021-3421) concern incorrect parsing
of the signature header (which, while it contains the signature, is
itself unsigned). These bugs lead either to crashing or to corrupting
the RPM database (if such a malformed package is installed).
While Fedora will release its own patches in due course, we apply a
mitigation that prevents the privilege escalation aspect of these
issues. We configure RPM to always verify package signatures, even if a
higher level package manager (like DNF) does not explicitly request it.
This way, bypassing the signature check in DNF is not enough to
compromise an entire TemplateVM. Note that this change also prevents the
installation of unsigned RPM packages, even when explicitly requested.
See the "Side effects" section below.
For the dom0 aspect of these issues in Qubes 4.0, we update RPM to a
version that is not vulnerable. We have decided to update to the next
major version of RPM (from 4.13 to 4.14). This is because, besides the
security fix itself (which could be backported), version 4.14 has
significantly improved integrity verification. In 4.14, the macro
_pkgverify_level can be used to require that all packages be signed by a
trusted key. It defaults to "digest", meaning that only checksums must
be present, but we have set it to "all", requiring that all packages be
signed. Additionally, the checks performed before importing a package
have been significantly enhanced, which substantially reduces the attack
surface prior to integrity verification.
In the near future, we will also deploy an extra tool to perform
preliminary validation of all RPM packages in dom0 before handing them
over to RPM.
Impact
=======
The impact differs between Fedora templates and dom0:
1. For Fedora templates, an attacker who controls packages that the user
downloads can completely bypass package signature verification and
fully compromise Fedora templates.
2. For dom0, an attacker who controls packages that the user downloads
can corrupt the RPM database and (almost silently) prevent further
updates of select packages.
The attack requires control over the contents of downloaded packages.
This requirement differs slightly between Fedora templates and dom0:
1. For Fedora templates, the attacker would either have to
a. compromise the Fedora infrastructure that is serving updates or
b. perform a man-in-the-middle attack on the HTTPS connection used to
download the repository metadata (which contains package hashes).
2. For dom0, the attacker would either have to attack the user's
repository access (as in the Fedora template case) or compromise the
UpdateVM (sys-firewall in the default configuration).
Side effects
=============
The mitigation forces signature verification in RPM regardless of other
options. This means that RPM will refuse to install packages that are
unsigned (or signed with an untrusted signature), even when explicitly
requested to do so. This breaks use cases such as installing
locally-built packages and installing manually-downloaded packages the
integrity of which was verified separately (which is often the case for
closed-source software).
In such cases, neither `dnf install /path/to/the/package.rpm` nor `rpm
-i /path/to/the/package.rpm` will work any longer. Instead, to install a
package without a trusted signature (that has been verified by other
means), use the following command:
rpm --define '_pkgverify_level digest' -i /path/to/the/package.rpm
If the package has any dependencies, the above command will list them,
and they will have to be installed with `dnf` manually.
Credits
========
These issues were discovered and reported by Demi M. Obenour.
References
===========
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1934125
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1927747
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1927741
[4] https://www.qubes-os.org/doc/updating-qubes-os/
--
The Qubes Security Team
https://www.qubes-os.org/security/
--
The Qubes Security Team
https://www.qubes-os.org/security/
XSAs released on 2021-03-30
https://www.qubes-os.org/news/2021/03/30/xsas-released-on-2021-03-30/
The Xen Project has released one or more new Xen Security Advisories (XSAs).
The security of Qubes OS is not affected by these XSAs.
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-371 (DoS only)
Related links
Qubes Security Pack (qubes-secpack) (https://www.qubes-os.org/security/pack/)
Qubes Security Bulletins (QSBs) (https://www.qubes-os.org/security/bulletins/)
XSA Tracker (https://www.qubes-os.org/security/xsa/)
https://www.qubes-os.org/news/2021/03/30/xsas-released-on-2021-03-30/
The Xen Project has released one or more new Xen Security Advisories (XSAs).
The security of Qubes OS is not affected by these XSAs.
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-371 (DoS only)
Related links
Qubes Security Pack (qubes-secpack) (https://www.qubes-os.org/security/pack/)
Qubes Security Bulletins (QSBs) (https://www.qubes-os.org/security/bulletins/)
XSA Tracker (https://www.qubes-os.org/security/xsa/)
Xen Project Hypervisor 4.15 now Available
https://xenproject.org/2021/04/08/xen-project-hypervisor-4-15/
Xen Project ships version 4.15 with Focus on Broader Accessibility, Performance, and Security. New version introduces Processor Trace, Improved Viridian support. Community initiatives, including Functional Safety and RISC-V Port, continue...
https://xenproject.org/2021/04/08/xen-project-hypervisor-4-15/
Xen Project ships version 4.15 with Focus on Broader Accessibility, Performance, and Security. New version introduces Processor Trace, Improved Viridian support. Community initiatives, including Functional Safety and RISC-V Port, continue...
Get paid to support Qubes development through automated testing! (six-month contract)
https://www.qubes-os.org/news/2021/04/10/get-paid-to-support-qubes-development-through-automated-testing/
The Qubes OS Project is seeking an expert in automated testing. We use
OpenQA and Travis to test changes to the Qubes OS source code and
automated building from source. We’re looking for someone who can help
with improving both the automated tests themselves and the testing
infrastructure.
This is a paid position on a six-month part-time contract with a
budgeted rate of $30-50 USD per hour through the Internews BASICS
project (Building Analytical and Support Infrastructure for Critical
Security tools):
https://phf.tbe.taleo.net/phf04/ats/careers/v2/viewRequisition?cws=38&org=INTERNEWS&rid=1392
https://www.qubes-os.org/news/2021/04/10/get-paid-to-support-qubes-development-through-automated-testing/
The Qubes OS Project is seeking an expert in automated testing. We use
OpenQA and Travis to test changes to the Qubes OS source code and
automated building from source. We’re looking for someone who can help
with improving both the automated tests themselves and the testing
infrastructure.
This is a paid position on a six-month part-time contract with a
budgeted rate of $30-50 USD per hour through the Internews BASICS
project (Building Analytical and Support Infrastructure for Critical
Security tools):
https://phf.tbe.taleo.net/phf04/ats/careers/v2/viewRequisition?cws=38&org=INTERNEWS&rid=1392
Why Attend the 2021 Xen Project Design and Developer Summit?
https://xenproject.org/2021/05/18/why-attend-the-2021-xen-project-design-and-developer-summit/
It’s almost that time of year, where we gather together as a Xen Project community and geek out on one of our most favorite topics – The Xen Project, of...
https://xenproject.org/2021/05/18/why-attend-the-2021-xen-project-design-and-developer-summit/
It’s almost that time of year, where we gather together as a Xen Project community and geek out on one of our most favorite topics – The Xen Project, of...
Fedora 32 has reached EOL
https://www.qubes-os.org/news/2021/05/25/fedora-32-eol/
Fedora 32 has reached EOL (end-of-life (https://fedoraproject.org/wiki/End_of_life)). If you have not already done
so, we strongly recommend upgrading (https://www.qubes-os.org/doc/templates/fedora/#upgrading) your Fedora 32 TemplateVMs and
StandaloneVMs to Fedora 33 immediately. We provide a fresh Fedora 33
TemplateVM package through the official Qubes repositories, which you
can install in dom0 by following the standard installation
instructions (https://www.qubes-os.org/doc/templates/fedora/#installing). Alternatively, we also provide step-by-step instructions
for performing an in-place upgrade (https://www.qubes-os.org/doc/template/fedora/upgrade/) of an existing Fedora TemplateVM.
After upgrading your TemplateVMs, please remember to switch all qubes
that were using the old template to use the new one (https://www.qubes-os.org/doc/templates/#switching).
For a complete list of TemplateVM versions supported for your specific
version of Qubes, see Supported TemplateVM Versions (https://www.qubes-os.org/doc/supported-versions/#templatevms).
Please note that no user action is required regarding the OS version in
dom0. For details, please see our note on dom0 and EOL (https://www.qubes-os.org/doc/supported-versions/#note-on-dom0-and-eol).
https://www.qubes-os.org/news/2021/05/25/fedora-32-eol/
Fedora 32 has reached EOL (end-of-life (https://fedoraproject.org/wiki/End_of_life)). If you have not already done
so, we strongly recommend upgrading (https://www.qubes-os.org/doc/templates/fedora/#upgrading) your Fedora 32 TemplateVMs and
StandaloneVMs to Fedora 33 immediately. We provide a fresh Fedora 33
TemplateVM package through the official Qubes repositories, which you
can install in dom0 by following the standard installation
instructions (https://www.qubes-os.org/doc/templates/fedora/#installing). Alternatively, we also provide step-by-step instructions
for performing an in-place upgrade (https://www.qubes-os.org/doc/template/fedora/upgrade/) of an existing Fedora TemplateVM.
After upgrading your TemplateVMs, please remember to switch all qubes
that were using the old template to use the new one (https://www.qubes-os.org/doc/templates/#switching).
For a complete list of TemplateVM versions supported for your specific
version of Qubes, see Supported TemplateVM Versions (https://www.qubes-os.org/doc/supported-versions/#templatevms).
Please note that no user action is required regarding the OS version in
dom0. For details, please see our note on dom0 and EOL (https://www.qubes-os.org/doc/supported-versions/#note-on-dom0-and-eol).
NitroPad T430 passes hardware certification for Qubes 4.0!
https://www.qubes-os.org/news/2021/06/01/nitropad-t430-qubes-certification/
It is our pleasure to announce that the NitroPad T430 (https://shop.nitrokey.com/shop/product/nitropad-t430-119) has become the
third Qubes-certified Laptop (https://www.qubes-os.org/doc/certified-hardware/#qubes-certified-laptops) for Qubes 4.0! This makes
Nitrokey (https://www.nitrokey.com/) the first vendor to have two products that pass Qubes
hardware certification, the other being the NitroPad X230 (https://www.qubes-os.org/doc/certified-hardware/#nitropad-x230).
What is Qubes Certified Hardware?
Qubes Certified Hardware (https://www.qubes-os.org/doc/certified-hardware/) is hardware that has been certified by the
Qubes developers as compatible with Qubes OS. Beginning with Qubes 4.0,
in order to achieve certification, the hardware must satisfy a rigorous
set of requirements (https://www.qubes-os.org/doc/certified-hardware/#hardware-certification-requirements), and the vendor must commit to offering customers
the very same configuration (same motherboard, same screen, same BIOS
version, same Wi-Fi module, etc.) for at least one year.
Qubes-certified Laptops (https://www.qubes-os.org/doc/certified-hardware/#qubes-certified-laptops), in particular, are regularly tested
by the Qubes developers to ensure compatibility with all of Qubes’
features. The developers test all new major versions and updates to
ensure that no regressions are introduced.
It is important to note, however, that Qubes Hardware Certification
certifies only that a particular hardware configuration is supported
by Qubes. The Qubes OS Project takes no responsibility for any vendor’s
manufacturing, shipping, payment, or other practices, nor can we control
whether physical hardware is modified (whether maliciously or otherwise)
en route to the user. (However, see below for information about how
this risk is mitigated.)
About the NitroPad T430
https://www.qubes-os.org/news/2021/06/01/nitropad-t430-qubes-certification/
It is our pleasure to announce that the NitroPad T430 (https://shop.nitrokey.com/shop/product/nitropad-t430-119) has become the
third Qubes-certified Laptop (https://www.qubes-os.org/doc/certified-hardware/#qubes-certified-laptops) for Qubes 4.0! This makes
Nitrokey (https://www.nitrokey.com/) the first vendor to have two products that pass Qubes
hardware certification, the other being the NitroPad X230 (https://www.qubes-os.org/doc/certified-hardware/#nitropad-x230).
What is Qubes Certified Hardware?
Qubes Certified Hardware (https://www.qubes-os.org/doc/certified-hardware/) is hardware that has been certified by the
Qubes developers as compatible with Qubes OS. Beginning with Qubes 4.0,
in order to achieve certification, the hardware must satisfy a rigorous
set of requirements (https://www.qubes-os.org/doc/certified-hardware/#hardware-certification-requirements), and the vendor must commit to offering customers
the very same configuration (same motherboard, same screen, same BIOS
version, same Wi-Fi module, etc.) for at least one year.
Qubes-certified Laptops (https://www.qubes-os.org/doc/certified-hardware/#qubes-certified-laptops), in particular, are regularly tested
by the Qubes developers to ensure compatibility with all of Qubes’
features. The developers test all new major versions and updates to
ensure that no regressions are introduced.
It is important to note, however, that Qubes Hardware Certification
certifies only that a particular hardware configuration is supported
by Qubes. The Qubes OS Project takes no responsibility for any vendor’s
manufacturing, shipping, payment, or other practices, nor can we control
whether physical hardware is modified (whether maliciously or otherwise)
en route to the user. (However, see below for information about how
this risk is mitigated.)
About the NitroPad T430
Key features of the NitroPad T430 (https://shop.nitrokey.com/shop/product/nitropad-t430-119) include:
Tamper detection through measured boot with Coreboot (https://www.coreboot.org/), Heads (https://github.com/osresearch/heads/), and
Nitrokey USB hardware, including support for Anti Evil Maid (AEM) (https://www.qubes-os.org/doc/anti-evil-maid/)
Deactivated Intel Management Engine (https://libreboot.org/faq.html#intelme)
User-replaceable cryptographic keys
Included Nitrokey USB key
Professional ThinkPad hardware based on the ThinkPad T430 (https://www.thinkwiki.org/wiki/Category:T430)
Security-conscious shipping to mitigate against third-party
interdiction (https://en.wikipedia.org/wiki/Interdiction)
For further details, please see the NitroPad T430 (https://shop.nitrokey.com/shop/product/nitropad-t430-119) product page.
How to get one
Please see the NitroPad T430 (https://shop.nitrokey.com/shop/product/nitropad-t430-119) on the Nitrokey website (https://www.nitrokey.com/) for
purchasing information.
Tamper detection through measured boot with Coreboot (https://www.coreboot.org/), Heads (https://github.com/osresearch/heads/), and
Nitrokey USB hardware, including support for Anti Evil Maid (AEM) (https://www.qubes-os.org/doc/anti-evil-maid/)
Deactivated Intel Management Engine (https://libreboot.org/faq.html#intelme)
User-replaceable cryptographic keys
Included Nitrokey USB key
Professional ThinkPad hardware based on the ThinkPad T430 (https://www.thinkwiki.org/wiki/Category:T430)
Security-conscious shipping to mitigate against third-party
interdiction (https://en.wikipedia.org/wiki/Interdiction)
For further details, please see the NitroPad T430 (https://shop.nitrokey.com/shop/product/nitropad-t430-119) product page.
How to get one
Please see the NitroPad T430 (https://shop.nitrokey.com/shop/product/nitropad-t430-119) on the Nitrokey website (https://www.nitrokey.com/) for
purchasing information.
Unikraft at Usenix Lisa 21 Conference: It’s Time to Debloat the Cloud with Unikraft
https://xenproject.org/2021/06/01/unikraft-at-usenix-lisa-21-conference-its-time-to-debloat-the-cloud-with-unikraft/
On Thursday, June 3 at 12 pm PT, check out Unikraft’s talk at Usenix Lisa 21. Felipe Huici, NEC Laboratories Europe GmbH, will be giving the following talk, “It’s Time...
https://xenproject.org/2021/06/01/unikraft-at-usenix-lisa-21-conference-its-time-to-debloat-the-cloud-with-unikraft/
On Thursday, June 3 at 12 pm PT, check out Unikraft’s talk at Usenix Lisa 21. Felipe Huici, NEC Laboratories Europe GmbH, will be giving the following talk, “It’s Time...
QSB-068: Disconnecting a video output can cause XScreenSaver to crash
https://www.qubes-os.org/news/2021/06/04/qsb-068/
We have just published Qubes Security Bulletin (QSB) 068:
Disconnecting a video output can cause XScreenSaver to crash.
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-068 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-068-2021.txt
Learn about the qubes-secpack, including how to obtain, verify, and read it:
https://www.qubes-os.org/security/pack/
View all past QSBs:
https://www.qubes-os.org/security/bulletins/
---===[ Qubes Security Bulletin 068 ]===---
2021-06-04
Disconnecting a video output can cause XScreenSaver to crash
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:
- xscreensaver 5.45-5
For Qubes 4.1, in dom0:
- xscreensaver 5.45-5
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 this update, the XScreenSaver daemon process must be
restarted in order for the changes to take effect. This can be done by
restarting dom0, logging out of dom0 then logging back in, or issuing
the following command in a dom0 terminal:
xscreensaver-command -exit; xscreensaver &
Summary
========
XScreenSaver is the default screen locker in dom0. It tracks which video
outputs are connected to the system in order to blank them properly. In
some specific hardware configurations, disconnecting an output can cause
XScreenSaver to crash, leaving the screen unlocked.
Impact
=======
On hardware configurations with more than 10 video outputs that can be
disconnected, an attacker with physical access to a screen-locked system
may be able to unlock it by physically disconnecting one or more
outputs, bypassing standard screen lock authentication.
Details
========
On X11, screen locking and blanking is done by creating a window that
obscures the whole screen, which is a standard practice. In
XScreenSaver, each such window is assigned a specific property. When a
video output is disconnected, its corresponding blanking window is
destroyed, and its XScreenSaver-specific property is removed so that it
will not be used by `xscreensaver-command` anymore. This is handled by
the `update_screen_layout()` function in the `driver/screens.c` file:
985 /* Synchronize the contents of si->ssi to the current state of the monitors.
986 Doesn't change anything if nothing has changed; otherwise, alters and
987 reuses existing saver_screen_info structs as much as possible.
988 Returns True if anything changed.
989 */
990 Bool
991 update_screen_layout (saver_info *si)
992 {
993 monitor **monitors = scan_monitors (si);
994 int count = 0;
995 int good_count = 0;
...
1009 while (monitors[count])
1010 {
1011 if (monitors[count]->sanity == S_SANE)
1012 good_count++;
1013 count++;
1014 }
1015
1016 if (si->ssi_count == 0)
1017 {
1018 si->ssi_count = 10;
1019 si->screens = (saver_screen_info *)
1020 calloc (sizeof(*si->screens), si->ssi_count);
1021 }
1022
1023 if (si->ssi_count <= good_count)
1024 {
1025 si->ssi_count = good_count + 10;
1026 si->screens = (saver_screen_info *)
1027 realloc (si->screens, sizeof(*si->screens) * si->ssi_count);
1028 memset (si->screens + si->nscreens, 0,
https://www.qubes-os.org/news/2021/06/04/qsb-068/
We have just published Qubes Security Bulletin (QSB) 068:
Disconnecting a video output can cause XScreenSaver to crash.
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-068 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-068-2021.txt
Learn about the qubes-secpack, including how to obtain, verify, and read it:
https://www.qubes-os.org/security/pack/
View all past QSBs:
https://www.qubes-os.org/security/bulletins/
---===[ Qubes Security Bulletin 068 ]===---
2021-06-04
Disconnecting a video output can cause XScreenSaver to crash
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:
- xscreensaver 5.45-5
For Qubes 4.1, in dom0:
- xscreensaver 5.45-5
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 this update, the XScreenSaver daemon process must be
restarted in order for the changes to take effect. This can be done by
restarting dom0, logging out of dom0 then logging back in, or issuing
the following command in a dom0 terminal:
xscreensaver-command -exit; xscreensaver &
Summary
========
XScreenSaver is the default screen locker in dom0. It tracks which video
outputs are connected to the system in order to blank them properly. In
some specific hardware configurations, disconnecting an output can cause
XScreenSaver to crash, leaving the screen unlocked.
Impact
=======
On hardware configurations with more than 10 video outputs that can be
disconnected, an attacker with physical access to a screen-locked system
may be able to unlock it by physically disconnecting one or more
outputs, bypassing standard screen lock authentication.
Details
========
On X11, screen locking and blanking is done by creating a window that
obscures the whole screen, which is a standard practice. In
XScreenSaver, each such window is assigned a specific property. When a
video output is disconnected, its corresponding blanking window is
destroyed, and its XScreenSaver-specific property is removed so that it
will not be used by `xscreensaver-command` anymore. This is handled by
the `update_screen_layout()` function in the `driver/screens.c` file:
985 /* Synchronize the contents of si->ssi to the current state of the monitors.
986 Doesn't change anything if nothing has changed; otherwise, alters and
987 reuses existing saver_screen_info structs as much as possible.
988 Returns True if anything changed.
989 */
990 Bool
991 update_screen_layout (saver_info *si)
992 {
993 monitor **monitors = scan_monitors (si);
994 int count = 0;
995 int good_count = 0;
...
1009 while (monitors[count])
1010 {
1011 if (monitors[count]->sanity == S_SANE)
1012 good_count++;
1013 count++;
1014 }
1015
1016 if (si->ssi_count == 0)
1017 {
1018 si->ssi_count = 10;
1019 si->screens = (saver_screen_info *)
1020 calloc (sizeof(*si->screens), si->ssi_count);
1021 }
1022
1023 if (si->ssi_count <= good_count)
1024 {
1025 si->ssi_count = good_count + 10;
1026 si->screens = (saver_screen_info *)
1027 realloc (si->screens, sizeof(*si->screens) * si->ssi_count);
1028 memset (si->screens + si->nscreens, 0,
1029 sizeof(*si->screens) * (si->ssi_count - si->nscreens));
1030 }
...
1092 for (; j < count; j++)
1093 {
1094 saver_screen_info *ssi = &si->screens[j];
1095 if (!ssi->screensaver_window)
1096 continue;
1097 fprintf (stderr, "%s: %d: screen now unused, disabling.\n",
1098 blurb(), j);
1099 /* Undo store_saver_id() so that xscreensaver-command doesn't attempt
1100 to communicate with us through this window. It might make more
1101 sense to destroy the window, but I'm not 100% sure that there are
1102 no outstanding grabs on it that have yet been transferred.
1103 */
1104 XDeleteProperty (si->dpy, ssi->screensaver_window,
1105 XA_SCREENSAVER_VERSION);
1106 }
The initial portion of the function counts how many outputs are defined
(the `count` variable) and how many of them are connected (the
`good_count` variable). Then, the `si->screens` array is allocated or
re-allocated to fit information about connected outputs, with an extra
margin of 10 entries. However, the loop at the end iterates over the
array up to the total number of outputs, not just the ones that are
connected.
If there are 10 or fewer disconnected outputs, this works fine. However,
if there are more than 10, it will access the array beyond its end,
reading unrelated data from memory. It will interpret this data as an
XScreenSaver window ID. If that unrelated data happens to be non-zero
(which is very likely), then the condition at line 1095 will not skip
it, and the `XDeleteProperty` call will operate on that (most likely
invalid) window ID. This, in turn, will cause the XScreenSaver process
to crash, as that's what the error handler is programmed to do (the
`saver_ehandler()` function in the `driver/xscreensaver.c` file).
The error message will look like this:
##############################################################################
xscreensaver: 11:17:59: X Error! PLEASE REPORT THIS BUG.
xscreensaver: 11:17:59: screen 0/0: 0x2ae, 0x0, 0x6600001
xscreensaver: 11:17:59: screen 0/1: 0x2ae, 0x0, 0x0
##############################################################################
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 19 (X_DeleteProperty)
Resource id in failed request: 0x188dba0
Serial number of failed request: 4284
Current serial number in output stream: 4286
#######################################################################
The issue affects only XScreenSaver version 5.45. Versions 5.44 and
older, as well as 6.00, are not affected. The XScreenSaver author was
notified about this issue and decided not to publish an advisory, as the
issue does not affect the most recent version.
The Qubes Security Team has decided to address this issue in Qubes OS by
patching this specific bug rather than immediately upgrading to the 6.00
version. The reason is that XScreenSaver 6.00 is a major update with
major architectural changes. As such, it poses an increased risk of
introducing unrelated problems. However, this decision does not preclude
the possibility of updating to XScreenSaver 6.00 at some point in the
future, independently of this particular security patch.
Credits
========
The issue was reported by Mustafa Kuscu. [3]
References
===========
[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/updating-qubes-os/
[3] https://github.com/QubesOS/qubes-issues/issues/6595
--
The Qubes Security Team
https://www.qubes-os.org/security/
1030 }
...
1092 for (; j < count; j++)
1093 {
1094 saver_screen_info *ssi = &si->screens[j];
1095 if (!ssi->screensaver_window)
1096 continue;
1097 fprintf (stderr, "%s: %d: screen now unused, disabling.\n",
1098 blurb(), j);
1099 /* Undo store_saver_id() so that xscreensaver-command doesn't attempt
1100 to communicate with us through this window. It might make more
1101 sense to destroy the window, but I'm not 100% sure that there are
1102 no outstanding grabs on it that have yet been transferred.
1103 */
1104 XDeleteProperty (si->dpy, ssi->screensaver_window,
1105 XA_SCREENSAVER_VERSION);
1106 }
The initial portion of the function counts how many outputs are defined
(the `count` variable) and how many of them are connected (the
`good_count` variable). Then, the `si->screens` array is allocated or
re-allocated to fit information about connected outputs, with an extra
margin of 10 entries. However, the loop at the end iterates over the
array up to the total number of outputs, not just the ones that are
connected.
If there are 10 or fewer disconnected outputs, this works fine. However,
if there are more than 10, it will access the array beyond its end,
reading unrelated data from memory. It will interpret this data as an
XScreenSaver window ID. If that unrelated data happens to be non-zero
(which is very likely), then the condition at line 1095 will not skip
it, and the `XDeleteProperty` call will operate on that (most likely
invalid) window ID. This, in turn, will cause the XScreenSaver process
to crash, as that's what the error handler is programmed to do (the
`saver_ehandler()` function in the `driver/xscreensaver.c` file).
The error message will look like this:
##############################################################################
xscreensaver: 11:17:59: X Error! PLEASE REPORT THIS BUG.
xscreensaver: 11:17:59: screen 0/0: 0x2ae, 0x0, 0x6600001
xscreensaver: 11:17:59: screen 0/1: 0x2ae, 0x0, 0x0
##############################################################################
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 19 (X_DeleteProperty)
Resource id in failed request: 0x188dba0
Serial number of failed request: 4284
Current serial number in output stream: 4286
#######################################################################
The issue affects only XScreenSaver version 5.45. Versions 5.44 and
older, as well as 6.00, are not affected. The XScreenSaver author was
notified about this issue and decided not to publish an advisory, as the
issue does not affect the most recent version.
The Qubes Security Team has decided to address this issue in Qubes OS by
patching this specific bug rather than immediately upgrading to the 6.00
version. The reason is that XScreenSaver 6.00 is a major update with
major architectural changes. As such, it poses an increased risk of
introducing unrelated problems. However, this decision does not preclude
the possibility of updating to XScreenSaver 6.00 at some point in the
future, independently of this particular security patch.
Credits
========
The issue was reported by Mustafa Kuscu. [3]
References
===========
[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/updating-qubes-os/
[3] https://github.com/QubesOS/qubes-issues/issues/6595
--
The Qubes Security Team
https://www.qubes-os.org/security/
XSAs released on 2021-06-08
https://www.qubes-os.org/news/2021/06/08/xsas-released-on-2021-06-08/
The Xen Project has released one or more new Xen Security Advisories (XSAs).
The security of Qubes OS is affected by one or more of these XSAs.
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-373
XSA-374
XSA-375
XSA-377
Please see QSB-069 (https://www.qubes-os.org/news/2021/06/08/qsb-069/) for the actions users must take in order to protect themselves, as well as further details about these XSAs.
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-372 (affects only Arm systems)
Related links
XSA list (on xen.org) (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/bulletins/)
https://www.qubes-os.org/news/2021/06/08/xsas-released-on-2021-06-08/
The Xen Project has released one or more new Xen Security Advisories (XSAs).
The security of Qubes OS is affected by one or more of these XSAs.
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-373
XSA-374
XSA-375
XSA-377
Please see QSB-069 (https://www.qubes-os.org/news/2021/06/08/qsb-069/) for the actions users must take in order to protect themselves, as well as further details about these XSAs.
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-372 (affects only Arm systems)
Related links
XSA list (on xen.org) (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/bulletins/)
QSB-069: Multiple Xen and Intel issues
https://www.qubes-os.org/news/2021/06/08/qsb-069/
We have just published Qubes Security Bulletin (QSB) 069:
Multiple Xen and Intel issues.
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-069 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-069-2021.txt
Learn about the qubes-secpack, including how to obtain, verify, and read it:
https://www.qubes-os.org/security/pack/
View all past QSBs:
https://www.qubes-os.org/security/bulletins/
---===[ Qubes Security Bulletin 069 ]===---
2021-06-08
Multiple Xen and Intel issues
(XSA-373, XSA-374, XSA-375, XSA-377, INTEL-SA-00442)
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-34
- Linux kernel packages, versions 5.12.9-1 (for users of the "latest"
kernel flavor)
- microcode_ctl package, version 2.1-33.qubes1 (for Intel CPU users)
For Qubes 4.1, in dom0:
- Xen packages, version 4.14.1-5
- Linux kernel packages, versions 5.10.42-1, 5.12.9-1 (for users of
the "latest" kernel flavor)
- microcode_ctl package, version 2.1-33.qubes1 (for Intel CPU users)
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 2021-06-08:
XSA-373 [3] "Inappropriate x86 IOMMU timeout detection / handling":
| IOMMUs process commands issued to them in parallel with the operation
| of the CPU(s) issuing such commands. In the current implementation in
| Xen, asynchronous notification of the completion of such commands is
| not used. Instead, the issuing CPU spin-waits for the completion of
| the most recently issued command(s). Some of these waiting loops try
| to apply a timeout to fail overly-slow commands. The course of action
| upon a perceived timeout actually being detected is inappropriate:
| - on Intel hardware guests which did not originally cause the timeout
| may be marked as crashed,
| - on AMD hardware higher layer callers would not be notified of the
| issue, making them continue as if the IOMMU operation succeeded.
XSA-374 [4] "Guest triggered use-after-free in Linux xen-netback":
| A malicious or buggy network PV frontend can force Linux netback to
| disable the interface and terminate the receive kernel thread
| associated with queue 0 in response to the frontend sending a
| malformed packet.
|
| Such kernel thread termination will lead to a use-after-free in Linux
| netback when the backend is destroyed, as the kernel thread associated
| with queue 0 will have already exited and thus the call to
| kthread_stop will be performed against a stale pointer.
XSA-375 [5] "Speculative Code Store Bypass":
| Modern superscalar processors may employ sophisticated decoding and
| caching of the instruction stream to improve performance. However, a
| consequence is that self-modifying code updates may not take effect
| instantly.
|
| Whatever the architectural guarantees, some CPUs have
| microarchitectural behaviour whereby the stale instruction stream may
| be speculatively decoded and executed.
|
| Speculation of this form can suffer from type confusion in registers,
| and potentially leak data.
https://www.qubes-os.org/news/2021/06/08/qsb-069/
We have just published Qubes Security Bulletin (QSB) 069:
Multiple Xen and Intel issues.
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-069 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-069-2021.txt
Learn about the qubes-secpack, including how to obtain, verify, and read it:
https://www.qubes-os.org/security/pack/
View all past QSBs:
https://www.qubes-os.org/security/bulletins/
---===[ Qubes Security Bulletin 069 ]===---
2021-06-08
Multiple Xen and Intel issues
(XSA-373, XSA-374, XSA-375, XSA-377, INTEL-SA-00442)
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-34
- Linux kernel packages, versions 5.12.9-1 (for users of the "latest"
kernel flavor)
- microcode_ctl package, version 2.1-33.qubes1 (for Intel CPU users)
For Qubes 4.1, in dom0:
- Xen packages, version 4.14.1-5
- Linux kernel packages, versions 5.10.42-1, 5.12.9-1 (for users of
the "latest" kernel flavor)
- microcode_ctl package, version 2.1-33.qubes1 (for Intel CPU users)
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 2021-06-08:
XSA-373 [3] "Inappropriate x86 IOMMU timeout detection / handling":
| IOMMUs process commands issued to them in parallel with the operation
| of the CPU(s) issuing such commands. In the current implementation in
| Xen, asynchronous notification of the completion of such commands is
| not used. Instead, the issuing CPU spin-waits for the completion of
| the most recently issued command(s). Some of these waiting loops try
| to apply a timeout to fail overly-slow commands. The course of action
| upon a perceived timeout actually being detected is inappropriate:
| - on Intel hardware guests which did not originally cause the timeout
| may be marked as crashed,
| - on AMD hardware higher layer callers would not be notified of the
| issue, making them continue as if the IOMMU operation succeeded.
XSA-374 [4] "Guest triggered use-after-free in Linux xen-netback":
| A malicious or buggy network PV frontend can force Linux netback to
| disable the interface and terminate the receive kernel thread
| associated with queue 0 in response to the frontend sending a
| malformed packet.
|
| Such kernel thread termination will lead to a use-after-free in Linux
| netback when the backend is destroyed, as the kernel thread associated
| with queue 0 will have already exited and thus the call to
| kthread_stop will be performed against a stale pointer.
XSA-375 [5] "Speculative Code Store Bypass":
| Modern superscalar processors may employ sophisticated decoding and
| caching of the instruction stream to improve performance. However, a
| consequence is that self-modifying code updates may not take effect
| instantly.
|
| Whatever the architectural guarantees, some CPUs have
| microarchitectural behaviour whereby the stale instruction stream may
| be speculatively decoded and executed.
|
| Speculation of this form can suffer from type confusion in registers,
| and potentially leak data.
XSA-377 [6] "x86: TSX Async Abort protections not restored after S3":
| This issue relates to the TSX Async Abort speculative security
| vulnerability. Please see https://xenbits.xen.org/xsa/advisory-305.html
| for details.
|
| Mitigating TAA by disabling TSX (the default and preferred option)
| requires selecting a non-default setting in MSR_TSX_CTRL. This
| setting isn't restored after S3 suspend.
INTEL-SA-00442 [7] "Intel® VT-d Advisory":
| A potential security vulnerability in some Intel® Virtualization
| Technology for Directed I/0 (VT-d) products may allow escalation of
| privilege. Intel is releasing firmware updates to mitigate this
| potential vulnerability.
Impact
=======
XSA-373:
As the Xen Security Team explains, "A malicious guest may be able to
elevate its privileges to that of the host, cause host or guest Denial
of Service (DoS), or cause information leaks." Only a guest with a PCI
device can leverage this vulnerability, such as `sys-net` or `sys-usb`
in a default Qubes OS configuration.
XSA-374:
A malicious or buggy VM can trigger its network-providing VM to crash.
In a typical installation, the affected network-providing VM would be
`sys-firewall` or `sys-whonix`. Privilege escalation (to the
network-providing VM) and information leaks cannot be ruled out.
The issue affects only Linux kernel version 5.5 and newer. By default,
Qubes OS R4.0 uses Linux 5.4.x and is therefore not affected. However,
if the user has manually installed a newer, affected kernel version
(e.g., using the `kernel-latest-qubes-vm` package), then that
installation is affected.
XSA-375:
As explained by the Xen Security Team, "An attacker might be able to
infer the contents of arbitrary host memory, including memory assigned
to other guests."
XSA-377:
The impact is the same as XSA-305, which we explained in QSB-053 [8]:
| An attacker, which could include a malicious untrusted user process on
| a trusted guest, or an untrusted guest, can sample the content of
| recently-used memory operands and IO Port writes.
|
| This can include data from:
|
| * A previously executing context (process, or guest, or
| hypervisor/toolstack) at the same privilege level.
| * A higher privilege context (kernel, hypervisor, SMM) which
| interrupted the attacker's execution.
|
| Vulnerable data is that on the same physical core as the attacker.
| This includes, when hyper-threading is enabled, adjacent threads.
|
| An attacker cannot use this vulnerability to target specific data.
| An attack would likely require sampling over a period of time and the
| application of statistical methods to reconstruct interesting data.
INTEL-SA-00442:
As explained by Intel, "Incomplete cleanup in some Intel(R) VT-d
products may allow an authenticated user to potentially enable
escalation of privilege via local access."
Only Intel CPUs are affected.
Credits
========
See the original Security Advisories.
References
===========
[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/updating-qubes-os/
[3] https://xenbits.xen.org/xsa/advisory-373.html
[4] https://xenbits.xen.org/xsa/advisory-374.html
[5] https://xenbits.xen.org/xsa/advisory-375.html
[6] https://xenbits.xen.org/xsa/advisory-377.html
[7] https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00442.html
[8] https://www.qubes-os.org/news/2019/11/13/qsb-053/
--
The Qubes Security Team
https://www.qubes-os.org/security/
| This issue relates to the TSX Async Abort speculative security
| vulnerability. Please see https://xenbits.xen.org/xsa/advisory-305.html
| for details.
|
| Mitigating TAA by disabling TSX (the default and preferred option)
| requires selecting a non-default setting in MSR_TSX_CTRL. This
| setting isn't restored after S3 suspend.
INTEL-SA-00442 [7] "Intel® VT-d Advisory":
| A potential security vulnerability in some Intel® Virtualization
| Technology for Directed I/0 (VT-d) products may allow escalation of
| privilege. Intel is releasing firmware updates to mitigate this
| potential vulnerability.
Impact
=======
XSA-373:
As the Xen Security Team explains, "A malicious guest may be able to
elevate its privileges to that of the host, cause host or guest Denial
of Service (DoS), or cause information leaks." Only a guest with a PCI
device can leverage this vulnerability, such as `sys-net` or `sys-usb`
in a default Qubes OS configuration.
XSA-374:
A malicious or buggy VM can trigger its network-providing VM to crash.
In a typical installation, the affected network-providing VM would be
`sys-firewall` or `sys-whonix`. Privilege escalation (to the
network-providing VM) and information leaks cannot be ruled out.
The issue affects only Linux kernel version 5.5 and newer. By default,
Qubes OS R4.0 uses Linux 5.4.x and is therefore not affected. However,
if the user has manually installed a newer, affected kernel version
(e.g., using the `kernel-latest-qubes-vm` package), then that
installation is affected.
XSA-375:
As explained by the Xen Security Team, "An attacker might be able to
infer the contents of arbitrary host memory, including memory assigned
to other guests."
XSA-377:
The impact is the same as XSA-305, which we explained in QSB-053 [8]:
| An attacker, which could include a malicious untrusted user process on
| a trusted guest, or an untrusted guest, can sample the content of
| recently-used memory operands and IO Port writes.
|
| This can include data from:
|
| * A previously executing context (process, or guest, or
| hypervisor/toolstack) at the same privilege level.
| * A higher privilege context (kernel, hypervisor, SMM) which
| interrupted the attacker's execution.
|
| Vulnerable data is that on the same physical core as the attacker.
| This includes, when hyper-threading is enabled, adjacent threads.
|
| An attacker cannot use this vulnerability to target specific data.
| An attack would likely require sampling over a period of time and the
| application of statistical methods to reconstruct interesting data.
INTEL-SA-00442:
As explained by Intel, "Incomplete cleanup in some Intel(R) VT-d
products may allow an authenticated user to potentially enable
escalation of privilege via local access."
Only Intel CPUs are affected.
Credits
========
See the original Security Advisories.
References
===========
[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/updating-qubes-os/
[3] https://xenbits.xen.org/xsa/advisory-373.html
[4] https://xenbits.xen.org/xsa/advisory-374.html
[5] https://xenbits.xen.org/xsa/advisory-375.html
[6] https://xenbits.xen.org/xsa/advisory-377.html
[7] https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00442.html
[8] https://www.qubes-os.org/news/2019/11/13/qsb-053/
--
The Qubes Security Team
https://www.qubes-os.org/security/
Qubes OS Project now accepting donations in Monero!
https://www.qubes-os.org/news/2021/06/11/qubes-os-project-now-accepting-donations-in-monero/
We are pleased to announce that the Qubes OS Project is now accepting donations (https://www.qubes-os.org/donate/) in the privacy-oriented cryptocurrency Monero (XMR) (https://www.getmonero.org/) at the following address:
46PrVgXBdD4cps3SVkHoCDZvMfFdG5q4ej5DYKpuKpTnjiL7pv6KGv7dPh4DPijCGqTbxLDPqZJkobd9SttMiauoP1CQU4y
We have received an increasing number of requests for Monero as a donation method over the past few years. We are proud that Qubes is the OS of choice for so many privacy-conscious individuals, and we are pleased to be able to offer a more private donation method for those users to show their support.
As with our Bitcoin donation address, you can verify the authenticity of the Monero donation address via the Qubes Security Pack (https://www.qubes-os.org/security/pack/) in the fund (https://github.com/QubesOS/qubes-secpack/tree/master/fund) directory. We also provide detailed instructions for verifying the digital signatures (https://www.qubes-os.org/security/pack/#how-to-obtain-verify-and-read).
As with all other donations, your Monero donations will directly fund the Qubes OS Project (https://www.qubes-os.org/donate/#how-is-my-donation-used). Since Qubes is free and open-source software, we do not earn any revenue by selling it. Instead, we rely on your financial support. If you rely on Qubes for secure computing in your work or personal life or see the value in our efforts, we would greatly appreciate your donation. Thank you!
https://www.qubes-os.org/news/2021/06/11/qubes-os-project-now-accepting-donations-in-monero/
We are pleased to announce that the Qubes OS Project is now accepting donations (https://www.qubes-os.org/donate/) in the privacy-oriented cryptocurrency Monero (XMR) (https://www.getmonero.org/) at the following address:
46PrVgXBdD4cps3SVkHoCDZvMfFdG5q4ej5DYKpuKpTnjiL7pv6KGv7dPh4DPijCGqTbxLDPqZJkobd9SttMiauoP1CQU4y
We have received an increasing number of requests for Monero as a donation method over the past few years. We are proud that Qubes is the OS of choice for so many privacy-conscious individuals, and we are pleased to be able to offer a more private donation method for those users to show their support.
As with our Bitcoin donation address, you can verify the authenticity of the Monero donation address via the Qubes Security Pack (https://www.qubes-os.org/security/pack/) in the fund (https://github.com/QubesOS/qubes-secpack/tree/master/fund) directory. We also provide detailed instructions for verifying the digital signatures (https://www.qubes-os.org/security/pack/#how-to-obtain-verify-and-read).
As with all other donations, your Monero donations will directly fund the Qubes OS Project (https://www.qubes-os.org/donate/#how-is-my-donation-used). Since Qubes is free and open-source software, we do not earn any revenue by selling it. Instead, we rely on your financial support. If you rely on Qubes for secure computing in your work or personal life or see the value in our efforts, we would greatly appreciate your donation. Thank you!
Qubes Canary 027
https://www.qubes-os.org/news/2021/06/14/canary-027/
We have published Qubes Canary 027. 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 027 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-027-2021.txt
Learn about the qubes-secpack, including how to obtain, verify, and
read it:
https://www.qubes-os.org/security/pack/
View all past canaries:
https://www.qubes-os.org/security/canaries/
---===[ Qubes Canary 027 ]===---
Statements
-----------
The Qubes core developers who have digitally signed this file [1]
state the following:
1. The date of issue of this canary is June 12, 2021.
2. There have been 69 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
two weeks of September 2021. 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 news feeds quoted below (Proof of freshness) 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
-------------------
Sat, 12 Jun 2021 00:25:17 +0000
Source: DER SPIEGEL - International (https://www.spiegel.de/international/index.rss)
The Telegram Billionaire and His Dark Empire
Biometric Data: How I Lost Control Over My Own Face
France’s War in West Africa: “People Collected Severed Arms, Legs and Heads”
An Interview with Håvard Grip, Chief Pilot of Ingenuity, Nasa's Mars Helicopter
A Boost for the CDU: German Conservatives Back on Track as General Election Approaches
Source: NYT > World News (https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
Cameras Off: G7 Summit Heralds the Return of In-Person Diplomacy
Question Looms Over This Year’s Group of 7: Where Are All the Protesters?
China’s Censorship Widens to Hong Kong’s Vaunted Film Industry, With Global Implications
A Fragile Israeli Coalition, With Some Underlying Glue
G7 Live Updates: A Return to Face-to-Face Diplomacy
Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
G7: Boris Johnson kicks off summit with plea to tackle inequality
Israel ex-top spy reveals Mossad operations against Iran
Ethiopia conflict: 33,000 Tigray children risk death from hunger - UN
Teen who filmed George Floyd's murder given journalism award
Oregon lawmaker ousted for allowing rioters into State Capitol
Source: Blockchain.info
0000000000000000000b56dd6255d8c3d53b6363cfb4459114de601ee2ddc96c
Footnotes
----------
https://www.qubes-os.org/news/2021/06/14/canary-027/
We have published Qubes Canary 027. 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 027 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-027-2021.txt
Learn about the qubes-secpack, including how to obtain, verify, and
read it:
https://www.qubes-os.org/security/pack/
View all past canaries:
https://www.qubes-os.org/security/canaries/
---===[ Qubes Canary 027 ]===---
Statements
-----------
The Qubes core developers who have digitally signed this file [1]
state the following:
1. The date of issue of this canary is June 12, 2021.
2. There have been 69 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
two weeks of September 2021. 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 news feeds quoted below (Proof of freshness) 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
-------------------
Sat, 12 Jun 2021 00:25:17 +0000
Source: DER SPIEGEL - International (https://www.spiegel.de/international/index.rss)
The Telegram Billionaire and His Dark Empire
Biometric Data: How I Lost Control Over My Own Face
France’s War in West Africa: “People Collected Severed Arms, Legs and Heads”
An Interview with Håvard Grip, Chief Pilot of Ingenuity, Nasa's Mars Helicopter
A Boost for the CDU: German Conservatives Back on Track as General Election Approaches
Source: NYT > World News (https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
Cameras Off: G7 Summit Heralds the Return of In-Person Diplomacy
Question Looms Over This Year’s Group of 7: Where Are All the Protesters?
China’s Censorship Widens to Hong Kong’s Vaunted Film Industry, With Global Implications
A Fragile Israeli Coalition, With Some Underlying Glue
G7 Live Updates: A Return to Face-to-Face Diplomacy
Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
G7: Boris Johnson kicks off summit with plea to tackle inequality
Israel ex-top spy reveals Mossad operations against Iran
Ethiopia conflict: 33,000 Tigray children risk death from hunger - UN
Teen who filmed George Floyd's murder given journalism award
Oregon lawmaker ousted for allowing rioters into State Capitol
Source: Blockchain.info
0000000000000000000b56dd6255d8c3d53b6363cfb4459114de601ee2ddc96c
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!
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!