====================================================================== CERT-Renater Note d'Information No. 2024/VULN340 _____________________________________________________________________ DATE : 26/08/2024 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Xen. ===================================================================== https://xenbits.xen.org/xsa/advisory-461.html https://xenbits.xen.org/xsa/advisory-460.html https://xenbits.xen.org/xsa/advisory-459.html https://xenbits.xen.org/xsa/advisory-458.html _____________________________________________________________________ Xen Security Advisory CVE-2024-31146 / XSA-461 version 2 PCI device pass-through with shared resources UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= When multiple devices share resources and one of them is to be passed through to a guest, security of the entire system and of respective guests individually cannot really be guaranteed without knowing internals of any of the involved guests. Therefore such a configuration cannot really be security-supported, yet making that explicit was so far missing. Resources the sharing of which is known to be problematic include, but are not limited to - - PCI Base Address Registers (BARs) of multiple devices mapping to the same page (4k on x86), - - INTx lines. IMPACT ====== The precise effects when shared resources are in use are system, device, guest, and resource specific. None of privilege escalation, information leaks, or Denial of Service (DoS) can be ruled out. VULNERABLE SYSTEMS ================== All systems making use of PCI pass-through are in principle vulnerable, when any kind of resource is shared. Just to re-iterate, even in the absence of resource sharing caveats apply to passing through of PCI devices to entirely untrusted guests. MITIGATION ========== Passing through only SR-IOV virtual functions or devices with well- separated resources will avoid this particular vulnerability. Passing through all devices sharing a given resource to the same guest will also avoid this particular vulnerability. RESOLUTION ========== Applying the appropriate attached patch documents this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa461.patch xen-unstable - Xen 4.16.x $ sha256sum xsa461* 2415504496508ad87c306aa7257e836d7c2f0bd8849656de5b586f0ab93fd17f xsa461.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of patches or mitigations is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because changing the nature of devices being passed through is very likely noticeable by the guest. Deployment is permitted only AFTER the embargo ends. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html _____________________________________________________________________ Xen Security Advisory CVE-2024-31145 / XSA-460 version 2 error handling in x86 IOMMU identity mapping UPDATES IN VERSION 2 ==================== Wording updated. Public release. ISSUE DESCRIPTION ================= Certain PCI devices in a system might be assigned Reserved Memory Regions (specified via Reserved Memory Region Reporting, "RMRR") for Intel VT-d or Unity Mapping ranges for AMD-Vi. These are typically used for platform tasks such as legacy USB emulation. Since the precise purpose of these regions is unknown, once a device associated with such a region is active, the mappings of these regions need to remain continuouly accessible by the device. In the logic establishing these mappings, error handling was flawed, resulting in such mappings to potentially remain in place when they should have been removed again. Respective guests would then gain access to memory regions which they aren't supposed to have access to. IMPACT ====== The precise impact is system specific. Denial of Service (DoS) affecting the entire host or individual guests, privilege escalation, and information leaks cannot be ruled out. VULNERABLE SYSTEMS ================== Only x86 systems passing PCI devices with RMRR/Unity regions through to guests are potentially affected. PCI devices listed in a vm.cfg file have error handling which causes `xl create` to abort and tear down the domain, and is thus believed to be safe. PCI devices attached using `xl pci-attach` will result in the command returning nonzero, but will not tear down the domain. VMs which continue to run after `xl pci-attach` has failed expose the vulnerability. For x86 Intel hardware, Xen versions 4.0 and later are affected. For all x86 hardware, Xen versions having the XSA-378 fixes applied / backported are affected. MITIGATION ========== Assigning devices using the vm.cfg file for attachment at boot avoids the vulnerability. CREDITS ======= This issue was discovered by Teddy Astie of Vates and diagnosed as a security issue by Jan Beulich of SUSE. RESOLUTION ========== Applying the attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the respective stable branch before applying these patches. xsa460.patch xen-unstable - Xen 4.16.x $ sha256sum xsa460* f4ca598f71e9ef6b9bc50803df2996b92d2e69afd8e36d9544823d7e56ec1819 xsa460.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html _____________________________________________________________________ Xen Security Advisory CVE-2024-31144 / XSA-459 version 2 Xapi: Metadata injection attack against backup/restore functionality UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= For a brief summary of Xapi terminology, see: https://xapi-project.github.io/xen-api/overview.html#object-model-overview Xapi contains functionality to backup and restore metadata about Virtual Machines and Storage Repositories (SRs). The metadata itself is stored in a Virtual Disk Image (VDI) inside an SR. This is used for two purposes; a general backup of metadata (e.g. to recover from a host failure if the filer is still good), and Portable SRs (e.g. using an external hard drive to move VMs to another host). Metadata is only restored as an explicit administrator action, but occurs in cases where the host has no information about the SR, and must locate the metadata VDI in order to retrieve the metadata. The metadata VDI is located by searching (in UUID alphanumeric order) each VDI, mounting it, and seeing if there is a suitable metadata file present. The first matching VDI is deemed to be the metadata VDI, and is restored from. In the general case, the content of VDIs are controlled by the VM owner, and should not be trusted by the host administrator. A malicious guest can manipulate its disk to appear to be a metadata backup. A guest cannot choose the UUIDs of its VDIs, but a guest with one disk has a 50% chance of sorting ahead of the legitimate metadata backup. A guest with two disks has a 75% chance, etc. IMPACT ====== If a fraudulent metadata backup has been written into an SR which also contains a legitimate metadata backup, and an administrator explicitly chooses to restore from backup, the fraudulent metadata might be consumed instead of the legitimate metadata. Control over meta data includes: which VMs are created, disk assignment, vCPU/RAM requirements, GPU allocation, etc. VULNERABLE SYSTEMS ================== Systems running Xapi v1.249.x are affected. Systems running Xapi v24.x are potentially affected. However it is believed that the only supported products using this version of Xapi have not shipped the metadata backup/restore functionality. To leverage the vulnerability, an attacker would likely need insider information to construct a plausible-looking metadata backup, and would have to persuade a real administrator to perform a data-recovery action. MITIGATION ========== Not using the metadata restore functionality avoids the vulnerability. CREDITS ======= This issue was discovered by XenServer. RESOLUTION ========== The attached patches resolve the issue for Xapi v1.249.x releases. xsa459-xen-api.patch (based on v1.249.37) causes all new metadata VDIs to be created with a deterministic UUID, and restore functionality to use that UUID only; not to search all disks to find the metadata. After installing the updated Xapi, a new metadata backup should be taken, to create a VDI with the new deterministic UUID. The ability to restore from an old backup VDI is retained, but the administrator is required to specify the exact VDI to use, so as to avoid searching the SR. Because xsa459-xen-api.patch alters the behaviour of the xe-{backup,restore}-metadata scripts, a companion patch xsa459-xsconsole.patch (based on v10.1.13.1) is needed to keep the pre-existing menu options working, and to ask for user conformation if needing to restore from a prior backup. Note: some work was carried out in public on this issue before the security implications were understood. These changes are present in xen-api.git and tagged as v1.249.37, which is used as the base for this patch. $ sha256sum xsa459* 89dba36a1889a41fbf585a25432079d10991d9e9f3c2d9f93f285c11e17e02c3 xsa459-xen-api.patch 0fc4dabd3a84055644fe415f55d8a1148ad2c17aaa2f8b52889cb11800c612d2 xsa459-xsconsole.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html _____________________________________________________________________ Xen Security Advisory CVE-2024-31143 / XSA-458 version 2 double unlock in x86 guest IRQ handling UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= An optional feature of PCI MSI called "Multiple Message" allows a device to use multiple consecutive interrupt vectors. Unlike for MSI-X, the setting up of these consecutive vectors needs to happen all in one go. In this handling an error path could be taken in different situations, with or without a particular lock held. This error path wrongly releases the lock even when it is not currently held. IMPACT ====== Denial of Service (DoS) affecting the entire host, crashes, information leaks, or elevation of privilege all cannot be ruled out. VULNERABLE SYSTEMS ================== Xen versions 4.4 and newer are vulnerable. Xen versions 4.3 and older are not vulnerable. Only x86 guest which have a multi-vector MSI capable device passed through to them can leverage the vulnerability. MITIGATION ========== Not passing through multi-vector MSI capable devices to x86 guests will avoid the vulnerability. CREDITS ======= This issue was discovered by Jan Beulich of SUSE. RESOLUTION ========== Applying the attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa458.patch xen-unstable - Xen 4.16.x $ sha256sum xsa458* 22dd1071755b1fd6b4ea3ce18a200f626ee796e77b7e7d93a3a5b33d2a896706 xsa458.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patch described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. HOWEVER, deployment of the mitigation is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because removing/replacing of pass-through devices or their replacement by emulated devices is a guest visible configuration change, which may lead to re-discovery of the issue. Deployment of this mitigation is permitted only AFTER the embargo ends. AND: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =========================================================