QSB-069: Multiple Xen and Intel issues

system · June 9, 2021, 1:09am

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

             ---===[ 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 is a companion discussion topic for the original entry at https://www.qubes-os.org/news/2021/06/08/qsb-069/

fiftyfourthparallel · June 9, 2021, 11:14am

system:

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.

Looks like another* QSB containing ~~not one, but two vulnerabilities~~ (Edit: XSA-374 doesn’t concern sys-net. I wasn’t thinking straight. Excuse me while I put on my dunce hat and sit in this corner for a bit. Don’t mind the drool.) a vulnerability that particularly impacts sys-net. As noted before, because sys-net is an HVM with PCI access, it is the weak link in our systems’ security–especially because it can’t sit behind a firewall (unless external).

Sometimes I just feel like we should crowdfund development of a unikernel like Mirage to replace sys-net, if only just for ethernet connections (if you’re this worried about your security, you shouldn’t be using WiFi anyways).

*Previously:

XSA-337: A malicious HVM with a PCI device (such as sys-net or sys-usb
in the default Qubes OS configuration) can potentially compromise the
whole system.

^{^{Not technically-trained; consume advice with salt}}

deeplow · June 14, 2021, 2:44pm

10 posts were merged into an existing topic: Why are (most) Security Fixes Not Immediately Available?

Qenthusiast · June 12, 2021, 2:35pm

The bulletin tells me to install a xen package, a linux kernel package and a microcode_ctl package, so how do I do it?

adw · June 13, 2021, 12:12am

Simply keep updating Qubes normally, and the packages will automatically be installed once they’re stable.

adw · June 13, 2021, 1:52am

I think I understand the confusion, and I’ve opened a new issue to have it addressed:

github.com/QubesOS/qubes-issues

Notify user when completed update requires system restart

opened 01:37AM - 13 Jun 21 UTC

andrewdavidwong

C: updates P: major T: enhancement ux

**The problem you're addressing (if any)** Many users are misinterpreting t…he "User action required" section at the top of each QSB. Specifically, they interpret it to mean that they must take some special action besides just updating normally. This is *not* true for most users. Most should just keep updating normally and receive the associated packages when they land in `current`. In particular, they are interpreting it to mean that they should all be enabling the `security-testing` repo in order to get the updates immediately. In other words, they see each QSB as giving them a "job" to do. Before our recent text change, they interpreted the "job" as saying, "In order to fix your system, enter this command: `sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing`." Now that we no longer print that exact command in the QSB, they interpret the "job" as saying, "Figure out how to enable something called `security-testing`, then figure out how to use it to update." They see the recent text change as making their "job" harder because it no longer just gives them the exact command they need to enter. A lot of these users see `security-testing` as a "cheat code" to getting security updates faster. Of course, none of this makes any sense. If we wanted every user to enable `security-testing`, we would just ship Qubes with that repo enabled. Better yet, we would just send all security updates directly to `current` and bypass `security-testing`. In fact, this is what we used to do, before we introduced `security-testing` in the first place! However, we found that (surprise) software updates can have bugs, and it's better to discover and fix the bugs before sending updates to the entire userbase. Hence, `security-testing` was born. It exists for a reason. It would make no sense to have every user figure out how to manually enable it for each QSB. That is clearly not what we intended, but that is what many users are doing. See these threads for more context: QSB-068: https://forum.qubes-os.org/t/qsb-068-disconnecting-a-video-output-can-cause-xscreensaver-to-crash/4354 QSB-069: https://forum.qubes-os.org/t/qsb-069-multiple-xen-and-intel-issues/4418 **Describe the solution you'd like** We need to find some way to say, "If you're a normal user, just keep updating normally" while still providing the specific package list for technical readers. One idea is to split the first section into two: the first for any special user action required (usually nothing special), the second for technical info (including the specific package list). But there is a problem with this idea (explained below). Here's an example of how this would have looked for QSB-069: ``` User action required ===================== Users should continue to update normally via the Qubes Update Tool or its command-line equivalents. [1] After the packages associated with this QSB have been installed, dom0 must be restarted 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. Patching ========= The specific packages that address the issues discussed in this bulletin are as follows: 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. [2] [...] References =========== [1] https://www.qubes-os.org/doc/updating-qubes-os/ [2] https://www.qubes-os.org/doc/testing/ ``` As you can see, the problem is that a lot of our QSBs require the user to restart something after the packages are installed in order for the update to take effect (in this case, dom0; for QSB-068, it was XScreenSaver). How are regular users who wait for the packages to land in `current` supposed to know when exactly to restart when the updater doesn't tell them? I guess the only option is for them to closely watch the update output over the next couple of weeks after each QSB is released and carefully compare the package names and versions to those mentioned in the QSB, but we can't honestly expect anyone to do this. The best solution would be to implement some kind of notification system so that we can say: "Security updates have been installed. System restart is required." This notification should work with both the Qubes Update tool and its command-line equivalents. I think it would be simpler just to have something like `update_requires_reboot: [0|1]` to handle all cases. Situations like QSB-068 requiring an XScreenSaver restart would be handled by simply saying that a system restart is required. (Even though it's technically possible to restart only the XScreenSaver daemon or relog the user account, such nuance is just likely to confuse non-technical users, and the marginal benefits are not worth the additional complexity.) This mechanism is most important for security updates, but even non-security updates for Xen and the kernel also require a reboot to take effect. **Where is the value to a user, and who might that user be?** Regular users would be less confused about what to do in response to QSBs and how to handle security updates. This would benefit all regular users who don't already know exactly what to do. **Describe alternatives you've considered** Merely rewording QSBs. See above for why this is problemtic. **Additional context** See these threads for more context: QSB-068: https://forum.qubes-os.org/t/qsb-068-disconnecting-a-video-output-can-cause-xscreensaver-to-crash/4354 QSB-069: https://forum.qubes-os.org/t/qsb-069-multiple-xen-and-intel-issues/4418 **Relevant [documentation](https://www.qubes-os.org/doc/) you've consulted** https://www.qubes-os.org/doc/updating-qubes-os/ https://www.qubes-os.org/doc/testing/ **Related, [non-duplicate](https://www.qubes-os.org/doc/reporting-bugs/#new-issues-should-not-be-duplicates-of-existing-issues) issues** https://github.com/QubesOS/qubes-issues/issues/3430 is closely related but distinct. This issue is only about the Qubes Update tool and its command-line equivalents notifying the user when a restart is required after a update, whereas https://github.com/QubesOS/qubes-issues/issues/3430 also includes things like, "The OS used in this template has reached EOL. Time to replace it with or upgrade it to a supported release."