===================================================================== CERT-Renater Note d'Information No. 2021/VULN670 _____________________________________________________________________ DATE : 21/12/2021 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Xen. ===================================================================== http://xenbits.xen.org/xsa/advisory-376.html http://xenbits.xen.org/xsa/advisory-391.html _____________________________________________________________________ Xen Security Advisory XSA-376 frontends vulnerable to backends ISSUE DESCRIPTION ================= Xen offers the ability to run PV backends in regular unprivileged guests, typically referred to as "driver domains". Running PV backends in driver domains has one primary security advantage: if a driver domain gets compromised, it doesn't have the privileges to take over the system. However, a malicious driver domain could try to attack other guests via the PV protocol. Many PV frontends are hardened against misbehaving PV backends, but a few of them are not and might be susceptible to Denial of Service attacks and metadata manipulation triggered by malicious PV backends. IMPACT ====== Potentially malicious PV backends can cause guest DoS due to unhardened frontends in the guests, even though this ought to have been prevented by containing them within a driver domain. VULNERABLE SYSTEMS ================== All guests with non-hardened frontends being serviced by potentially malicious backends are vulnerable, even if those backends are running in a less privileged environment. The vulnerability is not affecting the host, but the guests using non-hardened frontends. The console, block and net frontends have been hardened in the Linux kernel 5.16, so guests running Linux with kernel 5.16 or newer are not currently known to be vulnerable to potentially malicious console, block or net backends. MITIGATION ========== In case of running potentially malicious backends, using only hardened frontend counterparts in guests will mitigate the problem. NOTE REGARDING LACK OF EMBARGO ============================== This issue was discussed in public already. RESOLUTION ========== The related patch is just a clarification of the security statement, so it will NOT mitigate anything. As there is no urgent need for this patch to go into the Xen tree it will be posted on the xen-devel mailing list after disclosure of this advisory. xsa376.patch xen-unstable $ sha256sum xsa376* b18551f7800d5a232bbe6953b1222ecb2c5a2058285c6fbc8d64f9b7dea2415f xsa376.patch $ _____________________________________________________________________ Xen Security Advisory CVE-2021-28711,CVE-2021-28712,CVE-2021-28713 / XSA-391 version 3 Rogue backends can cause DoS of guests via high frequency events UPDATES IN VERSION 3 ==================== Public release ISSUE DESCRIPTION ================= Xen offers the ability to run PV backends in regular unprivileged guests, typically referred to as "driver domains". Running PV backends in driver domains has one primary security advantage: if a driver domain gets compromised, it doesn't have the privileges to take over the system. However, a malicious driver domain could try to attack other guests via sending events at a high frequency leading to a Denial of Service in the guest due to trying to service interrupts for elongated amounts of time. There are three affected backends: * blkfront patch 1, CVE-2021-28711 * netfront patch 2, CVE-2021-28712 * hvc_xen (console) patch 3, CVE-2021-28713 IMPACT ====== Potentially malicious PV backends can cause guest DoS due to unhardened frontends in the guests, even though this ought to have been prevented by containing them within a driver domain. VULNERABLE SYSTEMS ================== All guests being serviced by potentially malicious backends are vulnerable, even if those backends are running in a less privileged environment. The vulnerability is not affecting the host, but the guests. MITIGATION ========== There is no known mitigation available. RESOLUTION ========== Applying the attached patches resolves this issue. xsa391-linux-1.patch Linux 5.15 xsa391-linux-2.patch Linux 5.15 xsa391-linux-3.patch Linux 5.15 $ sha256sum xsa391* e55d3f15a85ff31e62a291981de89f7b0c08da807db9b2a6a2b9cbb2e29847cd xsa391-linux-1.patch 163fc4b9966768eb74e3bc1858a0b0254eff771898bd5f4d71806beeae0ffd2a xsa391-linux-2.patch de888abe8d11d3204b4033b304cf3d66104a65956089e23f1736db682d3cedc4 xsa391-linux-3.patch $ CREDITS ======= This issue was discovered by Jurgen Gross of SUSE. 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 the patches need to be applied to the guests, which will be visible by the guest administrators. 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 ========================================================= + 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 + =========================================================