XSAs released on 2022-07-05
https://www.qubes-os.org/news/2022/07/05/xsas-released-on-2022-07-05/
The Xen Project has released one or more Xen Security Advisories (XSAs).
The security of Qubes OS is affected.
Therefore, user action is required.
XSAs that affect the security of Qubes OS (user action required)
The following XSAs do affect the security of Qubes OS:
XSA-403
XSA-405
Please see QSB-082 for the actions users must take in order to
protect themselves, as well as further details about these XSAs:
https://www.qubes-os.org/news/2022/07/05/qsb-082/
XSAs that do not affect the security of Qubes OS (no user action required)
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
XSA-406 (ARM architecture only)
Related links
Xen XSA list: https://xenbits.xen.org/xsa/
Qubes XSA tracker: https://www.qubes-os.org/security/xsa/
Qubes security pack (qubes-secpack): https://www.qubes-os.org/security/pack/
Qubes security bulletins (QSBs): https://www.qubes-os.org/security/qsb/
https://www.qubes-os.org/news/2022/07/05/xsas-released-on-2022-07-05/
The Xen Project has released one or more Xen Security Advisories (XSAs).
The security of Qubes OS is affected.
Therefore, user action is required.
XSAs that affect the security of Qubes OS (user action required)
The following XSAs do affect the security of Qubes OS:
XSA-403
XSA-405
Please see QSB-082 for the actions users must take in order to
protect themselves, as well as further details about these XSAs:
https://www.qubes-os.org/news/2022/07/05/qsb-082/
XSAs that do not affect the security of Qubes OS (no user action required)
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
XSA-406 (ARM architecture only)
Related links
Xen XSA list: https://xenbits.xen.org/xsa/
Qubes XSA tracker: https://www.qubes-os.org/security/xsa/
Qubes security pack (qubes-secpack): https://www.qubes-os.org/security/pack/
Qubes security bulletins (QSBs): https://www.qubes-os.org/security/qsb/
QSB-082: Memory management issues in PV frontend drivers
https://www.qubes-os.org/news/2022/07/05/qsb-082/
We have just published Qubes Security Bulletin (QSB) 082:
Memory management issues in PV frontend drivers.
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack (qubes-secpack).
View QSB-082 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-082-2022.txt
In addition, you may wish to:
Get the qubes-secpack: https://www.qubes-os.org/security/pack/
View all past QSBs: https://www.qubes-os.org/security/qsb/
View the XSA Tracker: https://www.qubes-os.org/security/xsa/
---===[ Qubes Security Bulletin 082 ]===---
2022-07-05
Memory management issues in PV frontend drivers
User action required
---------------------
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.0, in dom0:
- Xen packages, version 4.8.5-42
- Linux kernel packages (kernel*-qubes-vm), versions 5.4.203, 5.8.9,
4.19.250
For Qubes 4.1, in dom0:
- Xen packages, version 4.14.5-5
- Linux kernel packages (kernel*-qubes-vm), versions 5.15.52, 5.8.9,
5.10.128
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]
Dom0 must be restarted afterward in order for the updates to take
effect.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen and Linux binaries.
Summary
--------
The following security advisories were published on 2022-07-05:
XSA-403 [3] "Linux disk/nic frontends data leaks":
| Linux Block and Network PV device frontends don't zero memory regions
| before sharing them with the backend. Additionally the granularity of
| the grant table doesn't allow sharing less than a 4K page, leading to
| unrelated data residing in the same 4K page as data shared with a
| backend being accessible by such backend.
|
| An untrusted backend can access data not intended to be shared. If
| such mappings are made with write permissions the backend could also
| cause malfunctions and/or crashes to consumers of contiguous data in
| the shared pages.
XSA-405 [4] "The PV network backend may cause Linux netfront to use
freed SKBs":
| While adding logic to support XDP (eXpress Data Path), a code label
| was moved in a way allowing for SKBs having references (pointers)
| retained for further processing to nevertheless be freed.
|
| A misbehaving or malicious backend may cause a Denial of Service (DoS)
| in the guest. Information leaks or privilege escalation cannot be
| ruled out.
Impact
-------
These vulnerabilities, if exploited, could allow a malicious VM that
serves as a network or a block backend to leak data from its frontend.
The ability to execute code in the frontend cannot be ruled out.
In the default Qubes OS configuration, this means that sys-net could
attack sys-firewall, and sys-firewall could attack qubes connected to
it. Furthermore, a qube to which a block device is assigned from an
untrusted backend qube can be attacked by that backend. (For example,
sys-usb could attack qubes to which a USB drive is attached as a block
device.) Qubes that do not have any NetVM set and to which no block
devices are assigned are not affected.
Credits
--------
See the original Xen Security Advisory.
References
-----------
[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/how-to-update/
[3] https://xenbits.xen.org/xsa/advisory-403.html
[4] https://xenbits.xen.org/xsa/advisory-405.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
https://www.qubes-os.org/news/2022/07/05/qsb-082/
We have just published Qubes Security Bulletin (QSB) 082:
Memory management issues in PV frontend drivers.
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack (qubes-secpack).
View QSB-082 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-082-2022.txt
In addition, you may wish to:
Get the qubes-secpack: https://www.qubes-os.org/security/pack/
View all past QSBs: https://www.qubes-os.org/security/qsb/
View the XSA Tracker: https://www.qubes-os.org/security/xsa/
---===[ Qubes Security Bulletin 082 ]===---
2022-07-05
Memory management issues in PV frontend drivers
User action required
---------------------
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.0, in dom0:
- Xen packages, version 4.8.5-42
- Linux kernel packages (kernel*-qubes-vm), versions 5.4.203, 5.8.9,
4.19.250
For Qubes 4.1, in dom0:
- Xen packages, version 4.14.5-5
- Linux kernel packages (kernel*-qubes-vm), versions 5.15.52, 5.8.9,
5.10.128
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]
Dom0 must be restarted afterward in order for the updates to take
effect.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen and Linux binaries.
Summary
--------
The following security advisories were published on 2022-07-05:
XSA-403 [3] "Linux disk/nic frontends data leaks":
| Linux Block and Network PV device frontends don't zero memory regions
| before sharing them with the backend. Additionally the granularity of
| the grant table doesn't allow sharing less than a 4K page, leading to
| unrelated data residing in the same 4K page as data shared with a
| backend being accessible by such backend.
|
| An untrusted backend can access data not intended to be shared. If
| such mappings are made with write permissions the backend could also
| cause malfunctions and/or crashes to consumers of contiguous data in
| the shared pages.
XSA-405 [4] "The PV network backend may cause Linux netfront to use
freed SKBs":
| While adding logic to support XDP (eXpress Data Path), a code label
| was moved in a way allowing for SKBs having references (pointers)
| retained for further processing to nevertheless be freed.
|
| A misbehaving or malicious backend may cause a Denial of Service (DoS)
| in the guest. Information leaks or privilege escalation cannot be
| ruled out.
Impact
-------
These vulnerabilities, if exploited, could allow a malicious VM that
serves as a network or a block backend to leak data from its frontend.
The ability to execute code in the frontend cannot be ruled out.
In the default Qubes OS configuration, this means that sys-net could
attack sys-firewall, and sys-firewall could attack qubes connected to
it. Furthermore, a qube to which a block device is assigned from an
untrusted backend qube can be attacked by that backend. (For example,
sys-usb could attack qubes to which a USB drive is attached as a block
device.) Qubes that do not have any NetVM set and to which no block
devices are assigned are not affected.
Credits
--------
See the original Xen Security Advisory.
References
-----------
[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/how-to-update/
[3] https://xenbits.xen.org/xsa/advisory-403.html
[4] https://xenbits.xen.org/xsa/advisory-405.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
XSAs released on 2022-07-12
https://www.qubes-os.org/news/2022/07/13/xsas-released-on-2022-07-12/
The Xen Project has released one or more Xen Security Advisories (XSAs).
The security of Qubes OS is affected.
Therefore, user action is required.
XSAs that affect the security of Qubes OS (user action required)
The following XSAs do affect the security of Qubes OS:
XSA-407
Please see QSB-083 for the actions users must take in order to
protect themselves, as well as further details about these XSAs:
https://www.qubes-os.org/news/2022/07/13/qsb-083/
XSAs that do not affect the security of Qubes OS (no user action required)
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
(none)
Related links
Xen XSA list: https://xenbits.xen.org/xsa/
Qubes XSA tracker: https://www.qubes-os.org/security/xsa/
Qubes security pack (qubes-secpack): https://www.qubes-os.org/security/pack/
Qubes security bulletins (QSBs): https://www.qubes-os.org/security/qsb/
https://www.qubes-os.org/news/2022/07/13/xsas-released-on-2022-07-12/
The Xen Project has released one or more Xen Security Advisories (XSAs).
The security of Qubes OS is affected.
Therefore, user action is required.
XSAs that affect the security of Qubes OS (user action required)
The following XSAs do affect the security of Qubes OS:
XSA-407
Please see QSB-083 for the actions users must take in order to
protect themselves, as well as further details about these XSAs:
https://www.qubes-os.org/news/2022/07/13/qsb-083/
XSAs that do not affect the security of Qubes OS (no user action required)
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
(none)
Related links
Xen XSA list: https://xenbits.xen.org/xsa/
Qubes XSA tracker: https://www.qubes-os.org/security/xsa/
Qubes security pack (qubes-secpack): https://www.qubes-os.org/security/pack/
Qubes security bulletins (QSBs): https://www.qubes-os.org/security/qsb/
QSB-083: Retbleed: Arbitrary speculative code execution with return instructions (XSA-407)
https://www.qubes-os.org/news/2022/07/13/qsb-083/
We have just published Qubes Security Bulletin (QSB) 083: Retbleed:
Arbitrary speculative code execution with return instructions (XSA-407).
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack
(qubes-secpack).
View QSB-083 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-083-2022.txt
In addition, you may wish to:
Get the qubes-secpack: https://www.qubes-os.org/security/pack/
View all past QSBs: https://www.qubes-os.org/security/qsb/
View the XSA Tracker: https://www.qubes-os.org/security/xsa/
---===[ Qubes Security Bulletin 083 ]===---
2022-07-12
Retbleed
Arbitrary speculative code execution
with return instructions (XSA-407)
User action required
---------------------
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.0, in dom0:
- Xen packages, version 4.8.5-43
For Qubes 4.1, in dom0:
- Xen packages, version 4.14.5-6
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]
Dom0 must be restarted afterward in order for the updates to take
effect.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.
Summary
--------
On 2022-07-12, the Xen Project published XSA-407, "Retbleed -
arbitrary speculative code execution with return instructions" [3]:
| Researchers at ETH Zurich have discovered Retbleed, allowing for
| arbitrary speculative execution in a victim context.
|
| For more details, see:
| https://comsec.ethz.ch/retbleed
|
| ETH Zurich have allocated CVE-2022-29900 for AMD and CVE-2022-29901 for
| Intel.
|
| Despite the similar preconditions, these are very different
| microarchitectural behaviours between vendors.
|
| On AMD CPUs, Retbleed is one specific instance of a more general
| microarchitectural behaviour called Branch Type Confusion. AMD have
| assigned CVE-2022-23816 (Retbleed) and CVE-2022-23825 (Branch Type
| Confusion).
|
| For more details, see:
| https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1037
|
| On Intel CPUs, Retbleed is not a new vulnerability; it is only
| applicable to software which did not follow Intel's original
| Spectre-v2 guidance. Intel are using the ETH Zurich allocated
| CVE-2022-29901.
|
| For more details, see:
| https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00702.html
| https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/return-stack-buffer-underflow.html
|
| ARM have indicated existing guidance on Spectre-v2 is sufficient.
Impact
-------
This is yet another speculative execution issue, which allows an
attacker to infer content of memory they shouldn't have access to. This
includes one VM extracting secrets from another. Any VM can perform this
attack on an affected hardware.
AMD systems based on Zen 1 - Zen 2 microarchitectures are affected.
Specifically those are AMD Ryzen processors with model names 1xxx - 4xxx
and some 5xxxU [4]. Zen 3 microarchitecture (AMD Ryzen 5xxx or newer)
are not affected.
Pre-existing Xen mitigations on Intel machines are effective to prevent
this issue, so Intel systems are not affected.
Credits
--------
See the original Xen Security Advisory.
References
-----------
[1] https://www.qubes-os.org/doc/testing/
https://www.qubes-os.org/news/2022/07/13/qsb-083/
We have just published Qubes Security Bulletin (QSB) 083: Retbleed:
Arbitrary speculative code execution with return instructions (XSA-407).
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack
(qubes-secpack).
View QSB-083 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-083-2022.txt
In addition, you may wish to:
Get the qubes-secpack: https://www.qubes-os.org/security/pack/
View all past QSBs: https://www.qubes-os.org/security/qsb/
View the XSA Tracker: https://www.qubes-os.org/security/xsa/
---===[ Qubes Security Bulletin 083 ]===---
2022-07-12
Retbleed
Arbitrary speculative code execution
with return instructions (XSA-407)
User action required
---------------------
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.0, in dom0:
- Xen packages, version 4.8.5-43
For Qubes 4.1, in dom0:
- Xen packages, version 4.14.5-6
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]
Dom0 must be restarted afterward in order for the updates to take
effect.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.
Summary
--------
On 2022-07-12, the Xen Project published XSA-407, "Retbleed -
arbitrary speculative code execution with return instructions" [3]:
| Researchers at ETH Zurich have discovered Retbleed, allowing for
| arbitrary speculative execution in a victim context.
|
| For more details, see:
| https://comsec.ethz.ch/retbleed
|
| ETH Zurich have allocated CVE-2022-29900 for AMD and CVE-2022-29901 for
| Intel.
|
| Despite the similar preconditions, these are very different
| microarchitectural behaviours between vendors.
|
| On AMD CPUs, Retbleed is one specific instance of a more general
| microarchitectural behaviour called Branch Type Confusion. AMD have
| assigned CVE-2022-23816 (Retbleed) and CVE-2022-23825 (Branch Type
| Confusion).
|
| For more details, see:
| https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1037
|
| On Intel CPUs, Retbleed is not a new vulnerability; it is only
| applicable to software which did not follow Intel's original
| Spectre-v2 guidance. Intel are using the ETH Zurich allocated
| CVE-2022-29901.
|
| For more details, see:
| https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00702.html
| https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/return-stack-buffer-underflow.html
|
| ARM have indicated existing guidance on Spectre-v2 is sufficient.
Impact
-------
This is yet another speculative execution issue, which allows an
attacker to infer content of memory they shouldn't have access to. This
includes one VM extracting secrets from another. Any VM can perform this
attack on an affected hardware.
AMD systems based on Zen 1 - Zen 2 microarchitectures are affected.
Specifically those are AMD Ryzen processors with model names 1xxx - 4xxx
and some 5xxxU [4]. Zen 3 microarchitecture (AMD Ryzen 5xxx or newer)
are not affected.
Pre-existing Xen mitigations on Intel machines are effective to prevent
this issue, so Intel systems are not affected.
Credits
--------
See the original Xen Security Advisory.
References
-----------
[1] https://www.qubes-os.org/doc/testing/
👍1
[2] https://www.qubes-os.org/doc/how-to-update/
[3] https://xenbits.xen.org/xsa/advisory-407.html
[4] Unlike other 5xxxU models, Ryzen 3 5300U, Ryzen 5 5500U and
Ryzen 7 5700U are Zen 2, not Zen 3. See
https://en.wikipedia.org/wiki/Zen2
https://en.wikipedia.org/wiki/Zen3
--
The Qubes Security Team
https://www.qubes-os.org/security/
[3] https://xenbits.xen.org/xsa/advisory-407.html
[4] Unlike other 5xxxU models, Ryzen 3 5300U, Ryzen 5 5500U and
Ryzen 7 5700U are Zen 2, not Zen 3. See
https://en.wikipedia.org/wiki/Zen2
https://en.wikipedia.org/wiki/Zen3
--
The Qubes Security Team
https://www.qubes-os.org/security/
👍2
Qubes OS 4.1.1 has been released!
https://www.qubes-os.org/news/2022/07/18/qubes-4-1-1/
We’re pleased to announce the stable release of Qubes 4.1.1! This release aims to consolidate all the security patches, bug fixes, and upstream template OS upgrades that have occurred since the initial Qubes 4.1.0 release in February. Our goal is to provide a secure and convenient way for users to install (or reinstall) the latest stable Qubes release with an up-to-date ISO.
Qubes 4.1.1 is available on the downloads (https://www.qubes-os.org/downloads/) page.
Reminder: Qubes 4.0 approaching end-of-life
As we recently announced (https://www.qubes-os.org/news/2022/07/04/qubes-os-4-0-eol-on-2022-08-04/), Qubes 4.0 reaches EOL (end-of-life) on 2022-08-04. If you’re using Qubes 4.0 and have been waiting for an opportunity to upgrade to Qubes 4.1 via the clean reinstallation (https://www.qubes-os.org/doc/upgrade/4.1/#clean-installation) method, we strongly recommend using this Qubes 4.1.1 release to do so, as this is the last Qubes 4.1 patch release before Qubes 4.0 reaches EOL.
Existing Qubes 4.1.0 and release candidate users
If you are already using Qubes 4.1.0 or Qubes 4.1.1-rc1 (https://www.qubes-os.org/news/2022/06/27/qubes-4-1-1-rc1/), then you should simply update normally (https://www.qubes-os.org/doc/how-to-update/) (which includes upgrading any EOL templates (https://www.qubes-os.org/doc/how-to-update/#upgrading-to-avoid-eol) you might have) in order to make your system essentially equivalent to this stable Qubes 4.1.1 release. No special action is required on your part.
What’s new in Qubes 4.1.1?
Qubes 4.1.1 includes numerous updates over the initial 4.1.0 release, in particular:
All 4.1.0 dom0 updates to date
Fedora 36 template (upgraded from Fedora 34)
Linux kernel 5.15 (upgraded from 5.10)
What is a patch release?
The Qubes OS Project uses the semantic versioning (https://semver.org/) standard. Version numbers are written as ... Hence, we refer to releases that increment the third number as “patch releases.” A patch release does not designate a separate, new major or minor release of Qubes OS. Rather, it designates its respective major or minor release (in this case, 4.1.0) inclusive of all updates up to a certain point. Installing Qubes 4.1.0 and fully updating it results in essentially the same system as installing Qubes 4.1.1. You can learn more about how Qubes release versioning works in the version scheme (https://www.qubes-os.org/doc/version-scheme/) documentation.
https://www.qubes-os.org/news/2022/07/18/qubes-4-1-1/
We’re pleased to announce the stable release of Qubes 4.1.1! This release aims to consolidate all the security patches, bug fixes, and upstream template OS upgrades that have occurred since the initial Qubes 4.1.0 release in February. Our goal is to provide a secure and convenient way for users to install (or reinstall) the latest stable Qubes release with an up-to-date ISO.
Qubes 4.1.1 is available on the downloads (https://www.qubes-os.org/downloads/) page.
Reminder: Qubes 4.0 approaching end-of-life
As we recently announced (https://www.qubes-os.org/news/2022/07/04/qubes-os-4-0-eol-on-2022-08-04/), Qubes 4.0 reaches EOL (end-of-life) on 2022-08-04. If you’re using Qubes 4.0 and have been waiting for an opportunity to upgrade to Qubes 4.1 via the clean reinstallation (https://www.qubes-os.org/doc/upgrade/4.1/#clean-installation) method, we strongly recommend using this Qubes 4.1.1 release to do so, as this is the last Qubes 4.1 patch release before Qubes 4.0 reaches EOL.
Existing Qubes 4.1.0 and release candidate users
If you are already using Qubes 4.1.0 or Qubes 4.1.1-rc1 (https://www.qubes-os.org/news/2022/06/27/qubes-4-1-1-rc1/), then you should simply update normally (https://www.qubes-os.org/doc/how-to-update/) (which includes upgrading any EOL templates (https://www.qubes-os.org/doc/how-to-update/#upgrading-to-avoid-eol) you might have) in order to make your system essentially equivalent to this stable Qubes 4.1.1 release. No special action is required on your part.
What’s new in Qubes 4.1.1?
Qubes 4.1.1 includes numerous updates over the initial 4.1.0 release, in particular:
All 4.1.0 dom0 updates to date
Fedora 36 template (upgraded from Fedora 34)
Linux kernel 5.15 (upgraded from 5.10)
What is a patch release?
The Qubes OS Project uses the semantic versioning (https://semver.org/) standard. Version numbers are written as ... Hence, we refer to releases that increment the third number as “patch releases.” A patch release does not designate a separate, new major or minor release of Qubes OS. Rather, it designates its respective major or minor release (in this case, 4.1.0) inclusive of all updates up to a certain point. Installing Qubes 4.1.0 and fully updating it results in essentially the same system as installing Qubes 4.1.1. You can learn more about how Qubes release versioning works in the version scheme (https://www.qubes-os.org/doc/version-scheme/) documentation.
👍3
XSAs released on 2022-07-26
https://www.qubes-os.org/news/2022/07/26/xsas-released-on-2022-07-26/
The Xen Project has released one or more Xen Security Advisories (XSAs).
The security of Qubes OS is not affected.
Therefore, no user action is required.
XSAs that affect the security of Qubes OS (user action required)
The following XSAs do affect the security of Qubes OS:
(none)
XSAs that do not affect the security of Qubes OS (no user action required)
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
XSA-408 (shadow mode is disabled at build time)
Related links
Xen XSA list: https://xenbits.xen.org/xsa/
Qubes XSA tracker: https://www.qubes-os.org/security/xsa/
Qubes security pack (qubes-secpack): https://www.qubes-os.org/security/pack/
Qubes security bulletins (QSBs): https://www.qubes-os.org/security/qsb/
https://www.qubes-os.org/news/2022/07/26/xsas-released-on-2022-07-26/
The Xen Project has released one or more Xen Security Advisories (XSAs).
The security of Qubes OS is not affected.
Therefore, no user action is required.
XSAs that affect the security of Qubes OS (user action required)
The following XSAs do affect the security of Qubes OS:
(none)
XSAs that do not affect the security of Qubes OS (no user action required)
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
XSA-408 (shadow mode is disabled at build time)
Related links
Xen XSA list: https://xenbits.xen.org/xsa/
Qubes XSA tracker: https://www.qubes-os.org/security/xsa/
Qubes security pack (qubes-secpack): https://www.qubes-os.org/security/pack/
Qubes security bulletins (QSBs): https://www.qubes-os.org/security/qsb/
Qubes OS Summit 2022: September 9-11 in Berlin
https://www.qubes-os.org/news/2022/07/29/qubes-os-summit-2022/
In conjunction with 3mdeb (https://3mdeb.com/), the fourth edition of our Qubes OS Summit will be held live this year from September 9 to 11 in Berlin, Germany! For more information about this event, including the CFP (which is open until August 29), please see: https://qubesos.3mdeb.com (https://qubesos.3mdeb.com/)
https://www.qubes-os.org/news/2022/07/29/qubes-os-summit-2022/
In conjunction with 3mdeb (https://3mdeb.com/), the fourth edition of our Qubes OS Summit will be held live this year from September 9 to 11 in Berlin, Germany! For more information about this event, including the CFP (which is open until August 29), please see: https://qubesos.3mdeb.com (https://qubesos.3mdeb.com/)
👍3
Qubes OS 4.0 has reached EOL
https://www.qubes-os.org/news/2022/08/04/qubes-4-0-has-reached-eol/
As previously announced (https://www.qubes-os.org/news/2022/07/04/qubes-os-4-0-eol-on-2022-08-04/), all releases in the Qubes 4.0 series (which includes the most recent 4.0.4 patch release) have officially reached EOL (end-of-life) as of today, 2022-08-04. We strongly urge all remaining Qubes 4.0 users to upgrade to Qubes 4.1 (https://www.qubes-os.org/doc/upgrade/4.1/) immediately. As always, the support statuses of all Qubes OS and template releases are available on the supported releases (https://www.qubes-os.org/doc/supported-releases/) page, and the latest release is available to download on the downloads (https://www.qubes-os.org/downloads/) page.
What should I do?
If you’re already using Qubes 4.1, then no action is required on your part. This announcement concerns only the 4.0 minor release series.
If you’re still using Qubes 4.0 (including the most recent 4.0.4 patch release), then you should upgrade to 4.1 immediately. You have two options:
Perform a clean reinstallation using the latest stable Qubes 4.1.1 ISO (https://www.qubes-os.org/downloads/#qubes-release-4-1-1), which was published on 2022-07-18 (https://www.qubes-os.org/news/2022/07/18/qubes-4-1-1/).
Perform an in-place upgrade (https://www.qubes-os.org/doc/upgrade/4.1/#in-place-upgrade) to 4.1.
Both of these options are covered in further detail in the Qubes 4.0 to 4.1 upgrade guide (https://www.qubes-os.org/doc/upgrade/4.1/). If you need help, please consult our help and support (https://www.qubes-os.org/support/) page.
https://www.qubes-os.org/news/2022/08/04/qubes-4-0-has-reached-eol/
As previously announced (https://www.qubes-os.org/news/2022/07/04/qubes-os-4-0-eol-on-2022-08-04/), all releases in the Qubes 4.0 series (which includes the most recent 4.0.4 patch release) have officially reached EOL (end-of-life) as of today, 2022-08-04. We strongly urge all remaining Qubes 4.0 users to upgrade to Qubes 4.1 (https://www.qubes-os.org/doc/upgrade/4.1/) immediately. As always, the support statuses of all Qubes OS and template releases are available on the supported releases (https://www.qubes-os.org/doc/supported-releases/) page, and the latest release is available to download on the downloads (https://www.qubes-os.org/downloads/) page.
What should I do?
If you’re already using Qubes 4.1, then no action is required on your part. This announcement concerns only the 4.0 minor release series.
If you’re still using Qubes 4.0 (including the most recent 4.0.4 patch release), then you should upgrade to 4.1 immediately. You have two options:
Perform a clean reinstallation using the latest stable Qubes 4.1.1 ISO (https://www.qubes-os.org/downloads/#qubes-release-4-1-1), which was published on 2022-07-18 (https://www.qubes-os.org/news/2022/07/18/qubes-4-1-1/).
Perform an in-place upgrade (https://www.qubes-os.org/doc/upgrade/4.1/#in-place-upgrade) to 4.1.
Both of these options are covered in further detail in the Qubes 4.0 to 4.1 upgrade guide (https://www.qubes-os.org/doc/upgrade/4.1/). If you need help, please consult our help and support (https://www.qubes-os.org/support/) page.
👍7❤1
QSB-084: Split GPG: GnuPG file denoscriptor confusion and file existence leak
https://www.qubes-os.org/news/2022/08/06/qsb-084/
We have just published Qubes Security Bulletin (QSB) 084: Split GPG: GnuPG file denoscriptor confusion and file existence leak (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-084-2022.txt). The text of this QSB is reproduced below. This QSB and its accompanying signatures will always be available in the Qubes Security Pack (qubes-secpack) (https://www.qubes-os.org/security/pack/). More information about QSBs, including a complete historical list, is available here (https://www.qubes-os.org/security/qsb/).
---===[ Qubes Security Bulletin 084 ]===---
2022-08-06
Split GPG: GnuPG file denoscriptor confusion and file existence leak
User action required
---------------------
Users must install the following specific packages in order to address the
issues discussed in this bulletin:
For Qubes 4.1, in templates and standalones:
- qubes-gpg-split 2.0.63
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]
Summary
--------
Split GPG [3] is designed to isolate private keys from the application
using them in order to protect them from being extracted and to allow
the user to retain control over when they are used. This isolation is
implemented by forwarding calls from an application in a frontend qube,
where `qubes-gpg-client` is executed, to an instance of `gpg` in a
backend qube that holds the private keys, all while allowing only
specific `gpg` options. This option filtering mechanism is designed to
reject options like `--export-secret-keys` that might leak private keys
to the frontend qube. However, it has been discovered that certain
combinations of options allow the frontend qube to access data in the
backend qube in unintended ways.
Two separate types of attack were discovered:
1. Interaction via `--command-fd` allows the frontend qube to check for
the existence of arbitrary files in the backend qube, including files
unrelated to GnuPG.
2. Using the same `--*-fd` option several times allows the frontend qube
to redirect GnuPG input and output to the wrong file denoscriptor. This
can be used to:
- Corrupt files used by GnuPG. (We have confirmed this only in the
case of `trustdb`, but other files cannot be ruled out.)
- Issue arbitrary commands to `gpg-agent`, which can be used to
perform actions like generating new secret keys and deleting
existing keys.
- Set various environment variables for the `pinentry` process,
thereby providing an indirect avenue of attack against this
process.
However, our testing did not reveal any way to exploit this
vulnerability in order to read `gpg-agent`'s responses, which means
that certain actions, such as extracting secret keys, should not be
possible.
Impact
-------
An attacker controlling a Split GPG frontend qube can check for the
existence of arbitrary files in a backend qube, corrupt the `trustdb`
file in a backend qube, issue arbitrary commands to `gpg-agent` in a
backend qube, and issue arbitrary commands to a smart card daemon in a
backend qube. While this vulnerability can be exploited in order to
generate and delete keys in the backend qube (or on a smart card
attached to the backend qube), it is unlikely that it can be used to
exfiltrate private keys out of the backend qube (or off of a smart card
attached to the backend qube). If this vulnerability were to be chained
with a hypothetical vulnerability in `gpg-agent`, `scdaemon`, or
`pinentry` (or in one of the libraries they use), then arbitrary code
execution could be possible.
Credits
--------
This issue was discovered by Demi Marie Obenour.
References
https://www.qubes-os.org/news/2022/08/06/qsb-084/
We have just published Qubes Security Bulletin (QSB) 084: Split GPG: GnuPG file denoscriptor confusion and file existence leak (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-084-2022.txt). The text of this QSB is reproduced below. This QSB and its accompanying signatures will always be available in the Qubes Security Pack (qubes-secpack) (https://www.qubes-os.org/security/pack/). More information about QSBs, including a complete historical list, is available here (https://www.qubes-os.org/security/qsb/).
---===[ Qubes Security Bulletin 084 ]===---
2022-08-06
Split GPG: GnuPG file denoscriptor confusion and file existence leak
User action required
---------------------
Users must install the following specific packages in order to address the
issues discussed in this bulletin:
For Qubes 4.1, in templates and standalones:
- qubes-gpg-split 2.0.63
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]
Summary
--------
Split GPG [3] is designed to isolate private keys from the application
using them in order to protect them from being extracted and to allow
the user to retain control over when they are used. This isolation is
implemented by forwarding calls from an application in a frontend qube,
where `qubes-gpg-client` is executed, to an instance of `gpg` in a
backend qube that holds the private keys, all while allowing only
specific `gpg` options. This option filtering mechanism is designed to
reject options like `--export-secret-keys` that might leak private keys
to the frontend qube. However, it has been discovered that certain
combinations of options allow the frontend qube to access data in the
backend qube in unintended ways.
Two separate types of attack were discovered:
1. Interaction via `--command-fd` allows the frontend qube to check for
the existence of arbitrary files in the backend qube, including files
unrelated to GnuPG.
2. Using the same `--*-fd` option several times allows the frontend qube
to redirect GnuPG input and output to the wrong file denoscriptor. This
can be used to:
- Corrupt files used by GnuPG. (We have confirmed this only in the
case of `trustdb`, but other files cannot be ruled out.)
- Issue arbitrary commands to `gpg-agent`, which can be used to
perform actions like generating new secret keys and deleting
existing keys.
- Set various environment variables for the `pinentry` process,
thereby providing an indirect avenue of attack against this
process.
However, our testing did not reveal any way to exploit this
vulnerability in order to read `gpg-agent`'s responses, which means
that certain actions, such as extracting secret keys, should not be
possible.
Impact
-------
An attacker controlling a Split GPG frontend qube can check for the
existence of arbitrary files in a backend qube, corrupt the `trustdb`
file in a backend qube, issue arbitrary commands to `gpg-agent` in a
backend qube, and issue arbitrary commands to a smart card daemon in a
backend qube. While this vulnerability can be exploited in order to
generate and delete keys in the backend qube (or on a smart card
attached to the backend qube), it is unlikely that it can be used to
exfiltrate private keys out of the backend qube (or off of a smart card
attached to the backend qube). If this vulnerability were to be chained
with a hypothetical vulnerability in `gpg-agent`, `scdaemon`, or
`pinentry` (or in one of the libraries they use), then arbitrary code
execution could be possible.
Credits
--------
This issue was discovered by Demi Marie Obenour.
References
❤6👍3
-----------
[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/how-to-update/
[3] https://www.qubes-os.org/doc/split-gpg/
--
The Qubes Security Team
https://www.qubes-os.org/security/
[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/how-to-update/
[3] https://www.qubes-os.org/doc/split-gpg/
--
The Qubes Security Team
https://www.qubes-os.org/security/
👍1💩1💯1
Qubes OS Summit: History from organizer's perspective
https://www.qubes-os.org/news/2022/09/07/qubes-os-summit-history/
Editor’s note: This is a guest article by Michał Żygowski from
3mdeb (https://3mdeb.com/) about the history of Qubes OS Summits.
Thanks for sharing with us today, Michał!
Introduction
The next Qubes OS Summit 2022 (https://www.qubes-os.org/news/2022/07/29/qubes-os-summit-2022/)
edition is upcoming. This year it will be held in Berlin from September 9th to
11th in hybrid format, in person and live-streamed for remote access. More
details here (https://qubesos.3mdeb.com/). Don’t miss the event and more
importantly how it started. In the article the history and organizer’s
perspective of the event will be described.
How did all of this start?
In May 2019 3mdeb funded Linux training for its employees, having no idea who
the instructor will be. At some point, it occurred that the mysterious
instructor will be none other than Marek Marczykowski-Górecki, the same person
who leads the Qubes OS project. As huge fans of Qubes OS and its approach to
security, as also fans of Joanna Rutkowska security research in the area of
firmware and computer architecture, we were delighted to meet him in person in
our office in Gdańsk, Poland. The time has come when the idea of a short event
focused on firmware impact on Qubes OS security has been born. We asked Marek
if he has some spare time to discuss firmware impacts on Qubes OS security and
he liked the idea. The event has been called humorously a “minisummit”. That is
how the first Qubes OS summit started, one day, in a small conference room,
with a tiny group of people passionate about firmware and system security,
nothing outrageous (in the meaning of scale). One may still read what topics
have been discussed
here (https://blog.3mdeb.com/2019/2019-08-07-qubes-os-and-3mdeb-minisummit/).
The main focus was on Qubes OS certification and ecosystem as well as the
firmware-related security technologies support like TPM 2.0 and DRTM (Anti Evil
Maid). The event helped 3mdeb realize how to get involved in Qubes OS project
and help to improve it with our expertise.
The past of Qubes OS Summits
Everyone enjoyed that one particular day so much, that we decided to repeat the
event next year. The environment we created together, bending and crossing the
event horizon between firmware and operating system, was something wonderful,
both to hear and to speak about. The potential we saw in that kind of event, to
bring various companies together and collaborate on the project on every
possible layer, has been pushing us forward to enlarge the community and
introduce more open-source firmware to the Qubes OS world.
Another May has come, the year 2020, the pandemic dominated the world. But it
didn’t stop us from holding the event again! It even gave us a better
opportunity to attract and gather more people virtually to attend the event.
Thanks to our 3mdeb colleagues, who set up the live recording and streaming of
the whole Qubes OS 2020 Summit, it is possible to see and listen to the talks
given by Qubes OS and 3mdeb experts on
Youtube (https://www.youtube.com/playlist?list=PLuISieMwVBpIwhPXcuYKtS50CHQOvt_BO)
over and over again. From 3mdeb side we continued firmware-related topics, for
example first time Qubes OS Anti Evil Maid on AMD platform. It was quite a
challenge for us because we have organized such a virtual event for the first
time. Fortunately, everything went smoothly and finished with success after 4
sessions 2.5 hours long.
In August 2021 we held yet another Qubes OS Summit together with the Qubes OS
team, still virtually, unfortunately. However, this year brought more speakers
from other companies and projects, which we were very happy about. There were 2
sessions almost 4 hours each and one may watch the talks at
Youtube (https://www.youtube.com/playlist?list=PLuISieMwVBpIoLQzpYeZnkupURheXky6r).
https://www.qubes-os.org/news/2022/09/07/qubes-os-summit-history/
Editor’s note: This is a guest article by Michał Żygowski from
3mdeb (https://3mdeb.com/) about the history of Qubes OS Summits.
Thanks for sharing with us today, Michał!
Introduction
The next Qubes OS Summit 2022 (https://www.qubes-os.org/news/2022/07/29/qubes-os-summit-2022/)
edition is upcoming. This year it will be held in Berlin from September 9th to
11th in hybrid format, in person and live-streamed for remote access. More
details here (https://qubesos.3mdeb.com/). Don’t miss the event and more
importantly how it started. In the article the history and organizer’s
perspective of the event will be described.
How did all of this start?
In May 2019 3mdeb funded Linux training for its employees, having no idea who
the instructor will be. At some point, it occurred that the mysterious
instructor will be none other than Marek Marczykowski-Górecki, the same person
who leads the Qubes OS project. As huge fans of Qubes OS and its approach to
security, as also fans of Joanna Rutkowska security research in the area of
firmware and computer architecture, we were delighted to meet him in person in
our office in Gdańsk, Poland. The time has come when the idea of a short event
focused on firmware impact on Qubes OS security has been born. We asked Marek
if he has some spare time to discuss firmware impacts on Qubes OS security and
he liked the idea. The event has been called humorously a “minisummit”. That is
how the first Qubes OS summit started, one day, in a small conference room,
with a tiny group of people passionate about firmware and system security,
nothing outrageous (in the meaning of scale). One may still read what topics
have been discussed
here (https://blog.3mdeb.com/2019/2019-08-07-qubes-os-and-3mdeb-minisummit/).
The main focus was on Qubes OS certification and ecosystem as well as the
firmware-related security technologies support like TPM 2.0 and DRTM (Anti Evil
Maid). The event helped 3mdeb realize how to get involved in Qubes OS project
and help to improve it with our expertise.
The past of Qubes OS Summits
Everyone enjoyed that one particular day so much, that we decided to repeat the
event next year. The environment we created together, bending and crossing the
event horizon between firmware and operating system, was something wonderful,
both to hear and to speak about. The potential we saw in that kind of event, to
bring various companies together and collaborate on the project on every
possible layer, has been pushing us forward to enlarge the community and
introduce more open-source firmware to the Qubes OS world.
Another May has come, the year 2020, the pandemic dominated the world. But it
didn’t stop us from holding the event again! It even gave us a better
opportunity to attract and gather more people virtually to attend the event.
Thanks to our 3mdeb colleagues, who set up the live recording and streaming of
the whole Qubes OS 2020 Summit, it is possible to see and listen to the talks
given by Qubes OS and 3mdeb experts on
Youtube (https://www.youtube.com/playlist?list=PLuISieMwVBpIwhPXcuYKtS50CHQOvt_BO)
over and over again. From 3mdeb side we continued firmware-related topics, for
example first time Qubes OS Anti Evil Maid on AMD platform. It was quite a
challenge for us because we have organized such a virtual event for the first
time. Fortunately, everything went smoothly and finished with success after 4
sessions 2.5 hours long.
In August 2021 we held yet another Qubes OS Summit together with the Qubes OS
team, still virtually, unfortunately. However, this year brought more speakers
from other companies and projects, which we were very happy about. There were 2
sessions almost 4 hours each and one may watch the talks at
Youtube (https://www.youtube.com/playlist?list=PLuISieMwVBpIoLQzpYeZnkupURheXky6r).
This time, the 3mdeb’s stage belonged to Piotr Król (CEO of 3mdeb) who presented
his adventures using Qubes OS as an everyday device, talking about USB camera
and cryptocurrency wallets. Of course firmware-related topics could not be
missing and Piotr also showed continuation of his previous year’s efforts of
securing the VMs with SRTM and Secure Boot.
The future of Qubes OS Summits
Finally, the time has come when we may meet together in person, after three
years! The Qubes OS Summit 2022 is fast approaching, with only a few days left
before the start of the event in Berlin. As it is no longer held only virtually
(but still possible to attend remotely for those who can’t be with us in
person) the organization is more complicated, both from the logistics and
presentations side. Every year we try our best to dig into hardcore security
topics on the verge of firmware and operating systems. All this time we have
been gradually building plans and ideas, and getting closer and closer to the
goal of improving the security of Qubes OS, especially in areas we feel best
at, i.e. SRTM and DRTM (AEM). In the upcoming event, we have prepared a few
interesting projects and ideas around Anti Evil Maid support and open-source
firmware on modern hardware.
Here (https://cfp.3mdeb.com/qubes-os-summit-2022/schedule/#) you may find the
full schedule. Among others we welcome the following speakers:
Wessel Klein Snakenborg from Novacustom with a story of open-source on modern
laptops as a candidate to Qubes OS certification
Brent Cowing from Protectli talking about security of his small form factor
computers also running open-source firmware
Jan Suhr from Nitrokey talking about how enterprise requirements tied to
Windows can be met with Qubes OS
Arthur Rasmusson from Arc Compute talking about GPU virtualization and its
possible benefits to Qubes oS
Puck Meerburg from Spectrum OS telling about the power of Wayland for GUI
isolation and how it benefits systems like Qubes OS or Spectrum OS
And everyone from 3mdeb, Qubes OS team, and others
We hope that the event and community around it and the Qubes OS project will
grow in the future, bringing reasonable trustworthiness and collaboration for
everybody. Definitely, 3mdeb will try its best to co-organize the event in the
upcoming years.
Summary
By a mere coincidence, meeting Marek Marczykowski-Górecki gave birth to a
fascinating series of Qubes OS Summits and led us to this day.
Together with Invisible Things Lab we (3mdeb) are very proud to be the
co-organizers of the 4th edition of the event. Looking forward to seeing each
other again, but most important to talk and share knowledge and passion with
everyone again after a long time.
Many thanks to the Qubes OS team for holding up the tradition with us. See you
all in Berlin!
his adventures using Qubes OS as an everyday device, talking about USB camera
and cryptocurrency wallets. Of course firmware-related topics could not be
missing and Piotr also showed continuation of his previous year’s efforts of
securing the VMs with SRTM and Secure Boot.
The future of Qubes OS Summits
Finally, the time has come when we may meet together in person, after three
years! The Qubes OS Summit 2022 is fast approaching, with only a few days left
before the start of the event in Berlin. As it is no longer held only virtually
(but still possible to attend remotely for those who can’t be with us in
person) the organization is more complicated, both from the logistics and
presentations side. Every year we try our best to dig into hardcore security
topics on the verge of firmware and operating systems. All this time we have
been gradually building plans and ideas, and getting closer and closer to the
goal of improving the security of Qubes OS, especially in areas we feel best
at, i.e. SRTM and DRTM (AEM). In the upcoming event, we have prepared a few
interesting projects and ideas around Anti Evil Maid support and open-source
firmware on modern hardware.
Here (https://cfp.3mdeb.com/qubes-os-summit-2022/schedule/#) you may find the
full schedule. Among others we welcome the following speakers:
Wessel Klein Snakenborg from Novacustom with a story of open-source on modern
laptops as a candidate to Qubes OS certification
Brent Cowing from Protectli talking about security of his small form factor
computers also running open-source firmware
Jan Suhr from Nitrokey talking about how enterprise requirements tied to
Windows can be met with Qubes OS
Arthur Rasmusson from Arc Compute talking about GPU virtualization and its
possible benefits to Qubes oS
Puck Meerburg from Spectrum OS telling about the power of Wayland for GUI
isolation and how it benefits systems like Qubes OS or Spectrum OS
And everyone from 3mdeb, Qubes OS team, and others
We hope that the event and community around it and the Qubes OS project will
grow in the future, bringing reasonable trustworthiness and collaboration for
everybody. Definitely, 3mdeb will try its best to co-organize the event in the
upcoming years.
Summary
By a mere coincidence, meeting Marek Marczykowski-Górecki gave birth to a
fascinating series of Qubes OS Summits and led us to this day.
Together with Invisible Things Lab we (3mdeb) are very proud to be the
co-organizers of the 4th edition of the event. Looking forward to seeing each
other again, but most important to talk and share knowledge and passion with
everyone again after a long time.
Many thanks to the Qubes OS team for holding up the tradition with us. See you
all in Berlin!
👍1🔥1
Qubes Canary 032
https://www.qubes-os.org/news/2022/09/14/canary-032/
We have published Qubes Canary 032. 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 032 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-032-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 032 ]===---
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 September 13, 2022.
2. There have been 84 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 December 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
----------------------
We plan to create a new Release Signing Key (RSK) [3] for Qubes OS 4.2.
Normally, we have only one RSK for each major release. However, for the
4.2 release, we will be using Qubes Builder version 2, which is a
complete rewrite of the Qubes Builder. Out of an abundance of caution,
we would like to isolate the build processes of the current stable 4.1
release and the upcoming 4.2 release from each other at the
cryptographic level in order to minimize the risk of a vulnerability in
one affecting the other. We are including this notice as a canary
special announcement since introducing a new RSK for a minor release is
an exception to our usual RSK management policy.
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, 13 Sep 2022 02:47:47 +0000
Source: DER SPIEGEL - International (https://www.spiegel.de/international/index.rss)
Poland's Prime Minister on Ukraine War and Energy Crisis
Habeck's Meltdown: Nuclear Energy Standby Proposal Has Germany's Greens Seeing Red
European Commissioner Gentiloni: "The Coming Winter Could Be One of the Worst in History"
Russian Meddling in the Balkans: "Over and Over, Putin Says Kosovo, Kosovo, Kosovo!"
Laos and the New Silk Road: The Train to Dependence on China
Source: NYT > World News (https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
Ukraine’s Sudden Gains Prompt New Questions for Commanders
Russian Critics Speak Out, Prompted by Ukraine Losses
https://www.qubes-os.org/news/2022/09/14/canary-032/
We have published Qubes Canary 032. 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 032 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-032-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 032 ]===---
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 September 13, 2022.
2. There have been 84 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 December 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
----------------------
We plan to create a new Release Signing Key (RSK) [3] for Qubes OS 4.2.
Normally, we have only one RSK for each major release. However, for the
4.2 release, we will be using Qubes Builder version 2, which is a
complete rewrite of the Qubes Builder. Out of an abundance of caution,
we would like to isolate the build processes of the current stable 4.1
release and the upcoming 4.2 release from each other at the
cryptographic level in order to minimize the risk of a vulnerability in
one affecting the other. We are including this notice as a canary
special announcement since introducing a new RSK for a minor release is
an exception to our usual RSK management policy.
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, 13 Sep 2022 02:47:47 +0000
Source: DER SPIEGEL - International (https://www.spiegel.de/international/index.rss)
Poland's Prime Minister on Ukraine War and Energy Crisis
Habeck's Meltdown: Nuclear Energy Standby Proposal Has Germany's Greens Seeing Red
European Commissioner Gentiloni: "The Coming Winter Could Be One of the Worst in History"
Russian Meddling in the Balkans: "Over and Over, Putin Says Kosovo, Kosovo, Kosovo!"
Laos and the New Silk Road: The Train to Dependence on China
Source: NYT > World News (https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
Ukraine’s Sudden Gains Prompt New Questions for Commanders
Russian Critics Speak Out, Prompted by Ukraine Losses
👍3
King Charles Pays Tribute to Queen Elizabeth on a Day Steeped in Tradition
Oppressive Blackouts Force Lebanese to Change Rhythm of Life
Ukraine Claims More Ground in Northeast and South
Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
Ukraine war: We retook 6,000 sq km from Russia in September, says Zelensky
Ukraine war: What will Russia's losses mean for Putin?
Ukraine war: A successful surprise attack - but danger still looms
Sweden election: Result could take days as vote too close to call
Taoiseach: Queen's death 'reminder to nurture UK-Ireland relations'
Source: Blockchain.info
00000000000000000002fb0e59c723277069b5389aa2df4b8ff6dc8d80da6ad4
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/
[3] https://www.qubes-os.org/security/verifying-signatures/#how-to-import-and-authenticate-release-signing-keys
--
The Qubes Security Team
https://www.qubes-os.org/security/
Oppressive Blackouts Force Lebanese to Change Rhythm of Life
Ukraine Claims More Ground in Northeast and South
Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
Ukraine war: We retook 6,000 sq km from Russia in September, says Zelensky
Ukraine war: What will Russia's losses mean for Putin?
Ukraine war: A successful surprise attack - but danger still looms
Sweden election: Result could take days as vote too close to call
Taoiseach: Queen's death 'reminder to nurture UK-Ireland relations'
Source: Blockchain.info
00000000000000000002fb0e59c723277069b5389aa2df4b8ff6dc8d80da6ad4
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/
[3] https://www.qubes-os.org/security/verifying-signatures/#how-to-import-and-authenticate-release-signing-keys
--
The Qubes Security Team
https://www.qubes-os.org/security/
❤2🖕1
The Qubes OS Project is now accepting donations on Ethereum!
https://www.qubes-os.org/news/2022/09/29/qubes-os-project-now-accepting-donations-on-ethereum/
We are pleased to announce that the Qubes OS Project is now accepting donations (https://www.qubes-os.org/donate/) on Ethereum (https://ethereum.org/) (Mainnet) at the following address:
0xDaa04647e8ecb616801F9bE89712771F6D291a0C
Warning: This Gnosis Safe (https://gnosis-safe.io/) Ethereum address supports ether (ETH) and all assets that fully comply with the ERC-20 (https://ethereum.org/en/developers/docs/standards/tokens/erc-20/) standard (e.g., USDT, USDC, and DAI), but only on Ethereum Mainnet (https://ethereum.org/en/developers/docs/networks/#ethereum-mainnet). Please do not send assets on any other network to this address, or else your donation may be lost. For example, please do not send assets on any Ethereum Layer 2 solution (e.g., Arbitrum, Optimism) or any sidechain (e.g., Polygon, xDai) to this address.
We have recently observed an increase in demand for an Ethereum donation option, both for ETH itself and for stablecoins like USDT, USDC, and DAI. As the largest smart-contract blockchain, largest proof-of-stake blockchain, and second-largest cryptocurrency by market capitalization, the Ethereum network and its native currency ETH are natural additions to our growing list of donation methods. Moreover, this new option allows users to donate any token they choose (including non-stablecoins!) so long as (1) the token fully complies with the ERC-20 standard and (2) the transaction is done on Ethereum Mainnet (as opposed to a Layer 2 solution or a sidechain). Please double-check that both of these conditions hold before sending anything to our Ethereum address, or else your donation may be lost!
As with our bitcoin (BTC) and monero (XMR) donation addresses, you can verify the authenticity of our Ethereum 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-and-authenticate).
As with all other donations, your donations on Ethereum 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/2022/09/29/qubes-os-project-now-accepting-donations-on-ethereum/
We are pleased to announce that the Qubes OS Project is now accepting donations (https://www.qubes-os.org/donate/) on Ethereum (https://ethereum.org/) (Mainnet) at the following address:
0xDaa04647e8ecb616801F9bE89712771F6D291a0C
Warning: This Gnosis Safe (https://gnosis-safe.io/) Ethereum address supports ether (ETH) and all assets that fully comply with the ERC-20 (https://ethereum.org/en/developers/docs/standards/tokens/erc-20/) standard (e.g., USDT, USDC, and DAI), but only on Ethereum Mainnet (https://ethereum.org/en/developers/docs/networks/#ethereum-mainnet). Please do not send assets on any other network to this address, or else your donation may be lost. For example, please do not send assets on any Ethereum Layer 2 solution (e.g., Arbitrum, Optimism) or any sidechain (e.g., Polygon, xDai) to this address.
We have recently observed an increase in demand for an Ethereum donation option, both for ETH itself and for stablecoins like USDT, USDC, and DAI. As the largest smart-contract blockchain, largest proof-of-stake blockchain, and second-largest cryptocurrency by market capitalization, the Ethereum network and its native currency ETH are natural additions to our growing list of donation methods. Moreover, this new option allows users to donate any token they choose (including non-stablecoins!) so long as (1) the token fully complies with the ERC-20 standard and (2) the transaction is done on Ethereum Mainnet (as opposed to a Layer 2 solution or a sidechain). Please double-check that both of these conditions hold before sending anything to our Ethereum address, or else your donation may be lost!
As with our bitcoin (BTC) and monero (XMR) donation addresses, you can verify the authenticity of our Ethereum 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-and-authenticate).
As with all other donations, your donations on Ethereum 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!
👍1
XSAs released on 2022-10-11
https://www.qubes-os.org/news/2022/10/11/xsas-released-on-2022-10-11/
The Xen Project has released one or more Xen Security Advisories (XSAs).
The security of Qubes OS is not affected.
Therefore, no user action is required.
XSAs that affect the security of Qubes OS (user action required)
The following XSAs do affect the security of Qubes OS:
(none)
XSAs that do not affect the security of Qubes OS (no user action required)
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
XSA-409 (ARM architecture only)
XSA-410 (denial-of-service only)
XSA-411 (denial-of-service only; gnttab v2 is unused in Qubes OS)
XSA-413 (denial-of-service only; XAPI is unused in Qubes OS)
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/10/11/xsas-released-on-2022-10-11/
The Xen Project has released one or more Xen Security Advisories (XSAs).
The security of Qubes OS is not affected.
Therefore, no user action is required.
XSAs that affect the security of Qubes OS (user action required)
The following XSAs do affect the security of Qubes OS:
(none)
XSAs that do not affect the security of Qubes OS (no user action required)
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
XSA-409 (ARM architecture only)
XSA-410 (denial-of-service only)
XSA-411 (denial-of-service only; gnttab v2 is unused in Qubes OS)
XSA-413 (denial-of-service only; XAPI is unused in Qubes OS)
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/
👍2👎1
New user guide: How to organize your qubes
https://www.qubes-os.org/news/2022/10/28/how-to-organize-your-qubes/
The following is a new how-to guide (https://www.qubes-os.org/doc/#how-to-guides) for users who are
starting out with Qubes OS. You can also find it in our documentation (https://www.qubes-os.org/doc/)
under How to organize your qubes (https://www.qubes-os.org/doc/how-to-organize-your-qubes/).
When people first learn about Qubes OS, their initial reaction is often, “Wow,
this looks really cool! But… what can I actually do with it?” It’s not
always obvious which qubes you should create, what you should do in each one,
and whether your organizational ideas makes sense from a security or usage
perspective.
Each qube is essentially a secure compartment, and you can create as many of
them as you like and connect them to each other in various ways. They’re sort
of like Lego blocks in the sense that you can build whatever you want. But if
you’re not sure what to build, then this open-ended freedom can be daunting.
It’s a bit like staring at a blank document when you first sit down to write
something. The possibilities are endless, and you may not know where to begin!
The truth is that no one else can tell you exactly how you should organize
your qubes, as there is no single correct answer to that question. It depends
on your needs, desires, and preferences. Every user’s optimal setup will be
different. However, what we can do is provide you with some illustrative
examples based on questionnaires and interviews with Qubes users and
developers, as well as our own personal experience and insight from using Qubes
over the years. You may be able to adapt some of these examples to fit your own
unique situation. More importantly, walking you through the rationale behind
various decisions will teach you how to apply the same thought process to your
own organizational decisions. Let’s begin!
Alice, the software developer
Alice is a freelance dev who works on several projects for different clients
simultaneously. The projects have varying requirements and often different
build environments. She has a separate set of qubes for each project. She keeps
them organized by coming up with a naming scheme, such as:
clientA-code
clientA-build
clientA-test
clientA-prod
projectB-code
projectB-build-test
projectB-prod
...
This helps her keep groups of qubes organized in a set. Some of her qubes are
based on Debian templates (https://www.qubes-os.org/doc/templates/debian/), while others are based on
Fedora templates (https://www.qubes-os.org/doc/templates/fedora/). The reason for this is that some
software packages are more readily available in one distribution as opposed to
the other. Alice’s setup looks like this:
https://www.qubes-os.org/news/2022/10/28/how-to-organize-your-qubes/
The following is a new how-to guide (https://www.qubes-os.org/doc/#how-to-guides) for users who are
starting out with Qubes OS. You can also find it in our documentation (https://www.qubes-os.org/doc/)
under How to organize your qubes (https://www.qubes-os.org/doc/how-to-organize-your-qubes/).
When people first learn about Qubes OS, their initial reaction is often, “Wow,
this looks really cool! But… what can I actually do with it?” It’s not
always obvious which qubes you should create, what you should do in each one,
and whether your organizational ideas makes sense from a security or usage
perspective.
Each qube is essentially a secure compartment, and you can create as many of
them as you like and connect them to each other in various ways. They’re sort
of like Lego blocks in the sense that you can build whatever you want. But if
you’re not sure what to build, then this open-ended freedom can be daunting.
It’s a bit like staring at a blank document when you first sit down to write
something. The possibilities are endless, and you may not know where to begin!
The truth is that no one else can tell you exactly how you should organize
your qubes, as there is no single correct answer to that question. It depends
on your needs, desires, and preferences. Every user’s optimal setup will be
different. However, what we can do is provide you with some illustrative
examples based on questionnaires and interviews with Qubes users and
developers, as well as our own personal experience and insight from using Qubes
over the years. You may be able to adapt some of these examples to fit your own
unique situation. More importantly, walking you through the rationale behind
various decisions will teach you how to apply the same thought process to your
own organizational decisions. Let’s begin!
Alice, the software developer
Alice is a freelance dev who works on several projects for different clients
simultaneously. The projects have varying requirements and often different
build environments. She has a separate set of qubes for each project. She keeps
them organized by coming up with a naming scheme, such as:
clientA-code
clientA-build
clientA-test
clientA-prod
projectB-code
projectB-build-test
projectB-prod
...
This helps her keep groups of qubes organized in a set. Some of her qubes are
based on Debian templates (https://www.qubes-os.org/doc/templates/debian/), while others are based on
Fedora templates (https://www.qubes-os.org/doc/templates/fedora/). The reason for this is that some
software packages are more readily available in one distribution as opposed to
the other. Alice’s setup looks like this:
👍1