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...
QSB-072: Inconsistent handling of the override-redirect flag
https://www.qubes-os.org/news/2021/09/27/qsb-072/
We have just published Qubes Security Bulletin (QSB) 072:
Inconsistent handling of the override-redirect flag.
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-072 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-072-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 072 ]===---
2021-09-27
Inconsistent handling of the override-redirect flag
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:
- qubes-gui-dom0 version 4.0.15
For Qubes 4.1, in dom0 and the template(s) of any GUI qube(s) [1]:
- qubes-gui-daemon version 4.1.16
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. [2] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [3]
The user session must be restarted afterward in order for the updates to
take effect, e.g., by logging out then logging back in.
Summary
--------
An override-redirect flag in the X11 protocol tells the window manager
not to manage a particular window. Windows with such flags do not get
their frames or noscript bars from the window manger, nor does the window
manager determine their positions. This feature is used for application
menus, tooltips, and similar accessory windows.
Since the window manager ignores such windows, the GUI daemon imposes
certain extra constraints on them, such as drawing thin colored frames.
Unfortunately, there are several cases in which the window manager and
GUI daemon do not agree on the override-redirect flag state, leading to
neither of them imposing the appropriate constraints.
Impact
-------
Normally, every window in Qubes OS has an unspoofable colored frame,
except for those belonging to dom0 or a GUI qube. [1] The flaws
described in this bulletin allow a malicious qube to create a window
that has no such colored frame. Such a window might be made to appear as
though it belongs to a different qube. For example, a malicious qube
with an untrusted color label might draw a passphrase prompt window.
Then, in order to induce the user to enter a valuable passphrase into
this window, the malicious qube might draw a fake frame in a different
color (more trusted than its own) along the inside edge of the window.
Since the window has no externally-imposed colored frame of its own, the
user might be deceived into accepting the fake internally-drawn frame as
a reliable indicator of the window's trust level or origin.
Such windows are also capable of bypassing limits normally imposed on
windows with the override-redirect flag. For example, such windows are
capable of covering desktop environment panels, potentially preventing
users from interacting with certain parts of the system or displaying
fake interface elements. Since such windows also lack colored frames,
they could be made to appear as though they belong to dom0 or a GUI qube
in an attempt to deceive users into believing that they are interacting
with trusted parts of the system.
Discussion
-----------
There were several cases in which the GUI daemon's view of the
override-redirect flag did not match the window manager's expectations:
1. Using an MSG_CONFIGURE GUI protocol [4] command to change the
override-redirect flag of a window that has already been mapped
https://www.qubes-os.org/news/2021/09/27/qsb-072/
We have just published Qubes Security Bulletin (QSB) 072:
Inconsistent handling of the override-redirect flag.
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-072 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-072-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 072 ]===---
2021-09-27
Inconsistent handling of the override-redirect flag
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:
- qubes-gui-dom0 version 4.0.15
For Qubes 4.1, in dom0 and the template(s) of any GUI qube(s) [1]:
- qubes-gui-daemon version 4.1.16
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. [2] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [3]
The user session must be restarted afterward in order for the updates to
take effect, e.g., by logging out then logging back in.
Summary
--------
An override-redirect flag in the X11 protocol tells the window manager
not to manage a particular window. Windows with such flags do not get
their frames or noscript bars from the window manger, nor does the window
manager determine their positions. This feature is used for application
menus, tooltips, and similar accessory windows.
Since the window manager ignores such windows, the GUI daemon imposes
certain extra constraints on them, such as drawing thin colored frames.
Unfortunately, there are several cases in which the window manager and
GUI daemon do not agree on the override-redirect flag state, leading to
neither of them imposing the appropriate constraints.
Impact
-------
Normally, every window in Qubes OS has an unspoofable colored frame,
except for those belonging to dom0 or a GUI qube. [1] The flaws
described in this bulletin allow a malicious qube to create a window
that has no such colored frame. Such a window might be made to appear as
though it belongs to a different qube. For example, a malicious qube
with an untrusted color label might draw a passphrase prompt window.
Then, in order to induce the user to enter a valuable passphrase into
this window, the malicious qube might draw a fake frame in a different
color (more trusted than its own) along the inside edge of the window.
Since the window has no externally-imposed colored frame of its own, the
user might be deceived into accepting the fake internally-drawn frame as
a reliable indicator of the window's trust level or origin.
Such windows are also capable of bypassing limits normally imposed on
windows with the override-redirect flag. For example, such windows are
capable of covering desktop environment panels, potentially preventing
users from interacting with certain parts of the system or displaying
fake interface elements. Since such windows also lack colored frames,
they could be made to appear as though they belong to dom0 or a GUI qube
in an attempt to deceive users into believing that they are interacting
with trusted parts of the system.
Discussion
-----------
There were several cases in which the GUI daemon's view of the
override-redirect flag did not match the window manager's expectations:
1. Using an MSG_CONFIGURE GUI protocol [4] command to change the
override-redirect flag of a window that has already been mapped
(i.e., made visible). In this case, the GUI daemon saved the new
state of the flag (and thus stopped applying its own constraints),
but it had not yet sent this flag to the X server.
2. Using an MSG_MAP GUI protocol [4] command to change the
override-redirect flag of a window that has already been mapped. In
this case, the attribute was updated in the X server, but the window
manager did not pick up the change, since the window was already
mapped.
3. The override-redirect protection feature, which prevents a window
from covering more than 90% of the screen if it has the
override-redirect flag, suffered from the same problem described in
the first point.
4. It was unclear how docked windows (aka "tray icons") should interact
with the override-redirect flag. Neither the XEmbed Protocol
Specification [5] nor the System Tray Protocol Specification [6]
defines how they should interact.
5. Docking a window passes control over mapping and unmapping the window
to the embedder (the application that "holds" the docked windows).
The implications of this behavior are unclear, and we cannot rule
out the possibility that this could be abused in some way.
6. There are two things that draw externally-imposed colored frames in
Qubes OS: the window manager and the GUI daemon. The GUI daemon draws
colored frames around windows with the override-redirect flag and
docked windows (aka "tray icons"), while the window manager draws all
other colored frames, e.g., for "normal" windows. (The window manager
also controls the noscript bar, which is another type of trusted window
decoration.)
Any window, including a docked window, can have a "child" window,
which is a separate window embedded in the parent window. Children do
not have the override-redirect flag, even when their parents do.
Children also do not have colored frames externally imposed by the
GUI daemon, even when their parents do.
Therefore, it is possible for a child window to extend its position
to cover the parent window's GUI-daemon-imposed colored frame, then
draw a fake frame in a different color directly on top of the parent
window's colored frame. A malicious qube could exploit this in order
to make it appear that a window belongs to a higher trust level than
its actual trust level.
Likewise, since the GUI daemon also forces coloring on docked windows
by default, a child window could cover its parent's docked window in
order to draw a "tray icon" in a different color.
To fix these problems, the GUI daemon will no longer accept changes to
the override-redirect flag in the cases described above. Instead, the
override-redirect flag can now be changed in only two cases:
- When the window is not yet visible (either as a normal window or as a
tray icon) and has no children
- When override-redirect protection forcefully clears the flag, in which
case the window is unmapped, the flag is cleared, and the window is
mapped again
Moreover, in order to avoid confusing the embedder and the GUI daemon,
windows that are already mapped or have children will now be prevented
from being docked.
Credits
--------
This issue was discovered by Demi Marie Obenour.
Notes
------
[1] In Qubes 4.1, certain GUI functions historically served by dom0 can
be delegated to separate template-based "GUI qubes." A single Qubes
4.1 system can have multiple GUI qubes.
[2] https://www.qubes-os.org/doc/testing/
[3] https://www.qubes-os.org/doc/how-to-update/
[4] https://www.qubes-os.org/doc/gui/
[5] https://specifications.freedesktop.org/xembed-spec/xembed-spec-latest.html
[6] https://specifications.freedesktop.org/systemtray-spec/systemtray-spec-latest.html
--
The Qubes Security Team
state of the flag (and thus stopped applying its own constraints),
but it had not yet sent this flag to the X server.
2. Using an MSG_MAP GUI protocol [4] command to change the
override-redirect flag of a window that has already been mapped. In
this case, the attribute was updated in the X server, but the window
manager did not pick up the change, since the window was already
mapped.
3. The override-redirect protection feature, which prevents a window
from covering more than 90% of the screen if it has the
override-redirect flag, suffered from the same problem described in
the first point.
4. It was unclear how docked windows (aka "tray icons") should interact
with the override-redirect flag. Neither the XEmbed Protocol
Specification [5] nor the System Tray Protocol Specification [6]
defines how they should interact.
5. Docking a window passes control over mapping and unmapping the window
to the embedder (the application that "holds" the docked windows).
The implications of this behavior are unclear, and we cannot rule
out the possibility that this could be abused in some way.
6. There are two things that draw externally-imposed colored frames in
Qubes OS: the window manager and the GUI daemon. The GUI daemon draws
colored frames around windows with the override-redirect flag and
docked windows (aka "tray icons"), while the window manager draws all
other colored frames, e.g., for "normal" windows. (The window manager
also controls the noscript bar, which is another type of trusted window
decoration.)
Any window, including a docked window, can have a "child" window,
which is a separate window embedded in the parent window. Children do
not have the override-redirect flag, even when their parents do.
Children also do not have colored frames externally imposed by the
GUI daemon, even when their parents do.
Therefore, it is possible for a child window to extend its position
to cover the parent window's GUI-daemon-imposed colored frame, then
draw a fake frame in a different color directly on top of the parent
window's colored frame. A malicious qube could exploit this in order
to make it appear that a window belongs to a higher trust level than
its actual trust level.
Likewise, since the GUI daemon also forces coloring on docked windows
by default, a child window could cover its parent's docked window in
order to draw a "tray icon" in a different color.
To fix these problems, the GUI daemon will no longer accept changes to
the override-redirect flag in the cases described above. Instead, the
override-redirect flag can now be changed in only two cases:
- When the window is not yet visible (either as a normal window or as a
tray icon) and has no children
- When override-redirect protection forcefully clears the flag, in which
case the window is unmapped, the flag is cleared, and the window is
mapped again
Moreover, in order to avoid confusing the embedder and the GUI daemon,
windows that are already mapped or have children will now be prevented
from being docked.
Credits
--------
This issue was discovered by Demi Marie Obenour.
Notes
------
[1] In Qubes 4.1, certain GUI functions historically served by dom0 can
be delegated to separate template-based "GUI qubes." A single Qubes
4.1 system can have multiple GUI qubes.
[2] https://www.qubes-os.org/doc/testing/
[3] https://www.qubes-os.org/doc/how-to-update/
[4] https://www.qubes-os.org/doc/gui/
[5] https://specifications.freedesktop.org/xembed-spec/xembed-spec-latest.html
[6] https://specifications.freedesktop.org/systemtray-spec/systemtray-spec-latest.html
--
The Qubes Security Team
Whonix 16 template available
https://www.qubes-os.org/news/2021/09/30/whonix-16-template-available/
The Whonix Project (https://www.whonix.org/) has announced the release of Whonix 16 (https://forums.whonix.org/t/12465). For a list of
changes and further details, please see the official announcement (https://forums.whonix.org/t/12465).
Please note that, according to the Whonix support schedule (https://www.whonix.org/wiki/About#Support_Schedule), Whonix 15 will
reach end-of-life (EOL) in one month. This coincides with the end date for
Whonix 15 template support in Qubes according to the Whonix Project’s support
policy for Whonix templates in Qubes (https://www.qubes-os.org/doc/supported-releases/#note-on-whonix-support). Therefore, all Whonix users are urged to
upgrade from Whonix 15 to Whonix 16 within the next month.
The Whonix Project provides instructions for installing fresh Whonix 16
templates (https://www.whonix.org/wiki/Qubes/Install) as well as instructions for performing an in-place upgrade from
Whonix 15 to Whonix 16 (https://www.whonix.org/wiki/Release_Upgrade_Whonix_15_to_Whonix_16).
https://www.qubes-os.org/news/2021/09/30/whonix-16-template-available/
The Whonix Project (https://www.whonix.org/) has announced the release of Whonix 16 (https://forums.whonix.org/t/12465). For a list of
changes and further details, please see the official announcement (https://forums.whonix.org/t/12465).
Please note that, according to the Whonix support schedule (https://www.whonix.org/wiki/About#Support_Schedule), Whonix 15 will
reach end-of-life (EOL) in one month. This coincides with the end date for
Whonix 15 template support in Qubes according to the Whonix Project’s support
policy for Whonix templates in Qubes (https://www.qubes-os.org/doc/supported-releases/#note-on-whonix-support). Therefore, all Whonix users are urged to
upgrade from Whonix 15 to Whonix 16 within the next month.
The Whonix Project provides instructions for installing fresh Whonix 16
templates (https://www.whonix.org/wiki/Qubes/Install) as well as instructions for performing an in-place upgrade from
Whonix 15 to Whonix 16 (https://www.whonix.org/wiki/Release_Upgrade_Whonix_15_to_Whonix_16).
XSAs released on 2021-10-05
https://www.qubes-os.org/news/2021/10/07/xsas-released-on-2021-10-05/
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-386 (in practice affects only Xen 4.14.3+ due to another bug that cancels out this security flaw; the other bug was fixed in 4.14.3, which exposed this flaw)
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/10/07/xsas-released-on-2021-10-05/
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-386 (in practice affects only Xen 4.14.3+ due to another bug that cancels out this security flaw; the other bug was fixed in 4.14.3, which exposed this flaw)
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/
Reproducible builds for Debian: a big step forward
https://www.qubes-os.org/news/2021/10/08/reproducible-builds-for-debian-a-big-step-forward/
This is the second article in the “reproducible builds” series.
Previously: Improvements in testing and building: GitLab CI and reproducible builds (https://www.qubes-os.org/news/2021/02/28/improvements-in-testing-and-building/).
In the previous article, Improvements in testing and building: GitLab CI and reproducible builds (https://www.qubes-os.org/news/2021/02/28/improvements-in-testing-and-building/#reproducible-builds), we discussed reproducible builds and our current short-term goals for them in Qubes OS. Notably, we aimed to start by building our Debian templates such that packages can be installed only when configured rebuilders confirm that they really came from the source code we publish. Today, we go beyond this expectation.
Reproducible builds: retrieve the past
The challenge in reproducible builds lies in rebuilding a package in the same environment in which it was officially published. This means that we need to retrieve every single package version that was used as dependency to rebuild a given package. For Debian, some packages in the current release were built several releases in the past but not necessarily with the exact same dependencies. In order to retrieve them, there is only one solution: a Debian service called snapshot.debian.org, which is an archive acting as a Wayback Machine (https://web.archive.org/) that allows access to old packages based on dates and version numbers. It contains all past and present packages that the Debian archive provides. Unfortunately, this service is known to suffer significant blocking issues on usability. For example, watch the DebConf 2021 talk Making use of snapshot.debian.org for fun and profit (https://debconf21.debconf.org/talks/22-making-use-of-snapshotdebianorg-for-fun-and-profit/) and have a look at some related Debian issues like #977653 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%977653), #960304 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%960304), #969906 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%969906), #969603 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%969603), and #782857 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=x2857). To summarize: There are throttling limits and availability issues such as repeatedly cutting off connections, returning partial content, etc. As announced in our previous article, we developed our own rebuilder tool, debrebuild (https://github.com/fepitre/debrebuild), which is able to rebuild a single Debian package together with a rebuilder orchestrator PackageRebuilder (https://github.com/fepitre/package-rebuilder). We started to put it in production in order to actively rebuild Qubes OS and Debian packages, but it quickly ceased to function, as the snapshot.debian.org service was unable to sustain the load of rebuilding even a single Debian package. That said, the question was: How should we proceed in order to make it work? Clearly, those issues are critical and make the snapshot.debian.org service awful or useless for reproducible builds.
Is rebuilding Debian really possible?
The snapshot.debian.org issues have still not been addressed even after several years. The service has existed for more than a decade, yet it still suffers from the aforementioned limitations. It’s either a design problem or a lack of resources, but we still had to do something.
That’s why we decided to create our own snapshot (https://github.com/fepitre/debian-snapshot) service. Easy to say, but not to do. First, the original snapshot service from Debian is roughly 90 TB of repository data. Second, we cannot download files easily because only HTTP(S) is available, and downloading multiple files means we are impeded by availability issues.
https://www.qubes-os.org/news/2021/10/08/reproducible-builds-for-debian-a-big-step-forward/
This is the second article in the “reproducible builds” series.
Previously: Improvements in testing and building: GitLab CI and reproducible builds (https://www.qubes-os.org/news/2021/02/28/improvements-in-testing-and-building/).
In the previous article, Improvements in testing and building: GitLab CI and reproducible builds (https://www.qubes-os.org/news/2021/02/28/improvements-in-testing-and-building/#reproducible-builds), we discussed reproducible builds and our current short-term goals for them in Qubes OS. Notably, we aimed to start by building our Debian templates such that packages can be installed only when configured rebuilders confirm that they really came from the source code we publish. Today, we go beyond this expectation.
Reproducible builds: retrieve the past
The challenge in reproducible builds lies in rebuilding a package in the same environment in which it was officially published. This means that we need to retrieve every single package version that was used as dependency to rebuild a given package. For Debian, some packages in the current release were built several releases in the past but not necessarily with the exact same dependencies. In order to retrieve them, there is only one solution: a Debian service called snapshot.debian.org, which is an archive acting as a Wayback Machine (https://web.archive.org/) that allows access to old packages based on dates and version numbers. It contains all past and present packages that the Debian archive provides. Unfortunately, this service is known to suffer significant blocking issues on usability. For example, watch the DebConf 2021 talk Making use of snapshot.debian.org for fun and profit (https://debconf21.debconf.org/talks/22-making-use-of-snapshotdebianorg-for-fun-and-profit/) and have a look at some related Debian issues like #977653 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%977653), #960304 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%960304), #969906 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%969906), #969603 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%969603), and #782857 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=x2857). To summarize: There are throttling limits and availability issues such as repeatedly cutting off connections, returning partial content, etc. As announced in our previous article, we developed our own rebuilder tool, debrebuild (https://github.com/fepitre/debrebuild), which is able to rebuild a single Debian package together with a rebuilder orchestrator PackageRebuilder (https://github.com/fepitre/package-rebuilder). We started to put it in production in order to actively rebuild Qubes OS and Debian packages, but it quickly ceased to function, as the snapshot.debian.org service was unable to sustain the load of rebuilding even a single Debian package. That said, the question was: How should we proceed in order to make it work? Clearly, those issues are critical and make the snapshot.debian.org service awful or useless for reproducible builds.
Is rebuilding Debian really possible?
The snapshot.debian.org issues have still not been addressed even after several years. The service has existed for more than a decade, yet it still suffers from the aforementioned limitations. It’s either a design problem or a lack of resources, but we still had to do something.
That’s why we decided to create our own snapshot (https://github.com/fepitre/debian-snapshot) service. Easy to say, but not to do. First, the original snapshot service from Debian is roughly 90 TB of repository data. Second, we cannot download files easily because only HTTP(S) is available, and downloading multiple files means we are impeded by availability issues.
In order to work around the huge volume of data, we decided to get repositories from 2017 to today (which corresponds approximately to when Debian “Buster” was released) and only related architectures amd64, source, and all. (all indicates no specific architecture in the Debian world.) For the download part itself, we needed to parse the metadata of each Debian repository in order to get the list of files to download for every timestamp for which a snapshot had been made. Then, we developed resume and retry download functions, which unfortunately are brute force download functions. For storing the data, a simple approach has been employed: storing files as SHA-256 names, then creating symlinks to reconstruct the repository layout. In order to get file information (package and repository metadata), we rely on simply reading a symlink. It took 3-4 months to get 4.2 TB of data, which represents 2017 to the present. Most of the information about the downloaded files and their source repository is stored in a database. In parallel, we added — like the original snapshot.debian.org — an API, snapshot-api (https://github.com/fepitre/debian-snapshot#API), to expose information about repositories. Unlike the original one, we added much more information that rebuilder software, e.g. debrebuild, needs to have when requesting package information, such as the exact location of a given package in terms of Debian archive, timestamp, suite, architecture and component. The service is now publicly exposed at https://snapshot.notset.fr (https://snapshot.notset.fr/) and the API endpoints at https://snapshot.notset.fr/mr. The service is home-hosted by the author.
This is exactly where the dream of rebuilding Debian packages in the same environment in which they were official published became a reality. Thanks to our standalone orchestrator and rebuilder software debrebuild, results of the rebuilding process, links to reproducible attestations called in-toto metadata (https://in-toto.io/), and even why a package is not reproducible can all be found at https://rebuild.notset.fr (https://rebuild.notset.fr/). As of this writing, we have successfully rebuilt more than 80% of the latest Debian packages for the unstable release while doing tests. Since it started, several adjustments have been made, and we have finally reached a stable rebuilding process. That is why, after a few late improvements during this almost first full rebuild, we flushed it all and started again for latest Debian stable release, Bullseye. We will again rebuild unstable after the full rebuild of Bullseye is complete. As time passes, we will have fewer and fewer pending tasks, as there are a couple thousand package rebuilds remaining. Please note that, in addition to the initial package build, the process of rebuilding a package means querying the snapshot.notset.fr API multiple times to get package information and location, set up the same environment as the original published one, and finally, actually build it. All of this is possible thanks to several servers, home-hosted by the author, that intensively build packages non-stop for more than a month.
What’s next?
For Qubes OS, we already track reproducibility status in our continuous integration (CI) tests (see the previous article (https://www.qubes-os.org/news/2021/02/28/improvements-in-testing-and-building/) for details), and they are also rebuilt independently like Debian packages in the same Package Rebuilder instance. We already have most of the reproducible attestations for our specific Debian packages (see https://rebuild.notset.fr/qubesos.html), and we will soon have all the needed ones for Debian. In consequence, we are happy to announce that we have already started the process of integrating the rebuild check status both at the build phase of our Debian templates and when later installing a package in the template itself. That’s the reason we restarted the whole process of a full rebuild for Bullseye.
This is exactly where the dream of rebuilding Debian packages in the same environment in which they were official published became a reality. Thanks to our standalone orchestrator and rebuilder software debrebuild, results of the rebuilding process, links to reproducible attestations called in-toto metadata (https://in-toto.io/), and even why a package is not reproducible can all be found at https://rebuild.notset.fr (https://rebuild.notset.fr/). As of this writing, we have successfully rebuilt more than 80% of the latest Debian packages for the unstable release while doing tests. Since it started, several adjustments have been made, and we have finally reached a stable rebuilding process. That is why, after a few late improvements during this almost first full rebuild, we flushed it all and started again for latest Debian stable release, Bullseye. We will again rebuild unstable after the full rebuild of Bullseye is complete. As time passes, we will have fewer and fewer pending tasks, as there are a couple thousand package rebuilds remaining. Please note that, in addition to the initial package build, the process of rebuilding a package means querying the snapshot.notset.fr API multiple times to get package information and location, set up the same environment as the original published one, and finally, actually build it. All of this is possible thanks to several servers, home-hosted by the author, that intensively build packages non-stop for more than a month.
What’s next?
For Qubes OS, we already track reproducibility status in our continuous integration (CI) tests (see the previous article (https://www.qubes-os.org/news/2021/02/28/improvements-in-testing-and-building/) for details), and they are also rebuilt independently like Debian packages in the same Package Rebuilder instance. We already have most of the reproducible attestations for our specific Debian packages (see https://rebuild.notset.fr/qubesos.html), and we will soon have all the needed ones for Debian. In consequence, we are happy to announce that we have already started the process of integrating the rebuild check status both at the build phase of our Debian templates and when later installing a package in the template itself. That’s the reason we restarted the whole process of a full rebuild for Bullseye.
There is preliminary work for integrating Fedora into the orchestrator, but that deserves a separate effort. The rebuilder rpmreproduce (https://github.com/fepitre/rpmreproduce) can be used to rebuild Fedora packages, but some discussions with RPM upstream are still needed (see https://github.com/rpm-software-management/rpm/pull/1532). Also, we plan to support input other than a buildinfo file for RPM, such as a Koji build denoscription (which is the build infrastructure used by Fedora and CentOS) or any denoscription piece that would make it clear how an RPM package was built. We also plan to add other distributions pretty easily and quickly, like Arch Linux, which we are going to ship officially soon.
Conclusion
Improved documentation for the orchestrator is in progress to make it easier for others who want to rebuild Qubes OS or Debian in the same way that we are currently doing it. Having more independent rebuilders publishing reproducibility attestations would be especially good for the community.
In all of these efforts, we are really satisfied that the Reproducible Builds Project (https://reproducible-builds.org/) has decided to use our work and results as an example of what it has been advocating for years, notably for Debian. The official website https://beta.tests.reproducible-builds.org (https://beta.tests.reproducible-builds.org/) currently mirrors our results website https://rebuild.notset.fr (https://rebuild.notset.fr/).
The author warmly thanks Marta Marczykowska-Górecka and Marek Marczykowski-Górecki for their moral support and technical discussions throughout this rough and intensive journey while juggling other projects.
Conclusion
Improved documentation for the orchestrator is in progress to make it easier for others who want to rebuild Qubes OS or Debian in the same way that we are currently doing it. Having more independent rebuilders publishing reproducibility attestations would be especially good for the community.
In all of these efforts, we are really satisfied that the Reproducible Builds Project (https://reproducible-builds.org/) has decided to use our work and results as an example of what it has been advocating for years, notably for Debian. The official website https://beta.tests.reproducible-builds.org (https://beta.tests.reproducible-builds.org/) currently mirrors our results website https://rebuild.notset.fr (https://rebuild.notset.fr/).
The author warmly thanks Marta Marczykowska-Górecka and Marek Marczykowski-Górecki for their moral support and technical discussions throughout this rough and intensive journey while juggling other projects.
Qubes OS 4.1-rc1 has been released!
https://www.qubes-os.org/news/2021/10/11/qubes-4-1-rc1/
After many years of work, the team is pleased to announce the first
release candidate for Qubes 4.1!
Qubes 4.1 includes several major new features, each of which is
explained in depth in its own article:
Qubes Architecture Next Steps: The GUI Domain (https://www.qubes-os.org/news/2020/03/18/gui-domain/)
Qubes Architecture Next Steps: The New Qrexec Policy System (https://www.qubes-os.org/news/2020/06/22/new-qrexec-policy-system/)
New Gentoo templates and maintenance infrastructure (https://www.qubes-os.org/news/2020/10/05/new-gentoo-templates-and-maintenance-infrastructure/)
Reproducible builds for Debian: a big step forward (https://www.qubes-os.org/news/2021/10/08/reproducible-builds-for-debian-a-big-step-forward/)
This release candidate also includes numerous other improvements and
bug fixes, which are listed in the release notes (https://www.qubes-os.org/doc/releases/4.1/release-notes/) and in the issue
tracker (https://github.com/QubesOS/qubes-issues/issues?q=milestone%3A%22Release+4.1%22+is%3Aclosed+-label%3A%22R%3A+duplicate%22+-label%3A%22R%3A+invalid%22+-label%3A%22R%3A+cannot+reproduce%22+-label%3A%22R%3A+not+an+issue%22+-label%3A%22R%3A+not+our+bug%22+-label%3A%22R%3A+won%27t+do%22+-label%3A%22R%3A+won%27t+fix%22+).
Finally, Qubes 4.1 features the following updated default components:
Xen 4.14
Fedora 32 in dom0
Fedora 34 template
Debian 11 template
Whonix 16 Gateway and Workstation templates
Linux kernel 5.10
Qubes 4.1-rc1 is available on the downloads (https://www.qubes-os.org/downloads/) page.
How to test Qubes 4.1-rc1
If you’re willing to test (https://www.qubes-os.org/doc/testing/) this release candidate, you can help to
improve the stable release by reporting any bugs you encounter (https://www.qubes-os.org/doc/issue-tracking/).
Experienced users are strongly encouraged to join the testing team (https://forum.qubes-os.org/t/joining-the-testing-team/5190)!
There are two ways to migrate to 4.1-rc1:
Back up (https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/#creating-a-backup) your current installation, perform a fresh install (https://www.qubes-os.org/doc/installation-guide/) of 4.1-rc1,
then restore (https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/#restoring-from-a-backup) from your backup.
Perform an in-place upgrade (https://www.qubes-os.org/doc/upgrade/4.1/).
Release candidate planning
As with any initial release candidate, it’s likely that user testing
will reveal important bugs that we’ll want to fix before the stable
release. Depending on the severity of the bugs discovered and how long
it takes to fix them, we expect that it may be anywhere from a few weeks
to a few months before we announce the second release candidate.
https://www.qubes-os.org/news/2021/10/11/qubes-4-1-rc1/
After many years of work, the team is pleased to announce the first
release candidate for Qubes 4.1!
Qubes 4.1 includes several major new features, each of which is
explained in depth in its own article:
Qubes Architecture Next Steps: The GUI Domain (https://www.qubes-os.org/news/2020/03/18/gui-domain/)
Qubes Architecture Next Steps: The New Qrexec Policy System (https://www.qubes-os.org/news/2020/06/22/new-qrexec-policy-system/)
New Gentoo templates and maintenance infrastructure (https://www.qubes-os.org/news/2020/10/05/new-gentoo-templates-and-maintenance-infrastructure/)
Reproducible builds for Debian: a big step forward (https://www.qubes-os.org/news/2021/10/08/reproducible-builds-for-debian-a-big-step-forward/)
This release candidate also includes numerous other improvements and
bug fixes, which are listed in the release notes (https://www.qubes-os.org/doc/releases/4.1/release-notes/) and in the issue
tracker (https://github.com/QubesOS/qubes-issues/issues?q=milestone%3A%22Release+4.1%22+is%3Aclosed+-label%3A%22R%3A+duplicate%22+-label%3A%22R%3A+invalid%22+-label%3A%22R%3A+cannot+reproduce%22+-label%3A%22R%3A+not+an+issue%22+-label%3A%22R%3A+not+our+bug%22+-label%3A%22R%3A+won%27t+do%22+-label%3A%22R%3A+won%27t+fix%22+).
Finally, Qubes 4.1 features the following updated default components:
Xen 4.14
Fedora 32 in dom0
Fedora 34 template
Debian 11 template
Whonix 16 Gateway and Workstation templates
Linux kernel 5.10
Qubes 4.1-rc1 is available on the downloads (https://www.qubes-os.org/downloads/) page.
How to test Qubes 4.1-rc1
If you’re willing to test (https://www.qubes-os.org/doc/testing/) this release candidate, you can help to
improve the stable release by reporting any bugs you encounter (https://www.qubes-os.org/doc/issue-tracking/).
Experienced users are strongly encouraged to join the testing team (https://forum.qubes-os.org/t/joining-the-testing-team/5190)!
There are two ways to migrate to 4.1-rc1:
Back up (https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/#creating-a-backup) your current installation, perform a fresh install (https://www.qubes-os.org/doc/installation-guide/) of 4.1-rc1,
then restore (https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/#restoring-from-a-backup) from your backup.
Perform an in-place upgrade (https://www.qubes-os.org/doc/upgrade/4.1/).
Release candidate planning
As with any initial release candidate, it’s likely that user testing
will reveal important bugs that we’ll want to fix before the stable
release. Depending on the severity of the bugs discovered and how long
it takes to fix them, we expect that it may be anywhere from a few weeks
to a few months before we announce the second release candidate.
QSB-073: Race condition when setting override-redirect flag
https://www.qubes-os.org/news/2021/10/15/qsb-073/
We have just published Qubes Security Bulletin (QSB) 073:
Race condition when setting override-redirect flag.
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-073 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-073-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 073 ]===---
2021-10-15
Race condition when setting override-redirect flag
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:
- qubes-gui-dom0 version 4.0.17
For Qubes 4.1, in dom0 and the template(s) of any GUI qube(s) [1]:
- qubes-gui-daemon version 4.1.18
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. [2] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [3]
The user session must be restarted afterward in order for the updates to
take effect, e.g., by logging out then logging back in.
Summary
--------
An override-redirect flag in the X11 protocol tells the window manager
not to manage a particular window. Windows with such flags do not get
their frames or noscript bars from the window manger, nor does the window
manager determine their positions. This feature is used for application
menus, tooltips, and similar accessory windows.
Unfortunately, some window managers get confused if the
override-redirect flag is set shortly before making the window visible.
When that happens, the window manager may try to move or resize the
window without respecting any size and position constraints imposed by
the GUI daemon. Normally, every window move and resize action requested
by the VM is validated by the GUI daemon. However, if the action is
initiated by the window manager, it doesn't require the GUI daemon's
validation.
Impact
-------
A malicious application may try to hide its unspoofable colored frame
off-screen. Hiding all four sides is prevented by another constraint
(forbidding a override-redirect window from covering more than 90% of
the screen), but hiding some sides is possible. The issue is known to
affect XFCE and KDE. Other desktop environments may also be affected.
Discussion
-----------
This is yet another corner case in handling the override-redirect flag.
In the long term, we will try to eliminate use of this flag completely.
As an immediate fix, we are adding additional validation of constraints
placed on windows with the override-redirect flag. This validation is
done whenever a window is moved or resized, regardless of what initiated
the action. If an illegal size or position is detected, the GUI daemon
will try to resize or move the window back to a legal size and position.
While this is a reactive solution (in the sense that it allows windows
to enter illegal states before correcting them), it will cover several
more cases, including the case in which another application resizes a
window behind the GUI daemon's back (which is the case being reported in
this QSB). Moreover, this solution serves as an additional safety check
in case the GUI daemon itself misses any other edge cases.
Credits
--------
This issue was discovered by Demi Marie Obenour.
Notes
------
[1] In Qubes 4.1, certain GUI functions historically served by dom0 can
be delegated to separate template-based "GUI qubes." A single Qubes
https://www.qubes-os.org/news/2021/10/15/qsb-073/
We have just published Qubes Security Bulletin (QSB) 073:
Race condition when setting override-redirect flag.
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-073 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-073-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 073 ]===---
2021-10-15
Race condition when setting override-redirect flag
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:
- qubes-gui-dom0 version 4.0.17
For Qubes 4.1, in dom0 and the template(s) of any GUI qube(s) [1]:
- qubes-gui-daemon version 4.1.18
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. [2] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [3]
The user session must be restarted afterward in order for the updates to
take effect, e.g., by logging out then logging back in.
Summary
--------
An override-redirect flag in the X11 protocol tells the window manager
not to manage a particular window. Windows with such flags do not get
their frames or noscript bars from the window manger, nor does the window
manager determine their positions. This feature is used for application
menus, tooltips, and similar accessory windows.
Unfortunately, some window managers get confused if the
override-redirect flag is set shortly before making the window visible.
When that happens, the window manager may try to move or resize the
window without respecting any size and position constraints imposed by
the GUI daemon. Normally, every window move and resize action requested
by the VM is validated by the GUI daemon. However, if the action is
initiated by the window manager, it doesn't require the GUI daemon's
validation.
Impact
-------
A malicious application may try to hide its unspoofable colored frame
off-screen. Hiding all four sides is prevented by another constraint
(forbidding a override-redirect window from covering more than 90% of
the screen), but hiding some sides is possible. The issue is known to
affect XFCE and KDE. Other desktop environments may also be affected.
Discussion
-----------
This is yet another corner case in handling the override-redirect flag.
In the long term, we will try to eliminate use of this flag completely.
As an immediate fix, we are adding additional validation of constraints
placed on windows with the override-redirect flag. This validation is
done whenever a window is moved or resized, regardless of what initiated
the action. If an illegal size or position is detected, the GUI daemon
will try to resize or move the window back to a legal size and position.
While this is a reactive solution (in the sense that it allows windows
to enter illegal states before correcting them), it will cover several
more cases, including the case in which another application resizes a
window behind the GUI daemon's back (which is the case being reported in
this QSB). Moreover, this solution serves as an additional safety check
in case the GUI daemon itself misses any other edge cases.
Credits
--------
This issue was discovered by Demi Marie Obenour.
Notes
------
[1] In Qubes 4.1, certain GUI functions historically served by dom0 can
be delegated to separate template-based "GUI qubes." A single Qubes
4.1 system can have multiple GUI qubes.
[2] https://www.qubes-os.org/doc/testing/
[3] https://www.qubes-os.org/doc/how-to-update/
--
The Qubes Security Team
https://www.qubes-os.org/security/
[2] https://www.qubes-os.org/doc/testing/
[3] https://www.qubes-os.org/doc/how-to-update/
--
The Qubes Security Team
https://www.qubes-os.org/security/
Fedora 33 approaching EOL; Fedora 34 templates available
https://www.qubes-os.org/news/2021/11/11/fedora-33-approaching-eol-fedora-34-templates-available/
Fedora 33 is scheduled to reach EOL (end-of-life (https://fedoraproject.org/wiki/End_of_life)) on 2021-11-30, and
new Fedora 34 templates are now available for both Qubes 4.0 and 4.1.
We strongly recommend that all Qubes users upgrade (https://www.qubes-os.org/doc/templates/fedora/#upgrading) their Fedora 33
templates and standalones to Fedora 34 before Fedora 33 reaches EOL.
We provide fresh Fedora 34 template packages through the official Qubes
repositories, which you can install in dom0 by following the standard
installation instructions (https://www.qubes-os.org/doc/templates/fedora/#installing). Alternatively, we also provide step-by-step
instructions for performing an in-place upgrade (https://www.qubes-os.org/doc/template/fedora/upgrade/) of an existing Fedora
template. After upgrading your templates, please remember to switch all
qubes that were using the old template to use the new one (https://www.qubes-os.org/doc/templates/#switching).
For a complete list of template releases supported for your specific
Qubes releases, see our supported template releases (https://www.qubes-os.org/doc/supported-releases/#templates).
Please note that no user action is required regarding the OS version in
dom0. For details, please see our note on dom0 and EOL (https://www.qubes-os.org/doc/supported-releases/#note-on-dom0-and-eol).
Note for 4.1 release candidate testers: Qubes R4.1-rc1 already
includes the Fedora 34 template by default, so no action is required.
https://www.qubes-os.org/news/2021/11/11/fedora-33-approaching-eol-fedora-34-templates-available/
Fedora 33 is scheduled to reach EOL (end-of-life (https://fedoraproject.org/wiki/End_of_life)) on 2021-11-30, and
new Fedora 34 templates are now available for both Qubes 4.0 and 4.1.
We strongly recommend that all Qubes users upgrade (https://www.qubes-os.org/doc/templates/fedora/#upgrading) their Fedora 33
templates and standalones to Fedora 34 before Fedora 33 reaches EOL.
We provide fresh Fedora 34 template packages through the official Qubes
repositories, which you can install in dom0 by following the standard
installation instructions (https://www.qubes-os.org/doc/templates/fedora/#installing). Alternatively, we also provide step-by-step
instructions for performing an in-place upgrade (https://www.qubes-os.org/doc/template/fedora/upgrade/) of an existing Fedora
template. After upgrading your templates, please remember to switch all
qubes that were using the old template to use the new one (https://www.qubes-os.org/doc/templates/#switching).
For a complete list of template releases supported for your specific
Qubes releases, see our supported template releases (https://www.qubes-os.org/doc/supported-releases/#templates).
Please note that no user action is required regarding the OS version in
dom0. For details, please see our note on dom0 and EOL (https://www.qubes-os.org/doc/supported-releases/#note-on-dom0-and-eol).
Note for 4.1 release candidate testers: Qubes R4.1-rc1 already
includes the Fedora 34 template by default, so no action is required.