Fedora 30 TemplateVM available
https://www.qubes-os.org/news/2019/05/30/fedora-30-template-available/

A new Fedora 30 TemplateVM is now available. We
previously announced that Fedora 28 reached EOL (https://www.qubes-os.org/news/2019/05/29/fedora-28-eol/) and encouraged users
to upgrade to Fedora 29. Fedora 29 is still supported by the Fedora
Project, so users may now choose either Fedora 29 or 30 (or both)
depending on their needs and preferences. Instructions are available
for upgrading from Fedora 29 to 30 (https://www.qubes-os.org/doc/template/fedora/upgrade-29-to-30/). We also provide fresh Fedora 30
TemplateVM packages through the official Qubes repositories, which you
can get with the following commands (in dom0).

Standard Fedora 30 TemplateVM:

$ sudo qubes-dom0-update qubes-template-fedora-30


Minimal (https://www.qubes-os.org/doc/templates/fedora-minimal/) Fedora 30 TemplateVM:

$ sudo qubes-dom0-update qubes-template-fedora-30-minimal


After upgrading to a Fedora 30 TemplateVM, please remember to set all
qubes that were using the old template to use the new one. This can be
done in dom0 either with the Qubes Template Manager (https://www.qubes-os.org/doc/templates/#how-to-switch-templates) or with the
qvm-prefs command-line tool.

Marek Marczykowski-Górecki to speak at Xen Developer and Design Summit 2019
https://www.qubes-os.org/news/2019/06/27/marek-marczykowski-gorecki-xen-summit-2019/

Marek Marczykowski-Górecki (https://www.qubes-os.org/team/#marek-marczykowski-g%C3%B3recki) will be speaking at this year’s Xen
Developer and Design Summit (https://events.linuxfoundation.org/events/xensummit-2019/). The summit will take place July 9–11 in
Chicago, Illinois. Marek’s presentation is noscriptd, “A Journey to Mirage
OS as Xen PVH.” Here is the denoscription from the Xen summit schedule (https://xensummit19.sched.com/event/PFW3/a-journey-to-mirage-os-as-xen-pvh-marek-marczykowski-gorecki-invisible-things-lab):


Marek will present difficulties faced during converting Mirage OS Xen
build from old PV-only Mini-OS fork, to recent Unikraft with addition
of PVH support. This talk will focus mostly on the latter part -
adding PVH support to Unikraft, its current state and future work.
There will be also a little of context how is that useful for Qubes
OS.


Please see the Xen summit schedule (https://xensummit19.sched.com/event/PFW3/a-journey-to-mirage-os-as-xen-pvh-marek-marczykowski-gorecki-invisible-things-lab) for further session details.

Whonix 15 has been released
https://www.qubes-os.org/news/2019/07/01/whonix-15-has-been-released/

The Whonix Project (https://www.whonix.org/) announced the release of Whonix 15 (https://forums.whonix.org/t/whonix-15-has-been-released/7616) today.
Project lead Patrick Schleizer (https://www.qubes-os.org/team/#patrick-schleizer) wrote:


After approximately one year of development, the Whonix Project is proud to announce the release of Whonix 15.

Whonix 15 is based on the Debian buster (Debian 10) distribution. This means users have access to many new software packages in concert with existing packages, such as a modern branch of GNuPG, and more.


For a list of major new features and further details, please see the official announcement (https://forums.whonix.org/t/whonix-15-has-been-released/7616).

Please note that, according to the Whonix Support Schedule (https://www.whonix.org/wiki/About#Support_Schedule), Whonix 14 will reach end-of-life (EOL) in one month.
Therefore, all current Whonix users are urged to upgrade from Whonix 14 to Whonix 15 (https://www.whonix.org/wiki/Upgrading_Whonix_14_to_Whonix_15) within the next month.

Qubes Canary #20
https://www.qubes-os.org/news/2019/07/04/canary-20/

We have published Qubes Canary #20. 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 #20 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-020-2019.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 #20 ]===---


Statements
-----------

The Qubes core developers who have digitally signed this file [1]
state the following:

1. The date of issue of this canary is July 3, 2019.

2. There have been 49 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 October 2019. 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
-------------------

$ date -R -u
Wed, 03 Jul 2019 23:32:11 +0000

$ feedstail -1 -n5 -f '{noscript}' -u https://www.spiegel.de/international/index.rss
No Way Back: Why Most Syrian Refugees Want to Stay in Germany
Lifelong Refugees: Ethiopia Is the Ultimate Destination for Many Fleeing Home
Former Secretary of Defense Panetta on Iran: 'You Can Create Chaos, but You'd Better Have a Plan'
'Hell Is Coming': What Lies Ahead for Europe's Climate
Amores Perros: The Paco-Addicted Youth of Buenos Aires

$ feedstail -1 -n5 -f '{noscript}' -u https://rss.nytimes.com/services/xml/rss/nyt/World.xml
Rouhani Says Iran Will Begin Enriching Uranium at Higher Level in Days
As Protests Rock Hong Kong, Xi Jinping’s View of History Shows He Will Dig In
Airstrike Kills Dozens of Migrants at Detention Center in Tripoli
Rahul Gandhi Resigns as Leader of India’s Congress Party
Ethiopian-Israelis Protest for 3rd Day After Fatal Police Shooting

$ feedstail -1 -n5 -f '{noscript}' -u https://feeds.bbci.co.uk/news/world/rss.xml
Stromboli: One dead as volcano erupts on Italian island
Wolf Pack ruling: New Spain sex attack trial reignites rape law debate
Boeing gives $100m to help 737 Max crash families
Manslaughter charges dropped against shot pregnant mum
Warehouse fire destroys 40,000 barrels of bourbon

$ feedstail -1 -n5 -f '{noscript}' -u http://feeds.reuters.com/reuters/worldnews

Frustration of surviving pricey Hong Kong stirs protest anger
26 dead in fishing boat accident off Honduran coast
Putin to meet pope in shadow of Ukraine crisis
Boeing makes $100 million pledge for 737 MAX crash-related support
At least 44 die as air strike hits Libya migrant detention center: U.N.

$ curl -s 'https://blockchain.info/blocks/?format=json' |\
python3 -c 'import sys, json; print(json.load(sys.stdin)['\''blocks'\''][10]['\''hash'\''])'
0000000000000000001afc39b5099b6b7f60700f44e82f44e0010099ce3519a0


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!

Qubes OS 4.0.2-rc1 has been released!
https://www.qubes-os.org/news/2019/07/09/qubes-4-0-2-rc1/

We’re pleased to announce the first release candidate for Qubes 4.0.2!

Features:
All 4.0 dom0 updates to date
Fedora 30 TemplateVM
Debian 10 TemplateVM
Whonix 15 Gateway and Workstation TemplateVMs
Linux kernel 4.19 by default
Qubes 4.0.2-rc1 is available on the Downloads (https://www.qubes-os.org/downloads/) page.

What is a point release?

A point release does not designate a separate, new version of Qubes OS.
Rather, it designates its respective major or minor release (in this
case, 4.0) inclusive of all updates up to a certain point. Installing
Qubes 4.0 and fully updating it results in the same system as installing
Qubes 4.0.2.

What should I do?

If you installed Qubes 4.0 or 4.0.1 and have fully updated (https://www.qubes-os.org/doc/updating-qubes-os/), then
your system is already equivalent to a Qubes 4.0.2 installation. No
further action is required.

Regardless of your current OS, if you wish to install (or reinstall)
Qubes 4.0 for any reason, then the 4.0.2 ISO makes this more convenient
and secure, since it bundles all Qubes 4.0 updates to date.

Release candidate planning

If no major issues are discovered in 4.0.2-rc1, we expect the stable
release of 4.0.2 to follow in a few weeks. As usual, you can help by
reporting any bugs you encounter (https://www.qubes-os.org/doc/reporting-bugs/).

XSA-300 does not affect the security of Qubes OS
https://www.qubes-os.org/news/2019/07/09/xsa-300-qubes-not-affected/

The Xen Project has published Xen Security Advisory 300 (XSA-300).
This XSA does not affect the security of Qubes OS, and no user
action is necessary.

This XSA has been added to the XSA Tracker (https://www.qubes-os.org/security/xsa/):

https://www.qubes-os.org/security/xsa/#300

Insurgo PrivacyBeast X230 Laptop meets and exceeds Qubes 4.0 hardware certification
https://www.qubes-os.org/news/2019/07/18/insurgo-privacybeast-qubes-certification/

We are very pleased to announce that the Insurgo PrivacyBeast X230 (https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/) has
passed Qubes 4.0 Hardware Certification and is now a Qubes-certified
Laptop (https://www.qubes-os.org/doc/certified-hardware/#qubes-certified-laptops)!

What is Qubes Certified Hardware?

Qubes Certified Hardware (https://www.qubes-os.org/doc/certified-hardware/) is hardware that has been certified by the
Qubes developers as compatible with Qubes OS. Beginning with Qubes 4.0,
in order to achieve certification, the hardware must satisfy a rigorous
set of requirements (https://www.qubes-os.org/doc/certified-hardware/#hardware-certification-requirements), and the vendor must commit to offering customers
the very same configuration (same motherboard, same screen, same BIOS
version, same Wi-Fi module, etc.) for at least one year.

Qubes-certified Laptops (https://www.qubes-os.org/doc/certified-hardware/#qubes-certified-laptops), in particular, are regularly tested
by the Qubes developers to ensure compatibility with all of Qubes’
features. The developers test all new major versions and updates to
ensure that no regressions are introduced.

It is important to note, however, that Qubes Hardware Certification
certifies only that a particular hardware configuration is supported
by Qubes. The Qubes OS Project takes no responsibility for any
manufacturing or shipping processes, nor can we control whether physical
hardware is modified (whether maliciously or otherwise) en route to
the user. (However, see below for information about how the Insurgo
team mitigates this risk.)

About the Insurgo PrivacyBeast X230 Laptop

The Insurgo PrivacyBeast X230 (https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/) is a custom refurbished ThinkPad X230 (https://www.thinkwiki.org/wiki/Category:X230)
that not only meets all Qubes Hardware Certification requirements (https://www.qubes-os.org/doc/certified-hardware/#hardware-certification-requirements)
but also exceeds them thanks to its unique configuration, including:


Coreboot (https://www.coreboot.org/) initialization for the x230 is binary-blob-free, including
native graphic initialization. Built with the
Heads (https://github.com/osresearch/heads/) payload, it delivers an Anti Evil Maid (AEM) (https://www.qubes-os.org/doc/anti-evil-maid/)-like solution
built into the firmware. (Even though our requirements (https://www.qubes-os.org/doc/certified-hardware/#hardware-certification-requirements) provide an
exception for CPU-vendor-provided blobs for silicon and memory
initialization, Insurgo exceeds our requirements by insisting that
these be absent from its machines.)


Intel ME (https://libreboot.org/faq.html#intelme) is neutered through the AltMeDisable bit, while all
modules other than ROMP and BUP, which are required to initialize
main CPU, have been deleted (https://github.com/osresearch/heads-wiki/blob/master/Clean-the-ME-firmware.md#how-to-disabledeactive-most-of-it).


A re-ownership process that allows it to ship pre-installed with
Qubes OS, including full-disk encryption already in place, but
where the final disk encryption key is regenerated only when the
machine is first powered on by the user, so that the OEM doesn’t
know it.


Heads (https://github.com/osresearch/heads/) provisioned pre-delivery to protect against malicious
interdiction (https://en.wikipedia.org/wiki/Interdiction).

How to get one

Please visit the Insurgo PrivacyBeast X230 (https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/) on the Insurgo website (https://insurgo.ca/)
for more information.

Acknowledgements

Special thanks go to:

Thierry Laurion (https://www.linkedin.com/in/thierry-laurion-40b4128/), Director of Insurgo, Technologies Libres (Open
Technologies), for spearheading this effort and making Heads+Qubes
laptops more broadly accessible
Trammell Hudson (https://trmm.net/About), for creating Heads (https://github.com/osresearch/heads/)
Purism (https://puri.sm/), for greatly improving the UX of Heads (https://github.com/osresearch/heads/), including the GUI
menu, and for adding Nitrokey (https://www.nitrokey.com/) and Librem Key (https://puri.sm/posts/introducing-the-librem-key/) support

QSB #050: Reinstalling a TemplateVM does not reset the private volume
https://www.qubes-os.org/news/2019/07/24/qsb-050/

We have just published Qubes Security Bulletin (QSB) #050:
Reinstalling a TemplateVM does not reset the private volume.
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 #050 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-050-2019.txt

Learn about the qubes-secpack, including how to obtain, verify, and read it:

https://www.qubes-os.org/security/pack/

View all past QSBs:

https://www.qubes-os.org/security/bulletins/



---===[ Qubes Security Bulletin #50 ]===---

2019-07-24


Reinstalling a TemplateVM does not reset the private volume

Denoscription
===========

In Qubes OS, we have the ability to reinstall a TemplateVM by running
`qubes-dom0-update --action=reinstall qubes-template-...` in dom0. [1]
This is supposed to reset the corresponding TemplateVM to the state of
the published package, i.e., no local changes should remain.

One uncommon reason to perform such a reinstallation is that you suspect
that a TemplateVM may be compromised. In such cases, it is very
important that no local changes persist in order to ensure that the
TemplateVM is no longer compromised.

Due to a regression in R4.0 [2], however, reinstalling a TemplateVM
using qubes-dom0-update does not completely reset all local changes to
that TemplateVM. Although the tool itself and our documentation claim
that the private volume of the TemplateVM is reset during
reinstallation, the private volume does not actually get reset. This
could allow a TemplateVM to remain compromised across a reinstallation
of that TemplateVM using qubes-dom0-update.

Workaround
==========

Fixed packages are forthcoming. In the meantime, we recommend avoiding
the qubes-dom0-update method of reinstalling a TemplateVM. Instead, we
recommend manually removing the TemplateVM, then installing it again.
Detailed instructions for this manual method are documented here:

https://www.qubes-os.org/doc/reinstall-template/#manual-method

(Note that we have updated this page with a warning against the
automatic method.)

Patching
=========

We expect to have fixed packages available next week. In the meantime,
please follow the workaround described in the previous section. We will
update this QSB when fixed packages are available.

Credits
========

Thank you to Andrey Bienkowski for
discovering and reporting this issue.

References
===========

[1] https://www.qubes-os.org/doc/reinstall-template/
[2] https://github.com/QubesOS/qubes-core-admin-linux/commit/552fd062ea2bb6c2d05faa1e64e172503cacbdbf#diff-6b87ee5cdb9e63b703415a14e5a505cdL192

--
The Qubes Security Team
https://www.qubes-os.org/security/

Xen Project Developer and Design Summit Recap
https://xenproject.org/2019/07/29/xen-project-developer-and-design-summit-recap/

3 weeks ago, the Xen Project developer community gathered in Chicago to collaborate, connect and solve the important challenges we all face. As always we kicked off the Summit with...

Everyone here, if you could, go on Twitter and tweet at twitter.com/qubesos with this link:
t.me/QubesOS.

The community must expand! If you could, use #QubesOS in your post.

Also, here's the link to our unofficial support group for Qubes OS: https://news.1rj.ru/str/joinchat/B8FHpkEToMfgdREGV7wzRQ

Announcing our 2019 Season of Docs project: Onboard with Qubes OS!
https://www.qubes-os.org/news/2019/08/07/announcing-our-2019-season-of-docs-project/

The Season of Docs program has announced (https://opensource.googleblog.com/2019/08/season-of-docs-announces-technical.html) the technical writing projects chosen for 2019.
We are pleased to congratulate Lukas à Porta (aka luzeal) (https://groups.google.com/d/topic/qubes-project/0AdqOTpuW1Q/discussion) on the selection of his project: Onboard with Qubes OS! (https://developers.google.com/season-of-docs/docs/participants/project-qubes)

We received many excellent proposals from talented writers.
Unfortunately, we had to choose just a single one, and this decision was extremely difficult.
Regardless of whether you applied or your proposal was accepted, we invite you to collaborate on the Qubes documentation (https://www.qubes-os.org/doc/doc-guidelines/).
The documentation is primarily a community effort, and it only gets better when you get involved!

QSB #051: Insufficient validation of backup compression filter on restore
https://www.qubes-os.org/news/2019/09/10/qsb-051/

We have just published Qubes Security Bulletin (QSB) #051:
Insufficient validation of backup compression filter on restore.
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 #051 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-051-2019.txt

Learn about the qubes-secpack, including how to obtain, verify, and read it:

https://www.qubes-os.org/security/pack/

View all past QSBs:

https://www.qubes-os.org/security/bulletins/



---===[ Qubes Security Bulletin #51 ]===---

2019-09-10

Insufficient validation of backup compression filter on restore


Summary
=======

The Qubes backup format has an option for user-selected compression
filters. While Qubes backups are authenticated and encrypted, the choice
of compression filter in a given backup is not further validated on
restore. Under specific conditions, an attacker capable of circumventing
backup authentication could exploit the lack of compression filter
validation in order to execute arbitrary commands when a backup is
restored.

Impact
======

In Qubes OS, backups are encrypted and authenticated using a passphrase.
You must enter your backup passphrase when attempting to restore a
backup. If your passphrase successfully authenticates the backup, it
will be decrypted and restored. Otherwise, the operation will be aborted
before the contents of the backup are further processed.

In order to exploit this vulnerability, an attacker would have to create
a malicious backup that would successfully pass authentication and
induce you to restore it. In practice, this means that the attacker
would effectively have to (1) learn your backup passphrase and (2)
replace one of your backups with a malicious version. If the attacker is
unable to achieve either condition (or an equivalent), the vulnerability
cannot be exploited.

Therefore, if you have only restored backups protected by strong, secret
passphrases, then you are not affected. Likewise, if you have only
restored backups from trusted, secure locations, then you are not
affected. However, if you have ever restored a backup with a weak or
non-secret passphrase that was also stored in an untrusted location,
then your system may be compromised. This bug can be exploited reliably
and silently only when both conditions are met.

(Note: In this context, "restoring" a backup also includes use of the
Qubes "verify backup" functionality, since verification works by
simulating the restore process.)

Details
=======

The ability to use a user-specified "compression filter" (in practice:
an argument to `tar -I`/`tar --use-compress-program`) was introduced in
Qubes Backup Format Version 3. [1] Alternate compression programs are
specified by the user via `qvm-backup --compress-filter [...]` and are
stored in the backup metadata. Originally, they were stored in the
`compressed` header field, then later in the `compression-filter` field.
The whole backup, including its metadata, is authenticated via an HMAC
with the backup passphrase. There is no further validation of the
contents of the specific `compressed` or `compression-filter` field.

In order to exploit this vulnerability, an attacker would have to create
or modify a backup for the user to restore. In order for the HMAC
authentication to succeed, the attacker would have to know the
passphrase that the user will enter when attempting to restore, e.g., by
cracking the user's passphrase or somehow inducing the user to enter a
passphrase provided by the attacker. Furthermore, the attacker would
have to induce the user to select the attacker's malicious backup for a
restore operation, e.g., by replacing one of the user's genuine backups

with a malicious version (which would require that the attacker have
write access to the user's backup storage location) or somehow
convincing the user to restore a backup provided by the attacker.

The internal structure of backups is one outer uncompressed
multi-session-concatinated (via `tar -A`) tar archive. The first session
contains an uncompressed and unauthenticated `backup-header`. This
untrusted backup header file is initially only inspected to determine
the backup archive format to determine how to proceed with further
extraction. The following tar sessions contain a `backup-header.hmac`
file used to authenticate the backup header before deeper inspection,
and other files (qubes.xml, vmXX/{private,etc.}.img) which are each
wrapped in their own tar archives and then wrapped in their own
encryption and authentication.

Since qubes.xml is itself contained in an inner potentially-compressed
tar archive, the decompression filter is also used when verifying a
backup, i.e., when the `--verify-only` flag is passed to
`qvm-backup-restore` or when the "Verify backup integrity, do not
restore the data" option is selected in the "Restore qubes" GUI tool.

Patching
========

Note: Patching is not sufficient to recover from a compromised state. If
you suspect you may have restored a malicious backup, see the next
section for details and recommendations.

The specific package that resolves the problems discussed in this
bulletin are as follows:

For Qubes 4.0:
- qubes-core-admin-client version 4.0.27

The packages are to be installed in dom0 via the Qubes VM Manager or via
the qubes-dom0-update command as follows:

For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update

For updates from the security-testing repository:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing

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.

Securely Restoring from Backups
===============================

The safest way to restore from a backup is to do the actual backup
processing outside dom0.

1. Install the `qubes-core-admin-client` package in a domU.

2. Authorize the appropriate qrexec policies in the domU:

- admin.vm.Create.AppVM
- admin.vm.Create.TemplateVM
- admin.vm.Create.StandaloneVM
- include/admin-local-rwx
- include/admin-global-ro

3. Use `qvm-backup-restore` in the domU.

In a subsequent update, the above procedure will be automated with a new
`qvm-backup-restore --paranoid-mode` option. See "Compromise recovery in
Qubes OS" for details about how to use this mode. [2]

Indicators of Compromise
========================

It is possible to manually inspect the header of a backup to observe
whether the vulnerability has been exploited. To do so, inspect the
backup as follows:

1. Verify the backup header integrity according to the "emergency backup
restore without Qubes" instructions for your backup. These vary
depending on the age of the backup, as the format has changed over
time. [3][4][5][6]

2. Check the "compressed" and "compression-filter" header fields for
anything anomalous. For example, you may see something like the
following:

$ tar -ivxf qubes-2019-08-06T121200 backup-header{,.hmac}
backup-header
backup-header.hmac
$ scrypt dec backup-header.hmac backup-header.ok
Please enter passphrase: backup-header!
$ cmp backup-header.ok backup-header && echo ok || echo wrong
ok
$ grep -E '^(compressed|compression-filter)=' backup-header | cat -v
compressed=True
compression-filter=gzip

If you see anything other than `True` and a legitimate compression
filter like `gzip` or `bzip2`, this may be a reason for suspicion.

It is worth noting, however, that depending on how a malicious backup
has been stored and/or transferred to the machine on which it is

restored -- and depending on the sophistication of an attacker -- a
previously malicious backup may have self-modified to appear benign
after the fact as part of its exploit payload. Therefore, this should
not be considered an infallible way to detect malicious backups. Storing
the backup exclusively on immutable media throughout this process can
provide further assurance.

The possibility of other similar vulnerabilities cannot be completely
ruled out, so restoring backups in a deprivileged manner (outside dom0,
as described in the previous section) is still recommended.

Credits
=======

This issue was discovered and reported by Jean-Philippe Ouellet
, who also provided a fix, a PoC exploit, helped with
mitigations for this general class of issue in the future, and wrote the
initial draft of this advisory.

References
==========

[1] https://github.com/QubesOS/qubes-core-admin/commit/0cd8281ac10ee06f4b2fce9f86e27eb25292bc25
[2] https://www.qubes-os.org/news/2017/04/26/qubes-compromise-recovery/
[3] https://www.qubes-os.org/doc/backup-restore/
[4] https://www.qubes-os.org/doc/backup-emergency-restore-v4/
[5] https://www.qubes-os.org/doc/backup-emergency-restore-v3/
[6] https://www.qubes-os.org/doc/backup-emergency-restore-v2/

--
The Qubes Security Team
https://www.qubes-os.org/security/

Upcoming Qubes presentations at Platform Security Summit 2019
https://www.qubes-os.org/news/2019/09/18/qubes-presentations-at-platform-security-summit-2019/

There will be two separate Qubes presentations at this year’s Platform Security Summit (https://www.platformsecuritysummit.com/).

Marek Marczykowski-Górecki (https://www.qubes-os.org/team/#marek-marczykowski-g%C3%B3recki)’s presentation in the Hypervisor category is noscriptd, “Complexity Everywhere: is it time to step back and rethink our platforms?” (https://www.platformsecuritysummit.com/#marek)

Meanwhile, Thierry Laurion (https://www.linkedin.com/in/thierry-laurion-40b4128/) of Insurgo Open Technologies (https://insurgo.ca/) will give a presentation in the Boot Integrity category noscriptd, “Accessible Security: deploying Qubes reasonably secured OS on slightly more secured hardware. An OEM approach to transferring device and secrets ownership.” (https://www.platformsecuritysummit.com/#laurion)

We recently announced that Insurgo’s PrivacyBeast X230 passed Qubes 4.0 hardware certification (https://www.qubes-os.org/news/2019/07/18/insurgo-privacybeast-qubes-certification/) to become a Qubes-certified Laptop (https://www.qubes-os.org/doc/certified-hardware/#qubes-certified-laptop-insurgo-privacybeast-x230).

The summit will take place October 1–3 in Redmond, Washington.

Xen Project Partners With Outreachy to Promote and Sustain More Diverse and Inclusive Open Source Ecosystem
https://xenproject.org/2019/09/24/xen-project-partners-with-outreachy-to-promote-and-sustain-more-diverse-and-inclusive-open-source-ecosystem/

The Xen Project is excited to be participating in the Outreachy internship program which supports diversity in free and open source software. The Xen Project’s participation in this year’s program...

ANNOUNCING THE XEN PROJECT 4.13 RC AND TEST DAY SCHEDULES
https://xenproject.org/2019/10/14/announcing-the-xen-project-4-13-rc-and-test-day-schedules/

Today, we created Xen 4.13 RC1 and will release a new release candidate every MONDAY, until we declare a release candidate as the final candidate and cut the Xen 4.13...