===================================================================== CERT-Renater Note d'Information No. 2014/VULN080 _____________________________________________________________________ DATE : 27/03/2014 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Xen versions from 4.1.x, Xen using Linux as the driver domain. ====================================================================== http://xenbits.xenproject.org/xsa/advisory-89.html http://xenbits.xenproject.org/xsa/advisory-90.html ______________________________________________________________________ Xen Security Advisory XSA-89 version 2 HVMOP_set_mem_access is not preemptible UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= Processing of the HVMOP_set_mem_access HVM control operations does not check the size of its input and can tie up a physical CPU for extended periods of time. IMPACT ====== In a configuration where device models run with limited privilege (for example, stubdom device models), a guest attacker who successfully finds and exploits an unfixed security flaw in qemu-dm could leverage the other flaw into a Denial of Service affecting the whole host. In the more general case, in more abstract terms: a malicious administrator of a domain privileged with regard to an HVM guest can cause Xen to become unresponsive leading to a Denial of Service. VULNERABLE SYSTEMS ================== All Xen versions from 4.1 onwards are vulnerable. In 4.2 only 64-bit versions of the hypervisor are vulnerable (HVMOP_set_mem_access is not available in 32-bit hypervisors). The vulnerability is only exposed to service domains for HVM guests which have privilege over the guest. In a usual configuration that means only device model emulators (qemu-dm). In the case of HVM guests whose device model is running in an unrestricted dom0 process, qemu-dm already has the ability to cause problems for the whole system. So in that case the vulnerability is not applicable. The situation is more subtle for an HVM guest with a stub qemu-dm. That is, where the device model runs in a separate domain (in the case of xl, as requested by "device_model_stubdomain_override=1" in the xl domain configuration file). The same applies with a qemu-dm in a dom0 process subjected to some kind kernel-based process privilege limitation (eg the chroot technique as found in some versions of XCP/XenServer). In those latter situations this issue means that the extra isolation does not provide as good a defence (against denial of service) as intended. That is the essence of this vulnerability. However, the security is still better than with a qemu-dm running as an unrestricted dom0 process. Therefore users with these configurations should not switch to an unrestricted dom0 qemu-dm. Finally, in a radically disaggregated system: where the HVM service domain software (probably, the device model domain image) is not always supplied by the host administrator, a malicious service domain administrator can excercise this vulnerability. MITIGATION ========== Running only PV guests will avoid this vulnerability. In a radically disaggregated system, restricting HVM service domains to software images approved by the host administrator will avoid the vulnerability. CREDITS ======= This issue was discovered by Jan Beulich. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa89.patch xen-unstable, Xen 4.4.x, Xen 4.3.x, Xen 4.2.x xsa89-4.1.patch Xen 4.1.x $ sha256sum xsa89*.patch 741c8fbbfa8e425d8debba17135d4c2e1e962d15717769bc93d68a65b5dc5ea6 xsa89.patch 7d965e9bf1894b7d909bfaddbc6b7bdcee0ba91b86942ce85e0ae80464f2463e xsa89-4.1.patch $ ___________________________________________________________________ Xen Security Advisory XSA-90 Linux netback crash trying to disable due to malformed packet ISSUE DESCRIPTION ================= When Linux's netback sees a malformed packet, it tries to disable the interface which serves the misbehaving frontend. This involves taking a mutex, which might sleep. But in recent versions of Linux the guest transmit path is handled by NAPI in softirq context, where sleeping is not allowed. The end result is that the backend domain (often, Dom0) crashes with "scheduling while atomic". IMPACT ====== Malicious guest administrators can cause denial of service. If driver domains are not in use, the impact is a host crash. VULNERABLE SYSTEMS ================== This bug affects systems using Linux as the driver domain, including non-disaggregated systems using Linux as dom0. Only versions of Linux whose netback uses NAPI are affected. In Linux mainline this is all versions of Linux containing git changeset b3f980bd82, which was introduced between Linux 3.11 and 3.12-rc1. Systems using a different OS as dom0 (eg, NetBSD, Solaris) are not vulnerable. Both x86 and ARM systems are affected. MITIGATION ========== Using driver domains may limit the scope of the denial of service, and may make it possible to resume service without restarting guests (by restarting the driver domain). Advice on reconfiguring a system to use driver domains is beyond the reasonable scope of this advisory. In the case of an x86 HVM guest, the exploit can be prevented by disabling the PV IO paths; normally this would come with a substantial performance cost, and it may involve reconfiguring the guest as well as the host. This is not recommended. NOTE REGARDING LACK OF EMBARGO ============================== This bug was publicly reported on xen-devel, before it was appreciated that there was a security problem. The public mailing list thread nevertheless contains information strongly suggestive of a security bug, and a different security bug (with CVE) is suggested as seeming "similar". For these reasons we (the Xen Project Security Team) have concluded that the presence of this bug, as a security problem, is not (any longer) a secret. CREDITS ======= This issue was discovered as a bug by Török Edwin and analysed by Wei Liu of Citrix. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. $ sha256sum xsa90*.patch 07341ffb7f577d32510602797a08009eade817009b425a124413ee743bdb6f05 xsa90.patch $ ========================================================= Serveur de référence du CERT-Renater https://services.renater.fr/ssi/ ========================================================== + 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 + ==========================================================