=================================================================== CERT-Renater Note d'Information No. 2023/VULN105 _____________________________________________________________________ DATE : 22/03/2023 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Xen. ====================================================================https://xenbits.xen.org/xsa/advisory-427.html https://xenbits.xen.org/xsa/advisory-428.html https://xenbits.xen.org/xsa/advisory-429.html _____________________________________________________________________ Xen Security Advisory CVE-2022-42332 / XSA-427 version 2 x86 shadow plus log-dirty mode use-after-free UPDATES IN VERSION 2 ==================Public release. ISSUE DESCRIPTION ===============In environments where host assisted address translation is necessary but Hardware Assisted Paging (HAP) is unavailable, Xen will run guests in so called shadow mode. Shadow mode maintains a pool of memory used for both shadow page tables as well as auxiliary data structures. To migrate or snapshot guests, Xen additionally runs them in so called log-dirty mode. The data structures needed by the log-dirty tracking are part of aformentioned auxiliary data. In order to keep error handling efforts within reasonable bounds, for operations which may require memory allocations shadow mode logic ensures up front that enough memory is available for the worst case requirements. Unfortunately, while page table memory is properly accounted for on the code path requiring the potential establishing of new shadows, demands by the log-dirty infrastructure were not taken into consideration. As a result, just established shadow page tables could be freed again immediately, while other code is still accessing them on the assumption that they would remain allocated. IMPACT ====Guests running in shadow mode and being subject to migration or snapshotting may be able to cause Denial of Service and other problems, including escalation of privilege. VULNERABLE SYSTEMS ================All Xen versions from at least 3.2 onwards are vulnerable. Earlier versions have not been inspected. Only x86 systems are vulnerable. The vulnerability is limited to migration and snapshotting of guests, and only to PV ones as well as HVM or PVH ones run with shadow paging. MITIGATION ========Not migrating or snapshotting guests will avoid the vulnerability. Running only HVM or PVH guests and only in HAP (Hardware Assisted Paging) mode will also avoid the vulnerability. CREDITS =====This issue was discovered by Jan Beulich of SUSE. RESOLUTION ========Applying the appropriate 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. xsa427.patch xen-unstable - Xen 4.17.x xsa427-4.16.patch Xen 4.16.x xsa427-4.15.patch Xen 4.15.x xsa427-4.14.patch Xen 4.14.x $ sha256sum xsa427* 5ebcdc495ba6f439e47be7e17dbb8fbdecf4de66d2fac560d460f6841bd3bef3 xsa427.meta aa39316cbb81478c62b3d5c5aea7edfb6ade3bc5e6d0aa8c4677f9ea7bcc97a2 xsa427.patch 5ba679bc2170b0d9cd4c6ce139057e3287a6ee00434fa0e9a7a02441420030ff xsa427-4.14.patch 410ee6be28412841ab5aba1131f7dd7b84b9983f6c93974605f196fd278562e1 xsa427-4.15.patch 76c1850eb9a274c1feb5a8645f61ecf394a0551278f4e40e123ec07ea307f101 xsa427-4.16.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-2022-42333,CVE-2022-42334 / XSA-428 version 3 x86/HVM pinned cache attributes mis-handling UPDATES IN VERSION 3 ==================Public release. ISSUE DESCRIPTION ===============To allow cachability control for HVM guests with passed through devices, an interface exists to explicitly override defaults which would otherwise be put in place. While not exposed to the affected guests themselves, the interface specifically exists for domains controlling such guests. This interface may therefore be used by not fully privileged entities, e.g. qemu running deprivileged in Dom0 or qemu running in a so called stub-domain. With this exposure it is an issue that - the number of the such controlled regions was unbounded (CVE-2022-42333), - installation and removal of such regions was not properly serialized (CVE-2022-42334). IMPACT ====Entities controlling HVM guests can run the host out of resources or stall execution of a physical CPU for effectively unbounded periods of time, resulting in a Denial of Servis (DoS) affecting the entire host. Crashes, information leaks, or elevation of privilege cannot be ruled out. VULNERABLE SYSTEMS ================Xen versions 4.11 through 4.17 are vulnerable. Older versions contain the same functionality, but it is exposed there only via an interface which is subject to XSA-77's constraints. Only x86 systems are potentially vulnerable. Arm systems are not vulnerable. Only entities controlling HVM guests can leverage the vulnerability. These are device models running in either a stub domain or de-privileged in Dom0. MITIGATION ========Running only PV or PVH guests will avoid the vulnerability. (Switching from a device model stub domain or a de-privileged device model to a fully privileged Dom0 device model does NOT mitigate this vulnerability. Rather, it simply recategorises the vulnerability to hostile management code, regarding it "as designed"; thus it merely reclassifies these issues as "not a bug". The security of a Xen system using stub domains is still better than with a qemu-dm running as a Dom0 process. Users and vendors of stub qemu dm systems should not change their configuration to use a Dom0 qemu process.) CREDITS =====Aspects of this issue were discovered by Andrew Cooper of XenServer and Jan Beulich of SUSE. RESOLUTION ========Applying the appropriate set of attached patches 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. xsa428-?.patch xen-unstable xsa428-4.17-?.patch Xen 4.17.x xsa428-4.16-?.patch Xen 4.16.x - 4.14.x $ sha256sum xsa428* a7bd8d4c1e8579aeda47564efdc960cac92472387ba57d7f7a6d5d79470ebd6f xsa428.meta 85a421d9123a56894124bed54731b8b6f2e86ad4e286871dee86efff519f4c68 xsa428-1.patch 3b691ca228592539a751ce5af69f31e09d9c477218d53af0602ac5f39f1e74d7 xsa428-2.patch da60e01a17f9073c83098d187c07bad3a868a6b7f97dbc538cb5ea5698c51b39 xsa428-4.16-1.patch 27718a7a86fd57624cd8500df83eb42ff3499670bc807c6555686c25e7f7b01a xsa428-4.16-2.patch da60e01a17f9073c83098d187c07bad3a868a6b7f97dbc538cb5ea5698c51b39 xsa428-4.17-1.patch 20d3b66da8fe06d7e92992218e519f4f9746791d4ba5610d84a335f38a824fcb xsa428-4.17-2.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-2022-42331 / XSA-429 version 3 x86: speculative vulnerability in 32bit SYSCALL path UPDATES IN VERSION 3 ==================Public release. ISSUE DESCRIPTION ===============Due to an oversight in the very original Spectre/Meltdown security work (XSA-254), one entrypath performs its speculation-safety actions too late. In some configurations, there is an unprotected RET instruction which can be attacked with a variety of speculative attacks. IMPACT ====An attacker might be able to infer the contents of arbitrary host memory, including memory assigned to other guests. VULNERABLE SYSTEMS ================Xen versions 4.5 through 4.17 are vulnerable. Older versions are not vulnerable. Only x86 CPUs are potentially vulnerable. CPUs of other architectures are not vulnerable. The problematic codepath is only reachable on x86 CPUs which follow AMD's behaviour with respect to SYSCALL instructions from compatibility mode segments. This means that AMD and Hygon CPUs are potentially vulnerable, whereas Intel CPUs are not. Other vendors have not been checked. Only PV guests can leverage the vulnerability. On Xen 4.16 and later, the vulnerability is only present if 32bit PV guest support is compiled in - i.e. CONFIG_PV32=y. On Xen 4.15 and older, all supported build configurations are vulnerable. The vulnerability is only present when booting on hardware that supports SMEP or SMAP (Supervisor Mode Execution/Access Prevention). This is believed to be some Family 0x16 models, and all later CPUs. MITIGATION ========Not running untrusted PV guests will avoid the issue. CREDITS =====This issue was discovered by Andrew Cooper of XenServer. RESOLUTION ========Applying the appropriate 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. xsa429.patch xen-unstable - Xen 4.16 xsa429-4.15.patch Xen 4.15 - Xen 4.14 $ sha256sum xsa429* 2d7be90d917c475ab5217e657d2b44f5d8b107d9023dca034fcfb7feab07b2f0 xsa429.meta 36ed36dbfaad9e5df5fa87b9a3d9e9c531f476f97eeb2afe280aa238032a0540 xsa429.patch 7ac3d4182585e5d2d39231f10e7c0c9fcb972c82cf81cb884e95b628187de3a7 xsa429-4.15.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 ========================================================+ 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 + =======================================================