-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2015-7311 / XSA-142 version 3 libxl fails to honour readonly flag on disks with qemu-xen UPDATES IN VERSION 3 ==================== Normalize version tags. ISSUE DESCRIPTION ================= Callers of libxl can specify that a disk should be read-only to the guest. However, there is no code in libxl to pass this information to qemu-xen (the upstream-based qemu); and indeed there is no way in qemu to make a disk read-only. The vulnerability is exploitable only via devices emulated by the device model, not the parallel PV devices for supporting PVHVM. Normally the PVHVM device unplug protocol renders the emulated devices inaccessible early in boot. IMPACT ====== Malicious guest administrators or (in some situations) users may be able to write to supposedly read-only disk images. 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. VULNERABLE SYSTEMS ================== 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.) All versions of libxl which support qemu-xen are vulnerable. The affected code was introduced in Xen 4.1. 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. Either of these mitigations is 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. RESOLUTION ========== There is no reasonable resolution because Qemu does not (at the time of writing) support presenting a read-only block device to a guest as a disk. The attached patch corrects the weakness in the libxl code, by rejecting the unsupported configurations, rather than allowing them to run but with the device perhaps writeable by the guest. Applying it should increase confidence and avoid future configuration errors, but will break affected configurations specifying read-only disk devices. xsa142-4.6.patch xen-unstable - Xen 4.6.x xsa142-4.5.patch Xen 4.5.x - 4.3.x xsa142-4.2.patch Xen 4.2.x $ sha256sum xsa142*.patch 15e27d28a6f1f2a92758e023ed55b1e74dd50103be2635e4a6c63b10e4afbb14 xsa142-4.2.patch 9ec0649f39720bc692be03c87ebea0506d6ec574f339fc745e41b31643240124 xsa142-4.5.patch 65f01167bfc141048261f56b99ed9b48ec7ff6e98155454ced938a17ec20e7d1 xsa142-4.6.patch $ NOTE REGARDING LACK OF EMBARGO ============================== This issue was discussed in public in the Red Hat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1257893 CREDITS ======= Thanks to Michael Young of Durham University for bring this problem to our attention. -----BEGIN PGP SIGNATURE----- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmV8b/AMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZg2QH/jlEJ7XPjbccXCeTDG0rRo0hirk2zdcX/CNc0BYa 9ic1KpAGluElDxAfshWpUKDoIGM02vahGXebzh50TgFBzbeTZdiROEt84v8GUfw/ x65GP9SghdPTQTjAZVKbk6CX4IDrGpW4OCaN+lFW6OC1UAi5H0LRR2NMfDuQGy9w n1nqTwUGKZMgvxiWEhKC78A6l9yYNPVXPQ52xTK0trNDulPCI2oWiaTq70ymDBRt 0xTvW4IU18WSlLhcSebPTR9bGvAEiRYYiEMxePsA8570CIFXNWKje8nl4uaDzDn5 2JfMtTbSw7c0Q1mbqYo/DOP3a1q9+rJ0MbiABZ2EwGGDBgc= =00XJ -----END PGP SIGNATURE-----