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
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/
--
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/
--
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).
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...
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
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
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-310.html
[2] https://xenbits.xen.org/xsa/advisory-311.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
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-310.html
[2] https://xenbits.xen.org/xsa/advisory-311.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
Qubes OS 4.0.2-rc3 has been released!
https://www.qubes-os.org/news/2019/12/13/qubes-4-0-2-rc3/
We’re pleased to announce the third 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-rc3 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.
Note: At 4.5 GiB, the Qubes 4.0.2-rc3 ISO will not fit on a
single-layer DVD (for the technical details underlying this, please see
issue #5367 (https://github.com/QubesOS/qubes-issues/issues/5367)). Instead, we recommend copying the ISO onto a
sufficiently large USB drive (https://www.qubes-os.org/doc/installation-guide/#copying-the-iso-onto-the-installation-medium). However, if you would prefer to
use optical media, we suggest selecting a dual-layer DVD or Blu-ray disc.
Release candidate planning
If no major issues are discovered in 4.0.2-rc3, 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/12/13/qubes-4-0-2-rc3/
We’re pleased to announce the third 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-rc3 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.
Note: At 4.5 GiB, the Qubes 4.0.2-rc3 ISO will not fit on a
single-layer DVD (for the technical details underlying this, please see
issue #5367 (https://github.com/QubesOS/qubes-issues/issues/5367)). Instead, we recommend copying the ISO onto a
sufficiently large USB drive (https://www.qubes-os.org/doc/installation-guide/#copying-the-iso-onto-the-installation-medium). However, if you would prefer to
use optical media, we suggest selecting a dual-layer DVD or Blu-ray disc.
Release candidate planning
If no major issues are discovered in 4.0.2-rc3, 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/).
True static partitioning with Xen Dom0-less
https://xenproject.org/2019/12/16/true-static-partitioning-with-xen-dom0-less/
The Xen Project hypervisor has relied on a special virtual machine, Dom0, to perform privileged operations since the early days of the project. Dom0 has always been the very first...
https://xenproject.org/2019/12/16/true-static-partitioning-with-xen-dom0-less/
The Xen Project hypervisor has relied on a special virtual machine, Dom0, to perform privileged operations since the early days of the project. Dom0 has always been the very first...
What’s New in Xen 4.13
https://xenproject.org/2019/12/18/whats-new-in-xen-4-13/
I am pleased to announce the release of Xen Project Hypervisor 4.13. This latest release improves security, hardware support, added new options for embedded use cases and reflects a wide...
https://xenproject.org/2019/12/18/whats-new-in-xen-4-13/
I am pleased to announce the release of Xen Project Hypervisor 4.13. This latest release improves security, hardware support, added new options for embedded use cases and reflects a wide...
Xen Project Hypervisor 4.13 Brings Improved Security, Hardware Support and Features to Increase Embedded Use Case Adoption
https://xenproject.org/2019/12/18/xen-project-hypervisor-4-13-brings-improved-security-hardware-support-and-features-to-increase-embedded-use-case-adoption/
Broad community collaboration brings new functionality as well as steps forward in functional safety certification. SAN FRANCISCO – December 18, 2019 — The Xen Project, an open source hypervisor hosted...
https://xenproject.org/2019/12/18/xen-project-hypervisor-4-13-brings-improved-security-hardware-support-and-features-to-increase-embedded-use-case-adoption/
Broad community collaboration brings new functionality as well as steps forward in functional safety certification. SAN FRANCISCO – December 18, 2019 — The Xen Project, an open source hypervisor hosted...