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...
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
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
Twitter
Qubes OS (@QubesOS) / Twitter
A reasonably secure operating system for personal computers.
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!
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
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
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/
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.
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...
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...
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...
Qubes Canary #21
https://www.qubes-os.org/news/2019/10/13/canary-21/
We have published Qubes Canary #21. 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 #21 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-021-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 #21 ]===---
Statements
-----------
The Qubes core developers who have digitally signed this file [1]
state the following:
1. The date of issue of this canary is October 13, 2019.
2. There have been 51 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
three weeks of January 2020. 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
-------------------
Sun, 13 Oct 2019 19:51:40 +0000
Source: SPIEGEL ONLINE - International (https://www.spiegel.de/international/index.rss)
Far-Right Terrorism: Deadly Attack Exposes Lapses in German Security Apparatus
Opinion: This Isn't the Drill, It's the Catastrophe
The PiS Dynasty: Kaczynski Party in Control Ahead of Polish Vote
Time To Act: Trump's Impeachment Inquiry Is Imperative for the World
Predictable Chaos: Europe Braces for the Effects of Brexit
Source: NYT > World News (https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
Hundreds of ISIS Supporters Flee Detention Amid Turkish Airstrikes
12 Hours. 4 Syrian Hospitals Bombed. One Culprit: Russia.
Typhoon Hagibis: Helicopters and Boats Rescue the Stranded
Police Officer is Stabbed in Hong Kong During Flash-Mob Protests
Pullback Leaves Green Berets Feeling ‘Ashamed,’ and Kurdish Allies Describing ‘Betrayal’
Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
Turkey-Syria offensive: US to evacuate 1,000 troops as Turkey advances
Hong Kong protests: President Xi warns of 'crushed bodies'
Black woman shot dead by Texas police through bedroom window
Simone Biles wins record 24th world medal
Hunter Biden to step down from China board amid Trump attacks
Source: Reuters: World News (http://feeds.reuters.com/reuters/worldnews)
Exclusive: U.S. could pull bulk of troops from Syria in matter of days - officials
https://www.qubes-os.org/news/2019/10/13/canary-21/
We have published Qubes Canary #21. 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 #21 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-021-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 #21 ]===---
Statements
-----------
The Qubes core developers who have digitally signed this file [1]
state the following:
1. The date of issue of this canary is October 13, 2019.
2. There have been 51 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
three weeks of January 2020. 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
-------------------
Sun, 13 Oct 2019 19:51:40 +0000
Source: SPIEGEL ONLINE - International (https://www.spiegel.de/international/index.rss)
Far-Right Terrorism: Deadly Attack Exposes Lapses in German Security Apparatus
Opinion: This Isn't the Drill, It's the Catastrophe
The PiS Dynasty: Kaczynski Party in Control Ahead of Polish Vote
Time To Act: Trump's Impeachment Inquiry Is Imperative for the World
Predictable Chaos: Europe Braces for the Effects of Brexit
Source: NYT > World News (https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
Hundreds of ISIS Supporters Flee Detention Amid Turkish Airstrikes
12 Hours. 4 Syrian Hospitals Bombed. One Culprit: Russia.
Typhoon Hagibis: Helicopters and Boats Rescue the Stranded
Police Officer is Stabbed in Hong Kong During Flash-Mob Protests
Pullback Leaves Green Berets Feeling ‘Ashamed,’ and Kurdish Allies Describing ‘Betrayal’
Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
Turkey-Syria offensive: US to evacuate 1,000 troops as Turkey advances
Hong Kong protests: President Xi warns of 'crushed bodies'
Black woman shot dead by Texas police through bedroom window
Simone Biles wins record 24th world medal
Hunter Biden to step down from China board amid Trump attacks
Source: Reuters: World News (http://feeds.reuters.com/reuters/worldnews)
Exclusive: U.S. could pull bulk of troops from Syria in matter of days - officials
Exit polls project Tunisian landslide win for Kais Saied
Poland's ruling nationalists set to win election: exit poll
U.S. to pull last troops from north Syria as Turkey presses offensive against Kurds
Russia takes part in talks between Syria and Kurdish-led SDF
Source: Blockchain.info
0000000000000000000a3b269b65134283e4f4e089768704b80727a31bdadd14
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!
Poland's ruling nationalists set to win election: exit poll
U.S. to pull last troops from north Syria as Turkey presses offensive against Kurds
Russia takes part in talks between Syria and Kurdish-led SDF
Source: Blockchain.info
0000000000000000000a3b269b65134283e4f4e089768704b80727a31bdadd14
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!
QSB #052: Xen issues affecting PCI passthrough and PV domains (XSA-299, XSA-302)
https://www.qubes-os.org/news/2019/10/31/qsb-052/
We have just published Qubes Security Bulletin (QSB) #052:
Xen issues affecting PCI passthrough and PV domains (XSA-299, XSA-302).
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 #052 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-052-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 #52 ]===---
2019-10-31
Xen issues affecting PCI passthrough and PV domains (XSA-299, XSA-302)
Summary
========
On 2019-10-31, the Xen Security Team published the following Xen
Security Advisories (XSAs):
XSA-299 [1] "Issues with restartable PV type change operations":
| To avoid using shadow pagetables for PV guests, Xen exposes the actual
| hardware pagetables to the guest. In order to prevent the guest from
| modifying these page tables directly, Xen keeps track of how pages are
| used using a type system; pages must be "promoted" before being used
| as a pagetable, and "demoted" before being used for any other type.
| Xen also allows for "recursive" promotions: i.e., an operating system
| promoting a page to an L4 pagetable may end up causing pages to be
| promoted to L3s, which may in turn cause pages to be promoted to L2s,
| and so on. These operations may take an arbitrarily large amount of
| time, and so must be re-startable.
|
| Unfortunately, making recursive pagetable promotion and demotion
| operations restartable is incredibly complicated, and the code
| contains several races which, if triggered, can cause Xen to drop or
| retain extra type counts, potentially allowing guests to get write
| access to in-use pagetables.
|
| A malicious PV guest administrator may be able to escalate their
| privilege to that of the host.
XSA-302 [2] "passed through PCI devices may corrupt host memory after
deassignment":
| When a PCI device is assigned to an untrusted domain, it is possible
| for that domain to program the device to DMA to an arbitrary address.
| The IOMMU is used to protect the host from malicious DMA by making
| sure that the device addresses can only target memory assigned to the
| guest. However, when the guest domain is torn down the device is
| assigned back to dom0, thus allowing any in-flight DMA to potentially
| target critical host data.
|
| An untrusted domain with access to a physical device can DMA into host
| memory, leading to privilege escalation.
Impact
=======
XSA-299 applies only to PV domains. Most of the domains in Qubes 4.0 are
PVH or HVM domains and are therefore not affected by XSA-299. However,
PV domains are still supported in Qubes 4.0, and they are specifically
used to host Qemu-instance-supporting HVM domains.
In the default Qubes 4.0 setup, several attacks would have to be chained
together in order to exploit this vulnerability. Specifically, an
attacker would have to:
1. Take control of an HVM domain, e.g., sys-usb, sys-net, or a
user-created HVM domain. (Most user domains are PVH and are therefore
not affected.)
2. Successfully attack a Qemu instance running in an associated PV
stubdomain.
3. Finally, find some way to exploit the vulnerability described in
XSA-299.
Moreover, since this vulnerability is a race condition, it is an
unreliable attack vector in real world scenarios.
XSA-302 also affects a limited set of domains in Qubes, namely, only
those with PCI devices assigned (sys-net and sys-usb in the default
configuration).
In order to exploit this vulnerability, an attacker would have to
control a cooperating device that could be programmed to perform a DMA
https://www.qubes-os.org/news/2019/10/31/qsb-052/
We have just published Qubes Security Bulletin (QSB) #052:
Xen issues affecting PCI passthrough and PV domains (XSA-299, XSA-302).
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 #052 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-052-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 #52 ]===---
2019-10-31
Xen issues affecting PCI passthrough and PV domains (XSA-299, XSA-302)
Summary
========
On 2019-10-31, the Xen Security Team published the following Xen
Security Advisories (XSAs):
XSA-299 [1] "Issues with restartable PV type change operations":
| To avoid using shadow pagetables for PV guests, Xen exposes the actual
| hardware pagetables to the guest. In order to prevent the guest from
| modifying these page tables directly, Xen keeps track of how pages are
| used using a type system; pages must be "promoted" before being used
| as a pagetable, and "demoted" before being used for any other type.
| Xen also allows for "recursive" promotions: i.e., an operating system
| promoting a page to an L4 pagetable may end up causing pages to be
| promoted to L3s, which may in turn cause pages to be promoted to L2s,
| and so on. These operations may take an arbitrarily large amount of
| time, and so must be re-startable.
|
| Unfortunately, making recursive pagetable promotion and demotion
| operations restartable is incredibly complicated, and the code
| contains several races which, if triggered, can cause Xen to drop or
| retain extra type counts, potentially allowing guests to get write
| access to in-use pagetables.
|
| A malicious PV guest administrator may be able to escalate their
| privilege to that of the host.
XSA-302 [2] "passed through PCI devices may corrupt host memory after
deassignment":
| When a PCI device is assigned to an untrusted domain, it is possible
| for that domain to program the device to DMA to an arbitrary address.
| The IOMMU is used to protect the host from malicious DMA by making
| sure that the device addresses can only target memory assigned to the
| guest. However, when the guest domain is torn down the device is
| assigned back to dom0, thus allowing any in-flight DMA to potentially
| target critical host data.
|
| An untrusted domain with access to a physical device can DMA into host
| memory, leading to privilege escalation.
Impact
=======
XSA-299 applies only to PV domains. Most of the domains in Qubes 4.0 are
PVH or HVM domains and are therefore not affected by XSA-299. However,
PV domains are still supported in Qubes 4.0, and they are specifically
used to host Qemu-instance-supporting HVM domains.
In the default Qubes 4.0 setup, several attacks would have to be chained
together in order to exploit this vulnerability. Specifically, an
attacker would have to:
1. Take control of an HVM domain, e.g., sys-usb, sys-net, or a
user-created HVM domain. (Most user domains are PVH and are therefore
not affected.)
2. Successfully attack a Qemu instance running in an associated PV
stubdomain.
3. Finally, find some way to exploit the vulnerability described in
XSA-299.
Moreover, since this vulnerability is a race condition, it is an
unreliable attack vector in real world scenarios.
XSA-302 also affects a limited set of domains in Qubes, namely, only
those with PCI devices assigned (sys-net and sys-usb in the default
configuration).
In order to exploit this vulnerability, an attacker would have to
control a cooperating device that could be programmed to perform a DMA
(direct memory access) attack with a sufficient delay (on the order of
seconds) such that the device had been reassigned to dom0 by the time
the attack occured.
Depending on internal connections, it may be also necessary for the
cooperating device to lack proper support for Function Level Reset
(FLR). (Most USB controllers do, in fact, lack proper support for FLR.)
While XSA-299 is unreliable to exploit in practice, XSA-302 can be
reliably exploited so long as all the aforementioned conditions are met.
Discussion
===========
The patches below isolate PCI devices out of dom0 using IOMMU, even
after those devices have been de-assigned from other domains (typically
less trusted domains like sys-net and sys-usb).
However, PCI devices can still perform DMA into most of the host memory
during early system startup (before dom0 assigns them to specific
domains). If the attacker were to program such a device to perform a DMA
attack in this window of opportunity during system startup, the
attacker could still compromise the system, even with the XSA-302
patches applied.
In practice, this means that devices containing internal writable
firmware or configuration storage are worse for system security than
those that have read-only storage and require firmware to be loaded
externally by a driver. Many people consider devices that require
loading "firmware blobs" to be less freedom-friendly, but the effect on
system trustworthiness is exactly the opposite. Such devices are
actually more trustworthy than those that have (possibly mutable)
firmware stored internally.
In addition, it's easier to reason about the firmware when it is
accessible to the user. Even if the firmware is in a binary form, it is
at least possible to verify its authenticity and that it wasn't modified
maliciously to target your specific device (e.g., by comparing hashes
against a public database). Naturally, a device with open-source
firmware (still loaded externally) would be even better. In the vast
majority of cases, however, a device that doesn't require loading
external firmware actually still has such firmware -- it's just hidden
inside and impossible to attest.
Patching
=========
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes OS 4.0:
- Xen packages version 4.8.5-11
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.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.
Credits
========
See the original Xen Security Advisories.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-299.html
[2] https://xenbits.xen.org/xsa/advisory-302.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
seconds) such that the device had been reassigned to dom0 by the time
the attack occured.
Depending on internal connections, it may be also necessary for the
cooperating device to lack proper support for Function Level Reset
(FLR). (Most USB controllers do, in fact, lack proper support for FLR.)
While XSA-299 is unreliable to exploit in practice, XSA-302 can be
reliably exploited so long as all the aforementioned conditions are met.
Discussion
===========
The patches below isolate PCI devices out of dom0 using IOMMU, even
after those devices have been de-assigned from other domains (typically
less trusted domains like sys-net and sys-usb).
However, PCI devices can still perform DMA into most of the host memory
during early system startup (before dom0 assigns them to specific
domains). If the attacker were to program such a device to perform a DMA
attack in this window of opportunity during system startup, the
attacker could still compromise the system, even with the XSA-302
patches applied.
In practice, this means that devices containing internal writable
firmware or configuration storage are worse for system security than
those that have read-only storage and require firmware to be loaded
externally by a driver. Many people consider devices that require
loading "firmware blobs" to be less freedom-friendly, but the effect on
system trustworthiness is exactly the opposite. Such devices are
actually more trustworthy than those that have (possibly mutable)
firmware stored internally.
In addition, it's easier to reason about the firmware when it is
accessible to the user. Even if the firmware is in a binary form, it is
at least possible to verify its authenticity and that it wasn't modified
maliciously to target your specific device (e.g., by comparing hashes
against a public database). Naturally, a device with open-source
firmware (still loaded externally) would be even better. In the vast
majority of cases, however, a device that doesn't require loading
external firmware actually still has such firmware -- it's just hidden
inside and impossible to attest.
Patching
=========
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes OS 4.0:
- Xen packages version 4.8.5-11
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.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.
Credits
========
See the original Xen Security Advisories.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-299.html
[2] https://xenbits.xen.org/xsa/advisory-302.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
XSAs 296, 298, 301, and 303 do not affect the security of Qubes OS
https://www.qubes-os.org/news/2019/10/31/xsa-296-298-301-303-qubes-not-affected/
The Xen Project has published Xen Security Advisories 296, 298, 301,
and 303 (XSA-296, XSA-298, XSA-301, and XSA-303, respectively). These
XSAs do not affect the security of Qubes OS, and no user action is
necessary.
These XSAs have been added to the XSA Tracker (https://www.qubes-os.org/security/xsa/):
https://www.qubes-os.org/security/xsa/#296
https://www.qubes-os.org/security/xsa/#298
https://www.qubes-os.org/security/xsa/#301
https://www.qubes-os.org/security/xsa/#303
https://www.qubes-os.org/news/2019/10/31/xsa-296-298-301-303-qubes-not-affected/
The Xen Project has published Xen Security Advisories 296, 298, 301,
and 303 (XSA-296, XSA-298, XSA-301, and XSA-303, respectively). These
XSAs do not affect the security of Qubes OS, and no user action is
necessary.
These XSAs have been added to the XSA Tracker (https://www.qubes-os.org/security/xsa/):
https://www.qubes-os.org/security/xsa/#296
https://www.qubes-os.org/security/xsa/#298
https://www.qubes-os.org/security/xsa/#301
https://www.qubes-os.org/security/xsa/#303
Qubes OS 4.0.2-rc2 has been released!
https://www.qubes-os.org/news/2019/11/03/qubes-4-0-2-rc2/
We’re pleased to announce the second 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-rc2 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-rc2, 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/).
https://www.qubes-os.org/news/2019/11/03/qubes-4-0-2-rc2/
We’re pleased to announce the second 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-rc2 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-rc2, 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/).
QSB #053: TSX Asynchronous Abort speculative side channel (XSA-305)
https://www.qubes-os.org/news/2019/11/13/qsb-053/
We have just published Qubes Security Bulletin (QSB) #053:
TSX Asynchronous Abort speculative side channel (XSA-305).
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 #053 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-053-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/
Note: Typically, XSAs have a predisclosure period, during which the XSA is
embargoed, which gives the Qubes Security Team time to analyze it and
prepare patches and an announcement. However, XSA-305 had no embargo period,
so the Qubes Security Team had no advance notice of it before it was publicly
announced. For this reason, QSB #053 is being initially published without
detached signatures from the Qubes Security Team. These signatures will be added
shortly after publication, as soon as Qubes Security Team members have a chance
to create them. Readers who wish to verify the authenticity of this QSB can
still check the signed tag on the commit that added this QSB to the
qubes-secpack repo:
https://github.com/QubesOS/qubes-secpack/commit/59b39c645015c3d1bfce5d633ab55d8ed88aeb0b
---===[ Qubes Security Bulletin #53 ]===---
2019-11-13
TSX Asynchronous Abort speculative side channel (XSA-305)
Summary
========
On 2019-11-12, the Xen Security Team published Xen Security Advisory
305 (CVE-2019-11135 / XSA-305) [1] with the following denoscription:
| This is very closely related to the Microarchitectural Data Sampling
| vulnerabilities from May 2019.
|
| Please see https://xenbits.xen.org/xsa/advisory-297.html for details
| about MDS.
|
| A new way to sample data from microarchitectural structures has been
| identified. A TSX Asynchronous Abort is a state which occurs between a
| transaction definitely aborting (usually for reasons outside of the
| pipeline's control e.g. receiving an interrupt), and architectural state
| being rolled back to start of the transaction.
|
| During this period, speculative execution may be able to infer the value
| of data in the microarchitectural structures.
|
| For more details, see:
| https://software.intel.com/security-software-guidance/insights/deep-dive-intel-transactional-synchronization-extensions-intel-tsx-asynchronous-abort
|
| An attacker, which could include a malicious untrusted user process on a
| trusted guest, or an untrusted guest, can sample the content of
| recently-used memory operands and IO Port writes.
|
| This can include data from:
|
| * A previously executing context (process, or guest, or
| hypervisor/toolstack) at the same privilege level.
| * A higher privilege context (kernel, hypervisor, SMM) which
| interrupted the attacker's execution.
|
| Vulnerable data is that on the same physical core as the attacker. This
| includes, when hyper-threading is enabled, adjacent threads.
|
| An attacker cannot use this vulnerability to target specific data. An
| attack would likely require sampling over a period of time and the
| application of statistical methods to reconstruct interesting data.
This is yet another CPU hardware bug related to speculative execution.
Only Intel processors are affected.
Note: There was no embargo period for this XSA.
Patching
=========
The Xen Project has provided patches that mitigate this issue. A CPU
microcode update is required to take advantage of them. Note that
microcode updates may not be available for older CPUs. (See the Intel
advisory linked above for details.)
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes 4.0:
https://www.qubes-os.org/news/2019/11/13/qsb-053/
We have just published Qubes Security Bulletin (QSB) #053:
TSX Asynchronous Abort speculative side channel (XSA-305).
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 #053 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-053-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/
Note: Typically, XSAs have a predisclosure period, during which the XSA is
embargoed, which gives the Qubes Security Team time to analyze it and
prepare patches and an announcement. However, XSA-305 had no embargo period,
so the Qubes Security Team had no advance notice of it before it was publicly
announced. For this reason, QSB #053 is being initially published without
detached signatures from the Qubes Security Team. These signatures will be added
shortly after publication, as soon as Qubes Security Team members have a chance
to create them. Readers who wish to verify the authenticity of this QSB can
still check the signed tag on the commit that added this QSB to the
qubes-secpack repo:
https://github.com/QubesOS/qubes-secpack/commit/59b39c645015c3d1bfce5d633ab55d8ed88aeb0b
---===[ Qubes Security Bulletin #53 ]===---
2019-11-13
TSX Asynchronous Abort speculative side channel (XSA-305)
Summary
========
On 2019-11-12, the Xen Security Team published Xen Security Advisory
305 (CVE-2019-11135 / XSA-305) [1] with the following denoscription:
| This is very closely related to the Microarchitectural Data Sampling
| vulnerabilities from May 2019.
|
| Please see https://xenbits.xen.org/xsa/advisory-297.html for details
| about MDS.
|
| A new way to sample data from microarchitectural structures has been
| identified. A TSX Asynchronous Abort is a state which occurs between a
| transaction definitely aborting (usually for reasons outside of the
| pipeline's control e.g. receiving an interrupt), and architectural state
| being rolled back to start of the transaction.
|
| During this period, speculative execution may be able to infer the value
| of data in the microarchitectural structures.
|
| For more details, see:
| https://software.intel.com/security-software-guidance/insights/deep-dive-intel-transactional-synchronization-extensions-intel-tsx-asynchronous-abort
|
| An attacker, which could include a malicious untrusted user process on a
| trusted guest, or an untrusted guest, can sample the content of
| recently-used memory operands and IO Port writes.
|
| This can include data from:
|
| * A previously executing context (process, or guest, or
| hypervisor/toolstack) at the same privilege level.
| * A higher privilege context (kernel, hypervisor, SMM) which
| interrupted the attacker's execution.
|
| Vulnerable data is that on the same physical core as the attacker. This
| includes, when hyper-threading is enabled, adjacent threads.
|
| An attacker cannot use this vulnerability to target specific data. An
| attack would likely require sampling over a period of time and the
| application of statistical methods to reconstruct interesting data.
This is yet another CPU hardware bug related to speculative execution.
Only Intel processors are affected.
Note: There was no embargo period for this XSA.
Patching
=========
The Xen Project has provided patches that mitigate this issue. A CPU
microcode update is required to take advantage of them. Note that
microcode updates may not be available for older CPUs. (See the Intel
advisory linked above for details.)
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes 4.0:
- Xen packages, version 4.8.5-12
- microcode_ctl 2.1-29.qubes1
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
A system restart will be required afterwards.
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.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.
Credits
========
See the original Xen Security Advisory.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-305.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
- microcode_ctl 2.1-29.qubes1
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
A system restart will be required afterwards.
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.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.
Credits
========
See the original Xen Security Advisory.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-305.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
XSA-304 does not affect the security of Qubes OS
https://www.qubes-os.org/news/2019/11/13/xsa-304-qubes-not-affected/
The Xen Project has published Xen Security Advisory 304 (XSA-304).
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/#304
https://www.qubes-os.org/news/2019/11/13/xsa-304-qubes-not-affected/
The Xen Project has published Xen Security Advisory 304 (XSA-304).
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/#304