QSB-069: Multiple Xen and Intel issues
20 views
Skip to first unread message
Andrew David Wong
Jun 8, 2021, 9:06:36 PM6/8/21
to qubes-announce, qubes-devel, qubes-users
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) 069: Multiple Xen
and Intel issues. 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-069 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-069-2021.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 069 ]===---
2021-06-08
Multiple Xen and Intel issues
(XSA-373, XSA-374, XSA-375, XSA-377, INTEL-SA-00442)
User action required
=====================
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.0, in dom0:
- Xen packages, version 4.8.5-34
- Linux kernel packages, versions 5.12.9-1 (for users of the "latest"
kernel flavor)
- microcode_ctl package, version 2.1-33.qubes1 (for Intel CPU users)
For Qubes 4.1, in dom0:
- Xen packages, version 4.14.1-5
- Linux kernel packages, versions 5.10.42-1, 5.12.9-1 (for users of
the "latest" kernel flavor)
- microcode_ctl package, version 2.1-33.qubes1 (for Intel CPU users)
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. [1] Once available, the packages are to be installed
via the Qubes Update Tool or its command-line equivalents. [2]
Dom0 must be restarted afterward in order for the updates to take
effect.
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.
Summary
========
The following security advisories were published on 2021-06-08:
XSA-373 [3] "Inappropriate x86 IOMMU timeout detection / handling":
| IOMMUs process commands issued to them in parallel with the operation
| of the CPU(s) issuing such commands. In the current implementation in
| Xen, asynchronous notification of the completion of such commands is
| not used. Instead, the issuing CPU spin-waits for the completion of
| the most recently issued command(s). Some of these waiting loops try
| to apply a timeout to fail overly-slow commands. The course of action
| upon a perceived timeout actually being detected is inappropriate:
| - on Intel hardware guests which did not originally cause the timeout
| may be marked as crashed,
| - on AMD hardware higher layer callers would not be notified of the
| issue, making them continue as if the IOMMU operation succeeded.
XSA-374 [4] "Guest triggered use-after-free in Linux xen-netback":
| A malicious or buggy network PV frontend can force Linux netback to
| disable the interface and terminate the receive kernel thread
| associated with queue 0 in response to the frontend sending a
| malformed packet.
|
| Such kernel thread termination will lead to a use-after-free in Linux
| netback when the backend is destroyed, as the kernel thread associated
| with queue 0 will have already exited and thus the call to
| kthread_stop will be performed against a stale pointer.
XSA-375 [5] "Speculative Code Store Bypass":
| Modern superscalar processors may employ sophisticated decoding and
| caching of the instruction stream to improve performance. However, a
| consequence is that self-modifying code updates may not take effect
| instantly.
|
| Whatever the architectural guarantees, some CPUs have
| microarchitectural behaviour whereby the stale instruction stream may
| be speculatively decoded and executed.
|
| Speculation of this form can suffer from type confusion in registers,
| and potentially leak data.
XSA-377 [6] "x86: TSX Async Abort protections not restored after S3":
| This issue relates to the TSX Async Abort speculative security
| vulnerability. Please see https://xenbits.xen.org/xsa/advisory-305.html
| for details.
|
| Mitigating TAA by disabling TSX (the default and preferred option)
| requires selecting a non-default setting in MSR_TSX_CTRL. This
| setting isn't restored after S3 suspend.
INTEL-SA-00442 [7] "Intel® VT-d Advisory":
| A potential security vulnerability in some Intel® Virtualization
| Technology for Directed I/0 (VT-d) products may allow escalation of
| privilege. Intel is releasing firmware updates to mitigate this
| potential vulnerability.
Impact
=======
XSA-373:
As the Xen Security Team explains, "A malicious guest may be able to
elevate its privileges to that of the host, cause host or guest Denial
of Service (DoS), or cause information leaks." Only a guest with a PCI
device can leverage this vulnerability, such as `sys-net` or `sys-usb`
in a default Qubes OS configuration.
XSA-374:
A malicious or buggy VM can trigger its network-providing VM to crash.
In a typical installation, the affected network-providing VM would be
`sys-firewall` or `sys-whonix`. Privilege escalation (to the
network-providing VM) and information leaks cannot be ruled out.
The issue affects only Linux kernel version 5.5 and newer. By default,
Qubes OS R4.0 uses Linux 5.4.x and is therefore not affected. However,
if the user has manually installed a newer, affected kernel version
(e.g., using the `kernel-latest-qubes-vm` package), then that
installation is affected.
XSA-375:
As explained by the Xen Security Team, "An attacker might be able to
infer the contents of arbitrary host memory, including memory assigned
to other guests."
XSA-377:
The impact is the same as XSA-305, which we explained in QSB-053 [8]:
| 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.
INTEL-SA-00442:
As explained by Intel, "Incomplete cleanup in some Intel(R) VT-d
products may allow an authenticated user to potentially enable
escalation of privilege via local access."
Only Intel CPUs are affected.
Credits
========
See the original Security Advisories.
References
===========
[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/updating-qubes-os/
[3] https://xenbits.xen.org/xsa/advisory-373.html
[4] https://xenbits.xen.org/xsa/advisory-374.html
[5] https://xenbits.xen.org/xsa/advisory-375.html
[6] https://xenbits.xen.org/xsa/advisory-377.html
[7]
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00442.html
[8] https://www.qubes-os.org/news/2019/11/13/qsb-053/
--
The Qubes Security Team
https://www.qubes-os.org/security/
```
This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2021/06/08/qsb-069/
We have just published Qubes Security Bulletin (QSB) 069: Multiple Xen
and Intel issues. 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-069 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-069-2021.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 069 ]===---
2021-06-08
Multiple Xen and Intel issues
(XSA-373, XSA-374, XSA-375, XSA-377, INTEL-SA-00442)
User action required
=====================
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.0, in dom0:
- Xen packages, version 4.8.5-34
- Linux kernel packages, versions 5.12.9-1 (for users of the "latest"
kernel flavor)
- microcode_ctl package, version 2.1-33.qubes1 (for Intel CPU users)
For Qubes 4.1, in dom0:
- Xen packages, version 4.14.1-5
- Linux kernel packages, versions 5.10.42-1, 5.12.9-1 (for users of
the "latest" kernel flavor)
- microcode_ctl package, version 2.1-33.qubes1 (for Intel CPU users)
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. [1] Once available, the packages are to be installed
via the Qubes Update Tool or its command-line equivalents. [2]
Dom0 must be restarted afterward in order for the updates to take
effect.
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.
Summary
========
The following security advisories were published on 2021-06-08:
XSA-373 [3] "Inappropriate x86 IOMMU timeout detection / handling":
| IOMMUs process commands issued to them in parallel with the operation
| of the CPU(s) issuing such commands. In the current implementation in
| Xen, asynchronous notification of the completion of such commands is
| not used. Instead, the issuing CPU spin-waits for the completion of
| the most recently issued command(s). Some of these waiting loops try
| to apply a timeout to fail overly-slow commands. The course of action
| upon a perceived timeout actually being detected is inappropriate:
| - on Intel hardware guests which did not originally cause the timeout
| may be marked as crashed,
| - on AMD hardware higher layer callers would not be notified of the
| issue, making them continue as if the IOMMU operation succeeded.
XSA-374 [4] "Guest triggered use-after-free in Linux xen-netback":
| A malicious or buggy network PV frontend can force Linux netback to
| disable the interface and terminate the receive kernel thread
| associated with queue 0 in response to the frontend sending a
| malformed packet.
|
| Such kernel thread termination will lead to a use-after-free in Linux
| netback when the backend is destroyed, as the kernel thread associated
| with queue 0 will have already exited and thus the call to
| kthread_stop will be performed against a stale pointer.
XSA-375 [5] "Speculative Code Store Bypass":
| Modern superscalar processors may employ sophisticated decoding and
| caching of the instruction stream to improve performance. However, a
| consequence is that self-modifying code updates may not take effect
| instantly.
|
| Whatever the architectural guarantees, some CPUs have
| microarchitectural behaviour whereby the stale instruction stream may
| be speculatively decoded and executed.
|
| Speculation of this form can suffer from type confusion in registers,
| and potentially leak data.
XSA-377 [6] "x86: TSX Async Abort protections not restored after S3":
| This issue relates to the TSX Async Abort speculative security
| vulnerability. Please see https://xenbits.xen.org/xsa/advisory-305.html
| for details.
|
| Mitigating TAA by disabling TSX (the default and preferred option)
| requires selecting a non-default setting in MSR_TSX_CTRL. This
| setting isn't restored after S3 suspend.
INTEL-SA-00442 [7] "Intel® VT-d Advisory":
| A potential security vulnerability in some Intel® Virtualization
| Technology for Directed I/0 (VT-d) products may allow escalation of
| privilege. Intel is releasing firmware updates to mitigate this
| potential vulnerability.
Impact
=======
XSA-373:
As the Xen Security Team explains, "A malicious guest may be able to
elevate its privileges to that of the host, cause host or guest Denial
of Service (DoS), or cause information leaks." Only a guest with a PCI
device can leverage this vulnerability, such as `sys-net` or `sys-usb`
in a default Qubes OS configuration.
XSA-374:
A malicious or buggy VM can trigger its network-providing VM to crash.
In a typical installation, the affected network-providing VM would be
`sys-firewall` or `sys-whonix`. Privilege escalation (to the
network-providing VM) and information leaks cannot be ruled out.
The issue affects only Linux kernel version 5.5 and newer. By default,
Qubes OS R4.0 uses Linux 5.4.x and is therefore not affected. However,
if the user has manually installed a newer, affected kernel version
(e.g., using the `kernel-latest-qubes-vm` package), then that
installation is affected.
XSA-375:
As explained by the Xen Security Team, "An attacker might be able to
infer the contents of arbitrary host memory, including memory assigned
to other guests."
XSA-377:
The impact is the same as XSA-305, which we explained in QSB-053 [8]:
| 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.
INTEL-SA-00442:
As explained by Intel, "Incomplete cleanup in some Intel(R) VT-d
products may allow an authenticated user to potentially enable
escalation of privilege via local access."
Only Intel CPUs are affected.
Credits
========
See the original Security Advisories.
References
===========
[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/updating-qubes-os/
[3] https://xenbits.xen.org/xsa/advisory-373.html
[4] https://xenbits.xen.org/xsa/advisory-374.html
[5] https://xenbits.xen.org/xsa/advisory-375.html
[6] https://xenbits.xen.org/xsa/advisory-377.html
[7]
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00442.html
[8] https://www.qubes-os.org/news/2019/11/13/qsb-053/
--
The Qubes Security Team
https://www.qubes-os.org/security/
```
This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2021/06/08/qsb-069/
Ulrich Windl
Jun 9, 2021, 5:07:38 PM6/9/21
to qubes...@googlegroups.com
On 6/9/21 3:06 AM, Andrew David Wong wrote:
...
> User action required
> =====================
>
> Users must install the following specific packages in order to address
> the issues discussed in this bulletin:
>
> For Qubes 4.0, in dom0:
> - Xen packages, version 4.8.5-34
> - Linux kernel packages, versions 5.12.9-1 (for users of the "latest"
> kernel flavor)
> - microcode_ctl package, version 2.1-33.qubes1 (for Intel CPU users)
After updating today no kernel was offered; I still have:
# rpm -qa kernel\*
kernel-5.4.88-1.qubes.x86_64
kernel-5.4.98-1.fc25.qubes.x86_64
kernel-qubes-vm-5.4.98-1.fc25.qubes.x86_64
kernel-5.4.107-1.fc25.qubes.x86_64
kernel-qubes-vm-5.4.107-1.fc25.qubes.x86_64
kernel-qubes-vm-5.4.88-1.qubes.x86_64
Somehow I'm missing instructions to get that kernel...
My repositories are:
================================================================================
Package Arch Version Repository
Size
================================================================================
Upgrading:
python3-qubesimgconverter x86_64 4.0.33-1.fc25
qubes-dom0-current 26 k
python3-xen x86_64 2001:4.8.5-32.fc25
qubes-dom0-current 59 k
qubes-libvchan-xen x86_64 4.0.9-1.fc25
qubes-dom0-current 19 k
qubes-mgmt-salt-base-topd noarch 4.0.2-1.fc25
qubes-dom0-current 29 k
qubes-release noarch 4.0-10
qubes-dom0-current 50 k
qubes-release-notes noarch 4.0-10
qubes-dom0-current 7.7 k
qubes-utils x86_64 4.0.33-1.fc25
qubes-dom0-current 23 k
qubes-utils-libs x86_64 4.0.33-1.fc25
qubes-dom0-current 27 k
xen x86_64 2001:4.8.5-32.fc25
qubes-dom0-current 23 k
xen-hvm x86_64 2001:4.8.5-32.fc25
qubes-dom0-current 7.3 M
xen-hypervisor x86_64 2001:4.8.5-32.fc25
qubes-dom0-current 6.2 M
xen-libs x86_64 2001:4.8.5-32.fc25
qubes-dom0-current 515 k
xen-licenses x86_64 2001:4.8.5-32.fc25
qubes-dom0-current 42 k
xen-runtime x86_64 2001:4.8.5-32.fc25
qubes-dom0-current 6.4 M
Regards,
Ulrich
...
> User action required
> =====================
>
> Users must install the following specific packages in order to address
> the issues discussed in this bulletin:
>
> For Qubes 4.0, in dom0:
> - Xen packages, version 4.8.5-34
> - Linux kernel packages, versions 5.12.9-1 (for users of the "latest"
> kernel flavor)
> - microcode_ctl package, version 2.1-33.qubes1 (for Intel CPU users)
# rpm -qa kernel\*
kernel-5.4.88-1.qubes.x86_64
kernel-5.4.98-1.fc25.qubes.x86_64
kernel-qubes-vm-5.4.98-1.fc25.qubes.x86_64
kernel-5.4.107-1.fc25.qubes.x86_64
kernel-qubes-vm-5.4.107-1.fc25.qubes.x86_64
kernel-qubes-vm-5.4.88-1.qubes.x86_64
Somehow I'm missing instructions to get that kernel...
My repositories are:
================================================================================
Package Arch Version Repository
Size
================================================================================
Upgrading:
python3-qubesimgconverter x86_64 4.0.33-1.fc25
qubes-dom0-current 26 k
python3-xen x86_64 2001:4.8.5-32.fc25
qubes-dom0-current 59 k
qubes-libvchan-xen x86_64 4.0.9-1.fc25
qubes-dom0-current 19 k
qubes-mgmt-salt-base-topd noarch 4.0.2-1.fc25
qubes-dom0-current 29 k
qubes-release noarch 4.0-10
qubes-dom0-current 50 k
qubes-release-notes noarch 4.0-10
qubes-dom0-current 7.7 k
qubes-utils x86_64 4.0.33-1.fc25
qubes-dom0-current 23 k
qubes-utils-libs x86_64 4.0.33-1.fc25
qubes-dom0-current 27 k
xen x86_64 2001:4.8.5-32.fc25
qubes-dom0-current 23 k
xen-hvm x86_64 2001:4.8.5-32.fc25
qubes-dom0-current 7.3 M
xen-hypervisor x86_64 2001:4.8.5-32.fc25
qubes-dom0-current 6.2 M
xen-libs x86_64 2001:4.8.5-32.fc25
qubes-dom0-current 515 k
xen-licenses x86_64 2001:4.8.5-32.fc25
qubes-dom0-current 42 k
xen-runtime x86_64 2001:4.8.5-32.fc25
qubes-dom0-current 6.4 M
Regards,
Ulrich
Ludovic
Jun 9, 2021, 5:33:52 PM6/9/21
to qubes...@googlegroups.com
On 6/9/21 @ 23:07, Ulrich Windl wrote :
please, re-read the QSB, you missed **security-testing repository** :
> 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. [1] Once available, the packages are to be installed
> via the Qubes Update Tool or its command-line equivalents. [2]
The QSB provides the links to the documentation which explains how
to update from security-testing, else wait ~2 weeks.
The kernel update is only if you use `kernel latest` (i.e. 5.5
kernel), but you use a 5.4 kernel. The xen and intel-microcode update is
for everyone.
Same for your post about XScreenSaver : **security-testing
repository**.
I did all theses update on my Qubes-OS host, from now, no detected
issue.
Regards,
Ludovic
> On 6/9/21 3:06 AM, Andrew David Wong wrote:
>
> After updating today no kernel was offered; I still have:
> # rpm -qa kernel\*
> kernel-5.4.88-1.qubes.x86_64
> kernel-5.4.98-1.fc25.qubes.x86_64
> kernel-qubes-vm-5.4.98-1.fc25.qubes.x86_64
> kernel-5.4.107-1.fc25.qubes.x86_64
> kernel-qubes-vm-5.4.107-1.fc25.qubes.x86_64
> kernel-qubes-vm-5.4.88-1.qubes.x86_64
>
> Somehow I'm missing instructions to get that kernel...
>
>
Hi Ulrich,
>
> After updating today no kernel was offered; I still have:
> # rpm -qa kernel\*
> kernel-5.4.88-1.qubes.x86_64
> kernel-5.4.98-1.fc25.qubes.x86_64
> kernel-qubes-vm-5.4.98-1.fc25.qubes.x86_64
> kernel-5.4.107-1.fc25.qubes.x86_64
> kernel-qubes-vm-5.4.107-1.fc25.qubes.x86_64
> kernel-qubes-vm-5.4.88-1.qubes.x86_64
>
> Somehow I'm missing instructions to get that kernel...
>
>
please, re-read the QSB, you missed **security-testing repository** :
> 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. [1] Once available, the packages are to be installed
> via the Qubes Update Tool or its command-line equivalents. [2]
to update from security-testing, else wait ~2 weeks.
The kernel update is only if you use `kernel latest` (i.e. 5.5
kernel), but you use a 5.4 kernel. The xen and intel-microcode update is
for everyone.
Same for your post about XScreenSaver : **security-testing
repository**.
I did all theses update on my Qubes-OS host, from now, no detected
issue.
Regards,
Ludovic
Andrew David Wong
Jun 9, 2021, 7:01:36 PM6/9/21
to qubes...@googlegroups.com
`kernel-latest`, as clearly stated in the QSB. You would know if you
were using `kernel-latest`, as you would've had to take deliberate
action to start using it. If you never did anything to change from the
default kernel, then this kernel update doesn't apply to you, and it's
expected that you would not see any kernel updates associated with this QSB.
--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
Reply all
Reply to author
Forward
0 new messages