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!
The Qubes Forum is moving to a new home!
https://www.qubes-os.org/news/2021/06/15/qubes-forum-moving-to-new-home/
Since the Qubes Forum (https://qubes-os.discourse.group/) first launched (https://www.qubes-os.org/news/2020/08/20/new-discussion-forum-for-qubes-os-users/) over nine months ago, it’s been far more popular than we anticipated! While this has been a pleasant surprise, one consequence is that we’ve outgrown the free hosting for open source projects (https://blog.discourse.org/2018/11/free-hosting-for-open-source-v2/) that Discourse (https://www.discourse.org/) has generously been providing to us. As a result, we must switch to a new paid host. We’re also taking this opportunity to move the forum to our official domain!
In order to ensure a smooth and orderly transition, we’re announcing these changes well in advance. The move is scheduled for 2021-07-01 (July 1), which is a little over two weeks from the date of this announcement. We hope this gives everyone sufficient time to prepare so that the transition doesn’t come as a surprise.
Once the move has been completed, the forum’s new address will be:
https://forum.qubes-os.org (https://forum.qubes-os.org/)
Again, this link will not take you to a fully functional forum until the migration on 2021-07-01.
We hope that this new address better reflects the forum’s official nature (https://www.qubes-os.org/support/#forum), as well as being intuitive and easy to remember. :)
Rest assured, we’ll be taking a full backup of the current forum and copying everything over to the new forum, including all categories, topics, posts, private messages, and even likes! After the migration, the old forum will automatically redirect visitors to the new address for at least a few months.
We’d like to thank you, the Qubes community, for making the forum a success. Your passion and engagement helps the project grow as we continue our journey together. On a personal note, I’d also like to give special recognition to a few individuals whose efforts made this forum possible to begin with and continue to sustain it. Thank you, deeplow (https://www.qubes-os.org/team/#deeplow), Simon Newton (https://www.qubes-os.org/team/#simon-newton), and Michael Carbone (https://www.qubes-os.org/team/#michael-carbone) for your tireless work. We wouldn’t have this forum without you!
Important note for U2F two-factor authentication users
If you’re using a U2F key for two-factor authentication (2FA) on the forum, you’ll have to use a backup code in order to log in on the new domain. Alternatively, you can disable two-factor authentication before the migration and re-enable it afterward. Please make sure you have either saved a copy of your backup codes or disabled 2FA before 2021-07-01, or you will be locked out of your forum account!
https://www.qubes-os.org/news/2021/06/15/qubes-forum-moving-to-new-home/
Since the Qubes Forum (https://qubes-os.discourse.group/) first launched (https://www.qubes-os.org/news/2020/08/20/new-discussion-forum-for-qubes-os-users/) over nine months ago, it’s been far more popular than we anticipated! While this has been a pleasant surprise, one consequence is that we’ve outgrown the free hosting for open source projects (https://blog.discourse.org/2018/11/free-hosting-for-open-source-v2/) that Discourse (https://www.discourse.org/) has generously been providing to us. As a result, we must switch to a new paid host. We’re also taking this opportunity to move the forum to our official domain!
In order to ensure a smooth and orderly transition, we’re announcing these changes well in advance. The move is scheduled for 2021-07-01 (July 1), which is a little over two weeks from the date of this announcement. We hope this gives everyone sufficient time to prepare so that the transition doesn’t come as a surprise.
Once the move has been completed, the forum’s new address will be:
https://forum.qubes-os.org (https://forum.qubes-os.org/)
Again, this link will not take you to a fully functional forum until the migration on 2021-07-01.
We hope that this new address better reflects the forum’s official nature (https://www.qubes-os.org/support/#forum), as well as being intuitive and easy to remember. :)
Rest assured, we’ll be taking a full backup of the current forum and copying everything over to the new forum, including all categories, topics, posts, private messages, and even likes! After the migration, the old forum will automatically redirect visitors to the new address for at least a few months.
We’d like to thank you, the Qubes community, for making the forum a success. Your passion and engagement helps the project grow as we continue our journey together. On a personal note, I’d also like to give special recognition to a few individuals whose efforts made this forum possible to begin with and continue to sustain it. Thank you, deeplow (https://www.qubes-os.org/team/#deeplow), Simon Newton (https://www.qubes-os.org/team/#simon-newton), and Michael Carbone (https://www.qubes-os.org/team/#michael-carbone) for your tireless work. We wouldn’t have this forum without you!
Important note for U2F two-factor authentication users
If you’re using a U2F key for two-factor authentication (2FA) on the forum, you’ll have to use a backup code in order to log in on the new domain. Alternatively, you can disable two-factor authentication before the migration and re-enable it afterward. Please make sure you have either saved a copy of your backup codes or disabled 2FA before 2021-07-01, or you will be locked out of your forum account!
Qubes virtual mini-summit 2021!
https://www.qubes-os.org/news/2021/07/30/minisummit-agenda/
We are pleased to announce the third annual Qubes mini-summit co-hosted by
3mdeb (https://3mdeb.com/) and the Qubes OS Project. (For prior year
summaries, agendas, and slides, see
2019 (https://3mdeb.com/events/#Qubes-OS-and-3mdeb-minisummit) and
2020 (https://3mdeb.com/events/#Qubes-OS-and-3mdeb-minisummit2020).) This
year’s event will take place across two virtual sessions on August 3 and 10.
Each day, there will be four talks, intermixed with Q&A time. An abstract for
each talk is provided below. The discussion section will be a live meeting on
Jitsi, with details to follow. The whole event will be also streamed on
3mdeb’s YouTube
channel (https://www.youtube.com/channel/UC_djHbyjuJvhVjfT18nyqmQ), where we
will also accept questions. We invite everyone interested to join!
Agenda for August 3
Time (UTC)
Event denoscription
18:00 – 18:15
Welcome and introduction by Piotr Król
18:15 – 19:00
“Qubes OS 4.1 highlights” by Marek Marczykowski-Górecki
19:00 – 19:45
“First Impressions Count: Onboarding Qubes Users Through an Integrated Tutorial” by deeplow
19:45 – 20:15
Break
20:15 – 21:00
“Wyng-backups: revertible local and remote known safe Qubes OS states (including dom0)” by Thierry Laurion
21:00 – 21:45
“SRTM and Secure Boot for VMs” by Piotr Król
21:45
vPub, informal afterparty
Agenda for August 10
Time (UTC)
Event denoscription
18:00 – 18:15
Welcome and introduction by Piotr Król
18:15 – 19:00
“Usability Within A Reasonably Secure, Multi-Environment System” by Nina Alter
19:00 – 19:45
“Qubes OS Native App Menu: UX Design and Implementation” by Marta Marczykowska-Górecka and Nina Alter
19:45 – 20:15
Break
20:15 – 21:00
“A brief history of USB camera support in Qubes OS” by Piotr Król
21:00 – 21:45
“How to setup BTC and XMR cold storage in Qubes OS” by Piotr Król
21:45
vPub, informal afterparty
Abstracts of the talks
“Qubes OS 4.1 highlights” by Marek Marczykowski-Górecki
The upcoming Qubes OS 4.1 release is full of new exciting features, ranging
from a technology preview of the GUI domain to subtle, yet important, Qrexec
improvements. In this talk I will give a brief overview of them and demo a
select few.
“First Impressions Count: Onboarding Qubes Users Through an Integrated Tutorial” by deeplow
We may all relate to having a rough time when starting using Qubes — be that
because we’re coming from Windows and everything is different or because we
come from Linux and many things don’t work like we expect them to. Apart from
the usual challenges of going into a different system, Qubes has the additional
one of requiring a fundamentally different way of thinking about your computer
(a hypervisor mental-model). Smoothing out this transition is particularly
important as Qubes aims to target vulnerable populations that are less
technically inclined and have less time to explore and read the documentation.
The solution proposed by deeplow is to implement an integrated onboarding
tutorial. The idea is that a short tutorial (with optional extra parts) that
guides the user through the essential mechanics of Qubes will make the
transition simpler. That’s what deeplow’s been working on for his master’s
dissertation. In this talk he’ll introduce the idea and give an update on the
current progress and challenges.
“Wyng-backups: revertible local and remote known safe Qubes OS states (including dom0)” by Thierry Laurion
Wyng-backups (https://github.com/tasket/wyng-backup) is an incremental
backup/restore tool for LVMs. For Qubes OS, this means even dom0 can be
https://www.qubes-os.org/news/2021/07/30/minisummit-agenda/
We are pleased to announce the third annual Qubes mini-summit co-hosted by
3mdeb (https://3mdeb.com/) and the Qubes OS Project. (For prior year
summaries, agendas, and slides, see
2019 (https://3mdeb.com/events/#Qubes-OS-and-3mdeb-minisummit) and
2020 (https://3mdeb.com/events/#Qubes-OS-and-3mdeb-minisummit2020).) This
year’s event will take place across two virtual sessions on August 3 and 10.
Each day, there will be four talks, intermixed with Q&A time. An abstract for
each talk is provided below. The discussion section will be a live meeting on
Jitsi, with details to follow. The whole event will be also streamed on
3mdeb’s YouTube
channel (https://www.youtube.com/channel/UC_djHbyjuJvhVjfT18nyqmQ), where we
will also accept questions. We invite everyone interested to join!
Agenda for August 3
Time (UTC)
Event denoscription
18:00 – 18:15
Welcome and introduction by Piotr Król
18:15 – 19:00
“Qubes OS 4.1 highlights” by Marek Marczykowski-Górecki
19:00 – 19:45
“First Impressions Count: Onboarding Qubes Users Through an Integrated Tutorial” by deeplow
19:45 – 20:15
Break
20:15 – 21:00
“Wyng-backups: revertible local and remote known safe Qubes OS states (including dom0)” by Thierry Laurion
21:00 – 21:45
“SRTM and Secure Boot for VMs” by Piotr Król
21:45
vPub, informal afterparty
Agenda for August 10
Time (UTC)
Event denoscription
18:00 – 18:15
Welcome and introduction by Piotr Król
18:15 – 19:00
“Usability Within A Reasonably Secure, Multi-Environment System” by Nina Alter
19:00 – 19:45
“Qubes OS Native App Menu: UX Design and Implementation” by Marta Marczykowska-Górecka and Nina Alter
19:45 – 20:15
Break
20:15 – 21:00
“A brief history of USB camera support in Qubes OS” by Piotr Król
21:00 – 21:45
“How to setup BTC and XMR cold storage in Qubes OS” by Piotr Król
21:45
vPub, informal afterparty
Abstracts of the talks
“Qubes OS 4.1 highlights” by Marek Marczykowski-Górecki
The upcoming Qubes OS 4.1 release is full of new exciting features, ranging
from a technology preview of the GUI domain to subtle, yet important, Qrexec
improvements. In this talk I will give a brief overview of them and demo a
select few.
“First Impressions Count: Onboarding Qubes Users Through an Integrated Tutorial” by deeplow
We may all relate to having a rough time when starting using Qubes — be that
because we’re coming from Windows and everything is different or because we
come from Linux and many things don’t work like we expect them to. Apart from
the usual challenges of going into a different system, Qubes has the additional
one of requiring a fundamentally different way of thinking about your computer
(a hypervisor mental-model). Smoothing out this transition is particularly
important as Qubes aims to target vulnerable populations that are less
technically inclined and have less time to explore and read the documentation.
The solution proposed by deeplow is to implement an integrated onboarding
tutorial. The idea is that a short tutorial (with optional extra parts) that
guides the user through the essential mechanics of Qubes will make the
transition simpler. That’s what deeplow’s been working on for his master’s
dissertation. In this talk he’ll introduce the idea and give an update on the
current progress and challenges.
“Wyng-backups: revertible local and remote known safe Qubes OS states (including dom0)” by Thierry Laurion
Wyng-backups (https://github.com/tasket/wyng-backup) is an incremental
backup/restore tool for LVMs. For Qubes OS, this means even dom0 can be
reverted to a known safe state; locally or remotely, applying changes only.
This talk will be a deep dive into the possibilities of wyng-backups for
deploying and maintaining up to date, revertible states of Qubes OS base
systems.
“SRTM and Secure Boot for VMs” by Piotr Król
This talk is the continuation of the Qubes OS mini-summit presentation “SRTM
for Qubes OS VMs”, where the theoretical background of the Static Root of Trust
was presented and discussed. In this presentation, we will practically approach
SRTM and Secure Boot for VMs. We will also explore potential use cases for
self-decrypting storage and signed kernels using safeboot. Finally, we will
discuss how to introduce this and other security mechanisms in Qubes OS.
“Usability Within A Reasonably Secure, Multi-Environment System” by Nina Alter
Nina Alter first became aware of exciting possibilities of Qubes OS, when asked
to lead UX research and design for the SecureDrop Workstation project.
SecureDrop’s Workstation is built atop Qubes OS, yet exists for high-risk,
non-technical journalist users. Nina will share her early discovery work;
the joys, the pain-points, and the many opportunities she has since uncovered
to extend Qubes OS’ reach to some of our world’s most vulnerable digital
citizens.
“Qubes OS Native App Menu: UX Design and Implementation” by Marta Marczykowska-Górecka and Nina Alter
A brief overview of the new Application Menu that’s being introduced in (at
latest) Qubes 4.2, the process of creating it, and design and implementation
challenges. Based on design work by Nina Alter and implementation by Marta
Marczykowska-Górecka.
“A brief history of USB camera support in Qubes OS” by Piotr Król
The use of complex multi-endpoint isochronous USB devices in the presence of
sys-usb was not always possible in Qubes OS. Luckily, the Qubes Video Companion
project was created by Elliot Killick, which enabled users to use USB cameras
on Qubes OS. The project is still in development and testing, but it is very
promising and gives many USB camera users hope. This presentation will tell the
story of using Qubes Video Companion with the Logitech C922.
“How to set up BTC and XMR cold storage in Qubes OS” by Piotr Król
Cold storage, also called offline wallets, provides the highest level of
security for cryptocurrency. The critical characteristic of a computing
environment that can be used as cold storage is the lack of network
connectivity. Good examples of cold storage are spare computer devices or
microcontroller-based devices like a hardware wallet. By leveraging the same
architecture, Qubes OS domains can be used for cold storage. In such a case,
one of the domains is disconnected from the network and runs a cryptocurrency
wallet inside. Other domains may generate transactions files, which are sent to
cold storage VM for signing. Signed transaction files are sent back to the
online environment. All operations are performed using well-specified and
secure Qubes RPCs. This presentation will show how to set up and use BTC and
XMR cold storage with the most popular wallets for those cryptocurrencies. We
will also discuss what other measures can be taken to secure offline wallet
VMs.
This talk will be a deep dive into the possibilities of wyng-backups for
deploying and maintaining up to date, revertible states of Qubes OS base
systems.
“SRTM and Secure Boot for VMs” by Piotr Król
This talk is the continuation of the Qubes OS mini-summit presentation “SRTM
for Qubes OS VMs”, where the theoretical background of the Static Root of Trust
was presented and discussed. In this presentation, we will practically approach
SRTM and Secure Boot for VMs. We will also explore potential use cases for
self-decrypting storage and signed kernels using safeboot. Finally, we will
discuss how to introduce this and other security mechanisms in Qubes OS.
“Usability Within A Reasonably Secure, Multi-Environment System” by Nina Alter
Nina Alter first became aware of exciting possibilities of Qubes OS, when asked
to lead UX research and design for the SecureDrop Workstation project.
SecureDrop’s Workstation is built atop Qubes OS, yet exists for high-risk,
non-technical journalist users. Nina will share her early discovery work;
the joys, the pain-points, and the many opportunities she has since uncovered
to extend Qubes OS’ reach to some of our world’s most vulnerable digital
citizens.
“Qubes OS Native App Menu: UX Design and Implementation” by Marta Marczykowska-Górecka and Nina Alter
A brief overview of the new Application Menu that’s being introduced in (at
latest) Qubes 4.2, the process of creating it, and design and implementation
challenges. Based on design work by Nina Alter and implementation by Marta
Marczykowska-Górecka.
“A brief history of USB camera support in Qubes OS” by Piotr Król
The use of complex multi-endpoint isochronous USB devices in the presence of
sys-usb was not always possible in Qubes OS. Luckily, the Qubes Video Companion
project was created by Elliot Killick, which enabled users to use USB cameras
on Qubes OS. The project is still in development and testing, but it is very
promising and gives many USB camera users hope. This presentation will tell the
story of using Qubes Video Companion with the Logitech C922.
“How to set up BTC and XMR cold storage in Qubes OS” by Piotr Król
Cold storage, also called offline wallets, provides the highest level of
security for cryptocurrency. The critical characteristic of a computing
environment that can be used as cold storage is the lack of network
connectivity. Good examples of cold storage are spare computer devices or
microcontroller-based devices like a hardware wallet. By leveraging the same
architecture, Qubes OS domains can be used for cold storage. In such a case,
one of the domains is disconnected from the network and runs a cryptocurrency
wallet inside. Other domains may generate transactions files, which are sent to
cold storage VM for signing. Signed transaction files are sent back to the
online environment. All operations are performed using well-specified and
secure Qubes RPCs. This presentation will show how to set up and use BTC and
XMR cold storage with the most popular wallets for those cryptocurrencies. We
will also discuss what other measures can be taken to secure offline wallet
VMs.
Forwarded from Ali Mirjamali 🌍
In 20 minutes: https://www.youtube.com/watch?v=y3V_V0Vllas
YouTube
Qubes OS-3mdeb mini-summit 2021: Day 1
Qubes OS virtual mini-summit 2021 is the event co-hosted with 3mdeb, where the Qubes OS experts will cover various topics related to the design, security, and usability of our favorite operating system. This year we will get highlights of the newest Qubes…
Xen Developer and Design Summit: A Year of Fuzzing with Xen
https://xenproject.org/2021/08/17/fuzzing-with-xen/
At the 2021 Xen Developer and Design Summit, Tamas K Lengyel, Senior Security Researcher at Intel Corporation, gave a deep dive into the latest developments of Intel’s Xen-based fuzzer that...
https://xenproject.org/2021/08/17/fuzzing-with-xen/
At the 2021 Xen Developer and Design Summit, Tamas K Lengyel, Senior Security Researcher at Intel Corporation, gave a deep dive into the latest developments of Intel’s Xen-based fuzzer that...
XSAs released on 2021-08-25
https://www.qubes-os.org/news/2021/08/25/xsas-released-on-2021-08-25/
The Xen Project has released one or more 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-378
XSA-379
XSA-382
Please see QSB-070 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/2021/08/25/qsb-070/
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-380 (denial of service only)
XSA-383 (affects only Arm systems)
Related links
Xen Project 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/2021/08/25/xsas-released-on-2021-08-25/
The Xen Project has released one or more 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-378
XSA-379
XSA-382
Please see QSB-070 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/2021/08/25/qsb-070/
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-380 (denial of service only)
XSA-383 (affects only Arm systems)
Related links
Xen Project 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-070: Xen issues related to grant tables v2 and IOMMU
https://www.qubes-os.org/news/2021/08/25/qsb-070/
We have just published Qubes Security Bulletin (QSB) 070:
Xen issues related to grant tables v2 and IOMMU.
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-070 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-070-2021.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 070 ]===---
2021-08-25
Xen issues related to grant tables v2 and IOMMU
(XSA-378, XSA-379, XSA-382)
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-35
For Qubes 4.1, in dom0:
- Xen packages, version 4.14.2-2
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [1] Once available, the packages are to be installed
via the Qubes Update Tool or its command-line equivalents. [2]
Dom0 must be restarted afterward in order for the updates to take
effect.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.
Summary
========
The following security advisories were published on 2021-08-25:
XSA-378 [3] "IOMMU page mapping issues on x86":
| Both AMD and Intel allow ACPI tables to specify regions of memory
| which should be left untranslated, which typically means these
| addresses should pass the translation phase unaltered. While these
| are typically device specific ACPI properties, they can also be
| specified to apply to a range of devices, or even all devices.
|
| On all systems with such regions Xen failed to prevent guests from
| undoing/replacing such mappings (CVE-2021-28694).
|
| On AMD systems, where a discontinuous range is specified by firmware,
| the supposedly-excluded middle range will also be identity-mapped
| (CVE-2021-28695).
|
| Further, on AMD systems, upon de-assigment of a physical device from a
| guest, the identity mappings would be left in place, allowing a guest
| continued access to ranges of memory which it shouldn't have access to
| anymore (CVE-2021-28696).
|
XSA-379 [4] "grant table v2 status pages may remain accessible after
de-allocation":
| Guest get permitted access to certain Xen-owned pages of memory. The
| majority of such pages remain allocated / associated with a guest for
| its entire lifetime. Grant table v2 status pages, however, get
| de-allocated when a guest switched (back) from v2 to v1. The freeing
| of such pages requires that the hypervisor know where in the guest
| these pages were mapped. The hypervisor tracks only one use within
| guest space, but racing requests from the guest to insert mappings of
| these pages may result in any of them to become mapped in multiple
| locations. Upon switching back from v2 to v1, the guest would then
| retain access to a page that was freed and perhaps re-used for other
| purposes.
|
| 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.
XSA-382 [5] "inadequate grant-v2 status frames array bounds check"
| The v2 grant table interface separates grant attributes from grant
| status. That is, when operating in this mode, a guest has two tables.
| As a result, guests also need to be able to retrieve the addresses that
https://www.qubes-os.org/news/2021/08/25/qsb-070/
We have just published Qubes Security Bulletin (QSB) 070:
Xen issues related to grant tables v2 and IOMMU.
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-070 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-070-2021.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 070 ]===---
2021-08-25
Xen issues related to grant tables v2 and IOMMU
(XSA-378, XSA-379, XSA-382)
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-35
For Qubes 4.1, in dom0:
- Xen packages, version 4.14.2-2
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [1] Once available, the packages are to be installed
via the Qubes Update Tool or its command-line equivalents. [2]
Dom0 must be restarted afterward in order for the updates to take
effect.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.
Summary
========
The following security advisories were published on 2021-08-25:
XSA-378 [3] "IOMMU page mapping issues on x86":
| Both AMD and Intel allow ACPI tables to specify regions of memory
| which should be left untranslated, which typically means these
| addresses should pass the translation phase unaltered. While these
| are typically device specific ACPI properties, they can also be
| specified to apply to a range of devices, or even all devices.
|
| On all systems with such regions Xen failed to prevent guests from
| undoing/replacing such mappings (CVE-2021-28694).
|
| On AMD systems, where a discontinuous range is specified by firmware,
| the supposedly-excluded middle range will also be identity-mapped
| (CVE-2021-28695).
|
| Further, on AMD systems, upon de-assigment of a physical device from a
| guest, the identity mappings would be left in place, allowing a guest
| continued access to ranges of memory which it shouldn't have access to
| anymore (CVE-2021-28696).
|
XSA-379 [4] "grant table v2 status pages may remain accessible after
de-allocation":
| Guest get permitted access to certain Xen-owned pages of memory. The
| majority of such pages remain allocated / associated with a guest for
| its entire lifetime. Grant table v2 status pages, however, get
| de-allocated when a guest switched (back) from v2 to v1. The freeing
| of such pages requires that the hypervisor know where in the guest
| these pages were mapped. The hypervisor tracks only one use within
| guest space, but racing requests from the guest to insert mappings of
| these pages may result in any of them to become mapped in multiple
| locations. Upon switching back from v2 to v1, the guest would then
| retain access to a page that was freed and perhaps re-used for other
| purposes.
|
| 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.
XSA-382 [5] "inadequate grant-v2 status frames array bounds check"
| The v2 grant table interface separates grant attributes from grant
| status. That is, when operating in this mode, a guest has two tables.
| As a result, guests also need to be able to retrieve the addresses that
| the new status tracking table can be accessed through.
|
| For 32-bit guests on x86, translation of requests has to occur because
| the interface structure layouts commonly differ between 32- and 64-bit.
|
| The translation of the request to obtain the frame numbers of the
| grant status table involves translating the resulting array of frame
| numbers. Since the space used to carry out the translation is limited,
| the translation layer tells the core function the capacity of the array
| within translation space. Unfortunately the core function then only
| enforces array bounds to be below 8 times the specified value, and would
| write past the available space if enough frame numbers needed storing.
|
| Malicious or buggy guest kernels may be able to mount a Denial of
| Service (DoS) attack affecting the entire system. Privilege escalation
| and information leaks cannot be ruled out.
Impact
=======
XSA-378:
As the Xen Security Team explains, "The precise impact is system
specific, but can - on affected systems - be any or all of privilege
escalation, denial of service, or 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-379:
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."
XSA-382:
Similar to the XSA-379. XSA-382 affects only Xen version 4.10 or newer,
thus only Qubes OS R4.1 is affected.
Discussion
===========
This is yet another set of problems related to grant tables v2. Since
none of the software included in Qubes OS uses this feature (both Linux
and Windows use grant tables v1), we have decided to disable grant
tables v2 in Xen globally in addition to apply the specific patches
described above.
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-378.html
[4] https://xenbits.xen.org/xsa/advisory-379.html
[5] https://xenbits.xen.org/xsa/advisory-382.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
|
| For 32-bit guests on x86, translation of requests has to occur because
| the interface structure layouts commonly differ between 32- and 64-bit.
|
| The translation of the request to obtain the frame numbers of the
| grant status table involves translating the resulting array of frame
| numbers. Since the space used to carry out the translation is limited,
| the translation layer tells the core function the capacity of the array
| within translation space. Unfortunately the core function then only
| enforces array bounds to be below 8 times the specified value, and would
| write past the available space if enough frame numbers needed storing.
|
| Malicious or buggy guest kernels may be able to mount a Denial of
| Service (DoS) attack affecting the entire system. Privilege escalation
| and information leaks cannot be ruled out.
Impact
=======
XSA-378:
As the Xen Security Team explains, "The precise impact is system
specific, but can - on affected systems - be any or all of privilege
escalation, denial of service, or 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-379:
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."
XSA-382:
Similar to the XSA-379. XSA-382 affects only Xen version 4.10 or newer,
thus only Qubes OS R4.1 is affected.
Discussion
===========
This is yet another set of problems related to grant tables v2. Since
none of the software included in Qubes OS uses this feature (both Linux
and Windows use grant tables v1), we have decided to disable grant
tables v2 in Xen globally in addition to apply the specific patches
described above.
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-378.html
[4] https://xenbits.xen.org/xsa/advisory-379.html
[5] https://xenbits.xen.org/xsa/advisory-382.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
Xen Summit Highlights: Xen FuSa SIG updates
https://xenproject.org/2021/08/25/xen-summit-highlights-xen-fusa-sig-updates/
During the 2021 Xen Summit, representatives from the Xen Project Functional Safety Special Interest Group have an update on what the SIG has been up to. The panelists covered what...
https://xenproject.org/2021/08/25/xen-summit-highlights-xen-fusa-sig-updates/
During the 2021 Xen Summit, representatives from the Xen Project Functional Safety Special Interest Group have an update on what the SIG has been up to. The panelists covered what...
Qubes Canary 028
https://www.qubes-os.org/news/2021/08/31/canary-028/
We have published Qubes Canary 028. The text of this canary is
reproduced below. Please note that this canary contains an announcement
and is accompanied by two letters, which are also reproduced below.
General information
This canary and its accompanying signatures will always be available in
the Qubes security pack (qubes-secpack).
View Qubes Canary 028 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-028-2021.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 028
---===[ Qubes Canary 028 ]===---
Statements
-----------
The Qubes core developers who have digitally signed this file [1] state
the following:
1. The date of issue of this canary is August 31, 2021.
2. There have been 70 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 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
----------------------
Joanna Rutkowska will soon begin traveling without her Qubes laptop for
extended periods of time, which means she will not be able to sign
future canaries on time. She has asked the members of the Qubes security
team, Marek Marczykowski-Górecki and Simon Gaiser, to be released of her
obligation to sign canaries, and she has reaffirmed that she destroyed
all copies of the Qubes Master Signing Key in her possession when she
transferred the project lead position to Marek. The Qubes security team
has agreed to her request. Therefore, this will be the last Qubes canary
signed by Joanna.
Note that this canary is being published one day ahead of schedule
because this is the last day Joanna is available to sign. In addition to
the usual detached signatures from all three aforementioned individuals,
this canary is also accompanied by letters (with their own detached
signatures), all of which can be found in the canary directory in the
qubes-secpack [3].
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, 31 Aug 2021 00:03:05 +0000
Source: DER SPIEGEL - International (https://www.spiegel.de/international/index.rss)
Afghan Vice President in Letter to DER SPIEGEL: "A Deal for Surrender Won't Happen"
https://www.qubes-os.org/news/2021/08/31/canary-028/
We have published Qubes Canary 028. The text of this canary is
reproduced below. Please note that this canary contains an announcement
and is accompanied by two letters, which are also reproduced below.
General information
This canary and its accompanying signatures will always be available in
the Qubes security pack (qubes-secpack).
View Qubes Canary 028 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-028-2021.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 028
---===[ Qubes Canary 028 ]===---
Statements
-----------
The Qubes core developers who have digitally signed this file [1] state
the following:
1. The date of issue of this canary is August 31, 2021.
2. There have been 70 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 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
----------------------
Joanna Rutkowska will soon begin traveling without her Qubes laptop for
extended periods of time, which means she will not be able to sign
future canaries on time. She has asked the members of the Qubes security
team, Marek Marczykowski-Górecki and Simon Gaiser, to be released of her
obligation to sign canaries, and she has reaffirmed that she destroyed
all copies of the Qubes Master Signing Key in her possession when she
transferred the project lead position to Marek. The Qubes security team
has agreed to her request. Therefore, this will be the last Qubes canary
signed by Joanna.
Note that this canary is being published one day ahead of schedule
because this is the last day Joanna is available to sign. In addition to
the usual detached signatures from all three aforementioned individuals,
this canary is also accompanied by letters (with their own detached
signatures), all of which can be found in the canary directory in the
qubes-secpack [3].
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, 31 Aug 2021 00:03:05 +0000
Source: DER SPIEGEL - International (https://www.spiegel.de/international/index.rss)
Afghan Vice President in Letter to DER SPIEGEL: "A Deal for Surrender Won't Happen"
Afghanistan Disaster: Debacle in Kabul Could Overshadow Biden's Presidency
The End of the German Airlift: What Will Become of the Afghans Left Behind?
Terror Expert on Afghanistan: "The Real Threat Is Islamic State, not Al-Qaida"
Redistributing Mafia Assets: The Palaces and Ruins of the Drug Bosses
Source: NYT > World News (https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
Afghanistan Live Updates: The U.S. Occupation Is Over, Ending America’s Longest War
U.S. Conducts Drone Strike in Kabul and Winds Down Airlift as Deadline Nears
Colombia’s Troubles Put a President’s Legacy on the Line
North Korea Restarted Plutonium-Producing Reactor, U.N. Agency Warns
How 2 Afghan Paralympians Defied the Odds to Get From Kabul to Tokyo
Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
Afghanistan: US investigates civilian deaths in Kabul strike
Hurricane Ida: One million people in Louisiana without power
Covid: EU recommends new travel restrictions for US as cases rise
Brazil bank robbers tie hostages to getaway cars in Araçatuba
China cuts children's online gaming to one hour
Source: Blockchain.info
000000000000000000059580872127a33754c4f4fb4e251ace298fea01ee73ca
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!
[3] https://github.com/QubesOS/qubes-secpack/tree/master/canaries
Letter from Joanna Rutkowska
The original letter and its detached signature file are available here:
canary-028-2021-letter-joanna.txt (https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-028-2021-letter-joanna.txt)
canary-028-2021-letter-joanna.txt.sig.joanna (https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-028-2021-letter-joanna.txt.sig.joanna)
2021-08-31
Hello again, Qubes community!
I hope you've all been well. As many of you know, I've continued to sign
Qubes canaries [1] ever since I left the project [2]. At the time, I
thought I could just continue to sign them forever, but I didn't
consider that this would effectively make my secure Qubes laptop like a
ball-and-chain that I'd have to bring with me wherever I go. :)
At this point in my life, I'd really like to do much more traveling
while being able to pack light and feel free of too many physical
possessions. Since I am not willing to compromise the security of the
Qubes OS Project or the security of the Qubes laptop I've been using to
sign canaries in any way just to make my own personal life easier, I've
decided it would be best to request that I be removed from the list of
canary signers. Otherwise, there would be canaries that I wouldn't be
able to sign on-time, which would create headaches for Marek and Simon,
as well as confusion for users looking for my signature and not finding
it.
So, I've requested that the current Qubes security team remove me from
the Qubes canary signing process. And, FWIW, I confirm that I --
according to the best of my knowledge -- destroyed all copies of the
Qubes Master Signing Key which were in my possession when I passed
project lead to Marek, and no one has approached me in an attempt to
subvert the Qubes OS Project in any way. This request is solely for my
own personal reasons, as explained above.
Canary 028 [3] should contain a denoscription of this event under the
"Special announcements" section, and that canary should be accompanied
by my signature as well as those of the current Qubes security team,
Marek Marczykowski-Górecki and Simon Gaiser. Canary 028 is the final
canary I will sign.
I wish the Qubes OS Project continued success!
Sincerely,
Joanna
[1] https://www.qubes-os.org/security/canary/
[2] https://www.qubes-os.org/news/2018/10/25/the-next-chapter/
The End of the German Airlift: What Will Become of the Afghans Left Behind?
Terror Expert on Afghanistan: "The Real Threat Is Islamic State, not Al-Qaida"
Redistributing Mafia Assets: The Palaces and Ruins of the Drug Bosses
Source: NYT > World News (https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
Afghanistan Live Updates: The U.S. Occupation Is Over, Ending America’s Longest War
U.S. Conducts Drone Strike in Kabul and Winds Down Airlift as Deadline Nears
Colombia’s Troubles Put a President’s Legacy on the Line
North Korea Restarted Plutonium-Producing Reactor, U.N. Agency Warns
How 2 Afghan Paralympians Defied the Odds to Get From Kabul to Tokyo
Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
Afghanistan: US investigates civilian deaths in Kabul strike
Hurricane Ida: One million people in Louisiana without power
Covid: EU recommends new travel restrictions for US as cases rise
Brazil bank robbers tie hostages to getaway cars in Araçatuba
China cuts children's online gaming to one hour
Source: Blockchain.info
000000000000000000059580872127a33754c4f4fb4e251ace298fea01ee73ca
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!
[3] https://github.com/QubesOS/qubes-secpack/tree/master/canaries
Letter from Joanna Rutkowska
The original letter and its detached signature file are available here:
canary-028-2021-letter-joanna.txt (https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-028-2021-letter-joanna.txt)
canary-028-2021-letter-joanna.txt.sig.joanna (https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-028-2021-letter-joanna.txt.sig.joanna)
2021-08-31
Hello again, Qubes community!
I hope you've all been well. As many of you know, I've continued to sign
Qubes canaries [1] ever since I left the project [2]. At the time, I
thought I could just continue to sign them forever, but I didn't
consider that this would effectively make my secure Qubes laptop like a
ball-and-chain that I'd have to bring with me wherever I go. :)
At this point in my life, I'd really like to do much more traveling
while being able to pack light and feel free of too many physical
possessions. Since I am not willing to compromise the security of the
Qubes OS Project or the security of the Qubes laptop I've been using to
sign canaries in any way just to make my own personal life easier, I've
decided it would be best to request that I be removed from the list of
canary signers. Otherwise, there would be canaries that I wouldn't be
able to sign on-time, which would create headaches for Marek and Simon,
as well as confusion for users looking for my signature and not finding
it.
So, I've requested that the current Qubes security team remove me from
the Qubes canary signing process. And, FWIW, I confirm that I --
according to the best of my knowledge -- destroyed all copies of the
Qubes Master Signing Key which were in my possession when I passed
project lead to Marek, and no one has approached me in an attempt to
subvert the Qubes OS Project in any way. This request is solely for my
own personal reasons, as explained above.
Canary 028 [3] should contain a denoscription of this event under the
"Special announcements" section, and that canary should be accompanied
by my signature as well as those of the current Qubes security team,
Marek Marczykowski-Górecki and Simon Gaiser. Canary 028 is the final
canary I will sign.
I wish the Qubes OS Project continued success!
Sincerely,
Joanna
[1] https://www.qubes-os.org/security/canary/
[2] https://www.qubes-os.org/news/2018/10/25/the-next-chapter/
[3] https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-028-2021.txt
Letter from the Qubes security team
The original letter and its detached signature files are available here:
canary-028-2021-letter-qst.txt (https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-028-2021-letter-qst.txt)
canary-028-2021-letter-qst.txt.sig.marmarek (https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-028-2021-letter-qst.txt.sig.marmarek)
canary-028-2021-letter-qst.txt.sig.simon (https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-028-2021-letter-qst.txt.sig.simon)
2021-08-31
Dear Qubes community,
As you can see in Qubes Canary 028 [1], Joanna has requested that she be
removed from the list of canary signers [2], and we have agreed to this
request. A careful reader might recall that, when Joanna left the Qubes
security team in 2018, we wrote [3]:
| However, due to the nature of PGP keys, there is no way to
| guarantee that Joanna will not retain a copy of the QMSK after
| transferring ownership to Marek. Since anyone in possession of the
| QMSK is a potential attack vector against the project, Joanna will
| continue to sign Qubes Canaries in perpetuity.
So, why this change now? It's still true that we (except Joanna herself,
of course) can't guarantee that Joanna did not really retain any copies
of the private portion of the Qubes Master Signing Key. Continuing to
have her sign the canaries on time every few months seemed like a
harmless commitment back then but turned out to require quite a lot of
effort now that Joanna is no longer involved in the project's day-to-day
business. Therefore, we reevaluated whether this is worth the effort
and decided against it. If Joanna were lying about deleting all her
copies of the private portion of the Qubes Master Signing Key, it is
equally possible that she could lie when signing a canary. Therefore,
we do not believe that her ceasing to sign canaries constitutes a
security problem.
This is a good reminder that canaries help only in a very specific
scenario, namely if someone (1) wants to act honestly, (2) is prevented
from stating that a compromise has occurred, and (3) is not forced to
state that no compromise has occurred. For example, this canary scheme
is designed to help if we were ever served with a government warrant
with an attached gag order that prohibited us from discussing the
warrant (the second condition) but that did not compel us to continue
signing and publishing canaries against our will (the third condition).
However, this will not work if the adversary is willing to coerce us
into signing and publishing statements or if signers are willing to lie
by signing statements they know to be false. Hence, this canary scheme
is limited and fallible, which is why we have always included a
statement to this effect in every canary.
Regards,
The Qubes security team
https://www.qubes-os.org/security/
[1] https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-028-2021.txt
[2] https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-028-2021-letter-joanna.txt
[3] https://www.qubes-os.org/news/2018/11/05/qubes-security-team-update/
Letter from the Qubes security team
The original letter and its detached signature files are available here:
canary-028-2021-letter-qst.txt (https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-028-2021-letter-qst.txt)
canary-028-2021-letter-qst.txt.sig.marmarek (https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-028-2021-letter-qst.txt.sig.marmarek)
canary-028-2021-letter-qst.txt.sig.simon (https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-028-2021-letter-qst.txt.sig.simon)
2021-08-31
Dear Qubes community,
As you can see in Qubes Canary 028 [1], Joanna has requested that she be
removed from the list of canary signers [2], and we have agreed to this
request. A careful reader might recall that, when Joanna left the Qubes
security team in 2018, we wrote [3]:
| However, due to the nature of PGP keys, there is no way to
| guarantee that Joanna will not retain a copy of the QMSK after
| transferring ownership to Marek. Since anyone in possession of the
| QMSK is a potential attack vector against the project, Joanna will
| continue to sign Qubes Canaries in perpetuity.
So, why this change now? It's still true that we (except Joanna herself,
of course) can't guarantee that Joanna did not really retain any copies
of the private portion of the Qubes Master Signing Key. Continuing to
have her sign the canaries on time every few months seemed like a
harmless commitment back then but turned out to require quite a lot of
effort now that Joanna is no longer involved in the project's day-to-day
business. Therefore, we reevaluated whether this is worth the effort
and decided against it. If Joanna were lying about deleting all her
copies of the private portion of the Qubes Master Signing Key, it is
equally possible that she could lie when signing a canary. Therefore,
we do not believe that her ceasing to sign canaries constitutes a
security problem.
This is a good reminder that canaries help only in a very specific
scenario, namely if someone (1) wants to act honestly, (2) is prevented
from stating that a compromise has occurred, and (3) is not forced to
state that no compromise has occurred. For example, this canary scheme
is designed to help if we were ever served with a government warrant
with an attached gag order that prohibited us from discussing the
warrant (the second condition) but that did not compel us to continue
signing and publishing canaries against our will (the third condition).
However, this will not work if the adversary is willing to coerce us
into signing and publishing statements or if signers are willing to lie
by signing statements they know to be false. Hence, this canary scheme
is limited and fallible, which is why we have always included a
statement to this effect in every canary.
Regards,
The Qubes security team
https://www.qubes-os.org/security/
[1] https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-028-2021.txt
[2] https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-028-2021-letter-joanna.txt
[3] https://www.qubes-os.org/news/2018/11/05/qubes-security-team-update/
XSAs released on 2021-09-08
https://www.qubes-os.org/news/2021/09/08/xsas-released-on-2021-09-08/
The Xen Project has released one or more Xen Security Advisories (XSAs).
The security of Qubes OS is not affected by one or more of 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-384 (already covered by the fix for QSB-070)
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/2021/09/08/xsas-released-on-2021-09-08/
The Xen Project has released one or more Xen Security Advisories (XSAs).
The security of Qubes OS is not affected by one or more of 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-384 (already covered by the fix for QSB-070)
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-071: Fatal options filtering flaw in Split GPG
https://www.qubes-os.org/news/2021/09/09/qsb-071/
We have just published Qubes Security Bulletin (QSB) 071:
Fatal options filtering flaw in Split GPG.
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-071 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-071-2021.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/
---===[ Qubes Security Bulletin 071 ]===---
2021-09-09
Fatal options filtering flaw in Split GPG
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 templates and standalones:
- qubes-gpg-split 2.0.53
For Qubes 4.1, in templates and standalones:
- qubes-gpg-split 2.0.53
Due to the ease with which this flaw can be exploited, we are immediately
migrating these packages to the current (stable) repository, bypassing the
usual testing period. These packages are to be installed via the Qubes Update
tool or its command-line equivalents. [1]
Summary
--------
Split GPG [2] 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 to `gpg` into a backend qube that holds the private keys and
allowing only specific `gpg` options. This option filtering mechanism rejects
options like `--export-secret-keys` and others that might leak private keys to
the frontend qube. Unfortunately, several options were declared incorrectly,
which allowed this filtering mechanism to be bypassed.
Impact
-------
An attacker controlling a frontend qube (where `qubes-gpg-client` is executed)
can extract an arbitrary file (including a secret key) from the backend qube.
Discussion
-----------
Several `gpg` options were declared incorrectly in Split GPG, which resulted in
Split GPG interpreting them differently than `gpg`. If Split GPG interpreted
one option as an argument to another option, Split GPG would allow it, since
option filtering is performed at the level of the options themselves, not their
arguments. This would allow options misinterpreted as arguments to bypass the
filtering mechanism. Specifically:
- All `--s2k-*` options were declared as not taking arguments when in fact they
do take arguments.
- `--export-ssh-key` was declared as taking an argument when it doesn't take
one directly; it does change the meanings of positional arguments, however.
- `--with-colons` was aliased with `-k`, which differs in its argument
requirements.
- `--default-recipient`, which takes an argument, was interpreted as
`--default-recipient-self`, which does not take an argument.
- `--display` was interpreted as `--display-charset`, which resulted in
`--display` being allowed when it should have been denied.
For our immediate, initial response, we have corrected all of these
inconsistencies and added automated testing to verify that GnuPG and Split GPG
both understand the options in the same way.
More generally, we will prioritize finishing Split GPG 2 [3], which does not
rely on option filtering at all. Instead, it uses `gpg-agent`'s protocol to
delegate only secret key processing to the backend qube. In addition to
obviating the need for fragile option filtering, this dramatically reduces the
attack surface, as most of the untrusted data processing is done in the
frontend qube and never reaches the backend qube.
Credits
--------
This issue was discovered by Demi Marie Obenour.
References
-----------
[1] https://www.qubes-os.org/doc/updating-qubes-os/
https://www.qubes-os.org/news/2021/09/09/qsb-071/
We have just published Qubes Security Bulletin (QSB) 071:
Fatal options filtering flaw in Split GPG.
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-071 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-071-2021.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/
---===[ Qubes Security Bulletin 071 ]===---
2021-09-09
Fatal options filtering flaw in Split GPG
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 templates and standalones:
- qubes-gpg-split 2.0.53
For Qubes 4.1, in templates and standalones:
- qubes-gpg-split 2.0.53
Due to the ease with which this flaw can be exploited, we are immediately
migrating these packages to the current (stable) repository, bypassing the
usual testing period. These packages are to be installed via the Qubes Update
tool or its command-line equivalents. [1]
Summary
--------
Split GPG [2] 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 to `gpg` into a backend qube that holds the private keys and
allowing only specific `gpg` options. This option filtering mechanism rejects
options like `--export-secret-keys` and others that might leak private keys to
the frontend qube. Unfortunately, several options were declared incorrectly,
which allowed this filtering mechanism to be bypassed.
Impact
-------
An attacker controlling a frontend qube (where `qubes-gpg-client` is executed)
can extract an arbitrary file (including a secret key) from the backend qube.
Discussion
-----------
Several `gpg` options were declared incorrectly in Split GPG, which resulted in
Split GPG interpreting them differently than `gpg`. If Split GPG interpreted
one option as an argument to another option, Split GPG would allow it, since
option filtering is performed at the level of the options themselves, not their
arguments. This would allow options misinterpreted as arguments to bypass the
filtering mechanism. Specifically:
- All `--s2k-*` options were declared as not taking arguments when in fact they
do take arguments.
- `--export-ssh-key` was declared as taking an argument when it doesn't take
one directly; it does change the meanings of positional arguments, however.
- `--with-colons` was aliased with `-k`, which differs in its argument
requirements.
- `--default-recipient`, which takes an argument, was interpreted as
`--default-recipient-self`, which does not take an argument.
- `--display` was interpreted as `--display-charset`, which resulted in
`--display` being allowed when it should have been denied.
For our immediate, initial response, we have corrected all of these
inconsistencies and added automated testing to verify that GnuPG and Split GPG
both understand the options in the same way.
More generally, we will prioritize finishing Split GPG 2 [3], which does not
rely on option filtering at all. Instead, it uses `gpg-agent`'s protocol to
delegate only secret key processing to the backend qube. In addition to
obviating the need for fragile option filtering, this dramatically reduces the
attack surface, as most of the untrusted data processing is done in the
frontend qube and never reaches the backend qube.
Credits
--------
This issue was discovered by Demi Marie Obenour.
References
-----------
[1] https://www.qubes-os.org/doc/updating-qubes-os/
[2] https://www.qubes-os.org/doc/split-gpg/
[3] https://github.com/QubesOS/qubes-issues/issues/474
--
The Qubes Security Team
https://www.qubes-os.org/security/
[3] https://github.com/QubesOS/qubes-issues/issues/474
--
The Qubes Security Team
https://www.qubes-os.org/security/
Clang-format for Xen Coding Style Checking Scheduled
https://xenproject.org/2021/09/22/clang-format-for-xen-coding-style-checking-scheduled/
Xen Summit 2021: Clang-format for Xen Coding Style Checking Anastasiia Lukianenko, EPAM At the moment there is no tool that would allow to format patches in Xen. The idea of...
https://xenproject.org/2021/09/22/clang-format-for-xen-coding-style-checking-scheduled/
Xen Summit 2021: Clang-format for Xen Coding Style Checking Anastasiia Lukianenko, EPAM At the moment there is no tool that would allow to format patches in Xen. The idea of...