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...

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

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!

Support Group!

https://news.1rj.ru/str/joinchat/B8FHpkEToMfgdREGV7wzRQ

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

(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/

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

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/).

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:

- 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/

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

Support Group!

https://news.1rj.ru/str/joinchat/B8FHpkEToMfgdREGV7wzRQ

QSB #054: Xen fix for XSA-302 found ineffective in Qubes configuration (XSA-306)
https://www.qubes-os.org/news/2019/11/26/qsb-054/

We have just published Qubes Security Bulletin (QSB) #054:
Xen fix for XSA-302 found ineffective in Qubes configuration (XSA-306).
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 #054 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-054-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/

View XSA-306 in the XSA Tracker:

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



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

2019-11-26


Xen fix for XSA-302 found ineffective in Qubes configuration (XSA-306)

Summary
========

In the course of re-verifying the fixes for QSB #52 (XSA-299, XSA-302)
[1], the Qubes Security Team discovered that the fix released by the
Xen Project for XSA-302 [2] is not effective for the configuration used
in Qubes OS.

On 2019-11-26, the Xen Security Team published the following Xen
Security Advisory (XSA):

XSA-306 [3] "Device quarantine for alternate pci assignment methods":
| XSA-302 relies on the use of libxl's "assignable-add" feature to
| prepare devices to be assigned to untrusted guests.
|
| Unfortunately, this is not considered a strictly required step for
| device assignment. The PCI passthrough documentation on the wiki
| describes alternate ways of preparing devices for assignment, and
| libvirt uses its own ways as well. Hosts where these "alternate"
| methods are used will still leave the system in a vulnerable state
| after the device comes back from a guest.
|
| An untrusted domain with access to a physical device can DMA into host
| memory, leading to privilege escalation.


Impact
=======

The original XSA-302 fix provided by the Xen Project is ineffective for
the configuration used in Qubes OS. Therefore, the impact is the same as
as the XSA-302 impact originally reported in QSB #52 (XSA-299, XSA-302).


Discussion
===========

The Qubes Security Team discovered this issue while re-verifying the Xen
Project's fixes for XSA-302. At that time, both XSA-302 and QSB #52 had
already been made public. Whether a disclosure has been made public is
significant to the Xen Security Policy [4]. Therefore, after discussion
with the Xen Security Team, we have decided to treat this as a separate
security issue, with a separate XSA, QSB, and embargo period.

From a security perspective, the new proposed fix for PCI device
isolation is much less fragile, since it no longer depends on toolstack
(libxl) behavior anymore.


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-13

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://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-052-2019.txt
[2] https://xenbits.xen.org/xsa/advisory-302.html
[3] https://xenbits.xen.org/xsa/advisory-306.html
[4] https://xenproject.org/developers/security-policy/

--

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

Fedora 29 has reached EOL
https://www.qubes-os.org/news/2019/11/29/fedora-29-eol/

Fedora 29 has reached EOL (end-of-life (https://fedoraproject.org/wiki/End_of_life)). We strongly recommend that
all Qubes users upgrade their Fedora 29 TemplateVMs and StandaloneVMs to
Fedora 30 immediately. We provide step-by-step upgrade instructions for
upgrading Fedora TemplateVMs (https://www.qubes-os.org/doc/template/fedora/upgrade/). For a complete list of TemplateVM
versions supported for your specific version of Qubes, see Supported
TemplateVM Versions (https://www.qubes-os.org/doc/supported-versions/#templatevms).

We also provide a fresh Fedora 30 TemplateVM package through the
official Qubes repositories, which you can install in dom0 by following
the standard installation instructions (https://www.qubes-os.org/doc/templates/fedora/#installing).

After upgrading your TemplateVMs, please remember to switch all qubes
that were using the old template to use the new one (https://www.qubes-os.org/doc/templates/#switching).

Please note that no user action is required regarding the OS version in
dom0. For details, please see our Note on dom0 and EOL (https://www.qubes-os.org/doc/supported-versions/#note-on-dom0-and-eol).

Xen Project 4.11.3 is available!
https://xenproject.org/2019/11/29/xen-project-4-11-3-is-available/

I am pleased to announce the release of the Xen 4.11.3. Xen Project maintenance releases are released in line with our Maintenance Release Policy. We recommend that all users of...

QSB #055: Issues with PV type change and handling IOMMU on AMD (XSA-310, XSA-311)
https://www.qubes-os.org/news/2019/12/11/qsb-055/

We have just published Qubes Security Bulletin (QSB) #055:
Issues with PV type change and handling IOMMU on AMD (XSA-310, XSA-311).
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 #055 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-055-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/

View XSA-310 and XSA-311 in the XSA Tracker:

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



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

2019-12-11


Issues with PV type change and handling IOMMU on AMD (XSA-310, XSA-311)


Summary
========

On 2019-12-11, the Xen Security Team published the following Xen
Security Advisories (XSAs):

XSA-310 (CVE-2019-19580) [1] Further issues with restartable PV type
change operations:

| XSA-299 addressed several critical issues in restartable PV type
| change operations. Despite extensive testing and auditing, some
| corner cases were missed.
|
| A malicious PV guest administrator may be able to escalate their
| privilege to that of the host.

XSA-311 (CVE-2019-19577) [2] Bugs in dynamic height handling for AMD
IOMMU pagetables:

| When running on AMD systems with an IOMMU, Xen attempted to
| dynamically adapt the number of levels of pagetables (the pagetable
| height) in the IOMMU according to the guest's address space size. The
| code to select and update the height had several bugs.
|
| Notably, the update was done without taking a lock which is necessary
| for safe operation.
|
| A malicious guest administrator can cause Xen to access data
| structures while they are being modified, causing Xen to crash.
| Privilege escalation is thought to be very difficult but cannot be
| ruled out.
|
| Additionally, there is a potential memory leak of 4kb per guest boot,
| under memory pressure.


Impact
=======

XSA-310 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-310. 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-310.

Moreover, since this vulnerability is a race condition, it is an
unreliable attack vector in real world scenarios.

XSA-311 affects only systems running on AMD hardware and also is
thought to be very hard to exploit. But since it can't be ruled out
completely, we recommend applying updates nevertheless.


Patching
=========

The specific packages that resolve the problems discussed in this
bulletin are as follows:

For Qubes 4.0:
- Xen packages, version 4.8.5-14

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