==================================================================== CERT-Renater Note d'Information No. 2018/VULN214 _____________________________________________________________________ DATE : 28/06/2018 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Xen versions from 3.4 onwards. ===================================================================== https://xenbits.xen.org/xsa/advisory-266.html https://xenbits.xen.org/xsa/advisory-265.html https://xenbits.xen.org/xsa/advisory-264.html _____________________________________________________________________ Xen Security Advisory CVE-2018-12892 / XSA-266 version 3 libxl fails to honour readonly flag on HVM emulated SCSI disks UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= libxl fails to pass the readonly flag to qemu when setting up a SCSI disk, due to what was probably an erroneous merge conflict resolution. IMPACT ====== Malicious guest administrators or (in some situations) users may be able to write to supposedly read-only disk images. VULNERABLE SYSTEMS ================== Only emulated SCSI disks (specified as "sd" in the libxl disk configuration, or an equivalent) are affected. IDE disks ("hd") are not affected (because attempts to make them readonly are rejected). Additionally, CDROM devices (that is, devices specified to be presented to the guest as CDROMs, regardless of the nature of the backing storage on the host) are not affected; they are always readonly. Only systems using qemu-xen (rather than qemu-xen-traditional) as the device model version are vulnerable. Only systems using libxl or libxl-based toolstacks are vulnerable. (This includes xl, and libvirt with the libxl driver.) The vulnerability is present in Xen versions 4.7 and later. (In earlier versions, provided that the patch for XSA-142 has been applied, attempts to create readonly disks are rejected.) If the host and guest together usually support PVHVM, the issue is exploitable only if the malicious guest administrator has control of the guest kernel or guest kernel command line. MITIGATION ========== Switching to qemu-xen-traditional will avoid this vulnerability. This can be done with device_model_version="qemu-xen-traditional" in the xl configuration file. Using stub domain device models (which necessarily involves switching to qemu-xen-traditional) will also avoid this vulnerability. This can be done with device_model_stubdomain_override=true in the xl configuration file. All of these mitigations are liable to have other guest-visible effects or even regressions. It may be possible, depending on the configuration, to make the underlying storage object readonly, or to make it reject writes. CREDITS ======= This issue was discovered by Andrew Reimers of OrionVM. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa266/*.patch xen-unstable xsa266-4.10/*.patch Xen 4.10.x xsa266-4.9/*.patch Xen 4.9.x xsa266-4.8/*.patch Xen 4.8.x xsa266-4.7/*.patch Xen 4.7.x xsa266-4.6/*.patch Xen 4.6.x $ sha256sum xsa266* xsa266*/* d0d998bb3c2f36b0795cdf86d52aa2da3eee72218f9073f398fc6fd2cf5719cd xsa266.meta 0e5634c9b730e2e022bfef9ded2bb81b7740d05911dae6499671db5cb90663c0 xsa266-4.7/0001-libxl-qemu_disk_scsi_drive_string-Break-out-common-p.patch e6dcef1bdd890a245cb9181266fc1378d77b08cf06c063f35a0835ab3b99cf91 xsa266-4.7/0002-libxl-restore-passing-readonly-to-qemu-for-SCSI-disk.patch 19ce6f236702219eb4831ed597f82dc81122fd517131e826643cee95b53d9f1c xsa266-4.8/0001-libxl-qemu_disk_scsi_drive_string-Break-out-common-p.patch e0a4c616218bc42abada75aa5fa0c3e35da6b6334fe50d6104a5892ffebcdb04 xsa266-4.8/0002-libxl-restore-passing-readonly-to-qemu-for-SCSI-disk.patch 9fd48f20da140731bb71dde07035b938cf0966339449a0b6833787767c588c0a xsa266-4.9/0001-libxl-qemu_disk_scsi_drive_string-Break-out-common-p.patch f23d0e76f15b1f6af487adc36a84cf2591197548ca7cab8ee84be72a87424cf7 xsa266-4.9/0002-libxl-restore-passing-readonly-to-qemu-for-SCSI-disk.patch 3d857f38d11b5531a651a45c2f151ac1493260524d4f49ead6833b5f1d599e64 xsa266-4.10/0001-libxl-qemu_disk_scsi_drive_string-Break-out-common-p.patch e380976abd77b5b46d69c9564aca3acf9bf467b36645ac34e035aba89d081591 xsa266-4.10/0002-libxl-restore-passing-readonly-to-qemu-for-SCSI-disk.patch 160dc8c8a918cae7259c252af098206f9eff357e52bdfc0b15553e9c31c587e6 xsa266/0001-libxl-qemu_disk_scsi_drive_string-Break-out-common-p.patch 2b44fd6baac094c82145667a16d9b1530b97fa342d0e635c831425b53a336266 xsa266/0002-libxl-restore-passing-readonly-to-qemu-for-SCSI-disk.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 all of the patches and mitigations make significant guest-visible changes. In particular, applying the patch will cause the emulated SCSI disk object to be reported to the guest as readonly, when previously it was reported as writeable. 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-2018-12893 / XSA-265 version 3 x86: #DB exception safety check can be triggered by a guest UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= One of the fixes in XSA-260 added some safety checks to help prevent Xen livelocking with debug exceptions. Unfortunately, due to an oversight, at least one of these safety checks can be triggered by a guest. IMPACT ====== A malicious PV guest can crash Xen, leading to a Denial of Service. VULNERABLE SYSTEMS ================== All Xen systems which have applied the XSA-260 fix are vulnerable. Only x86 systems are vulnerable. ARM systems are not vulnerable. Only x86 PV guests can exploit the vulnerability. x86 HVM and PVH guests cannot exploit the vulnerability. An attacker needs to be able to control hardware debugging facilities to exploit the vulnerability, but such permissions are typically available to unprivileged users. MITIGATION ========== Running only x86 HVM or PVH guests will avoid the vulnerability. CREDITS ======= This issue was discovered by Andrew Cooper of Citrix. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa265.patch xen-unstable, Xen 4.10.x, 4.9.x, 4.8.x xsa265-4.7.patch Xen 4.7.x, 4.6.x $ sha256sum xsa265* 3eb66ed7251dcc4259eeffe608b2747857e269307d894a1cb950973420184aa7 xsa265.patch 00faf2a4159698b6540565ece06de103c3547855e2084324ca44772b8a24aa18 xsa265-4.7.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-2018-12891 / XSA-264 version 3 preemption checks bypassed in x86 PV MM handling UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= Certain PV MMU operations may take a long time to process. For that reason Xen explicitly checks for the need to preempt the current vCPU at certain points. A few rarely taken code paths did bypass such checks. By suitably enforcing the conditions through its own page table contents, a malicious guest may cause such bypasses to be used for an unbounded number of iterations. IMPACT ====== A malicious or buggy PV guest may cause a Denial of Service (DoS) affecting the entire host. Specifically, it may prevent use of a physical CPU for an indeterminate period of time. VULNERABLE SYSTEMS ================== All Xen versions from 3.4 onwards are vulnerable. Xen versions 3.3 and earlier are vulnerable to an even wider class of attacks, due to them lacking preemption checks altogether in the affected code paths. Only x86 systems are affected. ARM systems are not affected. Only multi-vCPU x86 PV guests can leverage the vulnerability. x86 HVM or PVH guests as well as x86 single-vCPU PV ones cannot leverage the vulnerability. MITIGATION ========== Running only HVM, PVH, or single-vCPU PV guests will avoid this vulnerability. For PV guests, the vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS ======= This issue was discovered by Jan Beulich of SUSE. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa264.patch xen-unstable xsa264-4.10.patch Xen 4.10.x ... 4.6.x $ sha256sum xsa264* a7d2edf219af3375ac0d49bff9e64628c70e704fcf131ea21684694517aa9210 xsa264.patch 66aca234b168abc01f28fe131b7e07645a73fd5d0f1d141d68343f31914d96cc xsa264-4.10.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 + =========================================================