Today we released three patches for the following vulnerabilities: XSA-213, XSA-214 and XSA-215. Xen Project follows industry-accepted best practices regarding software security. This includes observing an embargo period, during which time the Xen Project security team will assess, respond, and prepare patches fixing the vulnerability, and distribute them privately to software and cloud providers before the public disclosure occurs.
When issuing a Xen Project Security Advisory (XSA), during the embargo this advisory is pre-disclosed to only members on the Xen Project Pre-Disclosure List. Vendors and open source projects who are on the Xen Project pre-disclosure list will not be affected by this security vulnerability and have updated their systems. The Xen Project security team has created fixes for these vulnerabilities, which can be publicly downloaded here: http://xenbits.xen.org/xsa/
Public cloud providers on the Xen Project predisclosure list were notified of these vulnerabilities two weeks ago; if your public cloud provider is on the list it is likely that your VMs are not vulnerable. Distributions and other software providers were also notified; they should have updated packages available soon (if they are not available already).
All three vulnerabilities have the potential to enable a guest virtual machine to break out of the hypervisor isolation. However, in order to exploit this vulnerability, an attacker would need to be running code in kernel mode of one or more VMs on the system. Any system that allows untrusted users to run arbitrary kernels will be particularly vulnerable.
Systems which only allow trusted users (such as IT professionals employed by the company) to run arbitrary kernels are less vulnerable, because an attacker would first need to find one or more exploit in the software running on one of the VMs before being able to then exploit this vulnerability. However, all users are encouraged to update as soon as possible.
Any 64-bit PV guest can exploit the vulnerability with XSA-213. The other two are more constrained. XSA-214 requires an attacker to control two different kinds of guests (either a PV one and an HVM one or a 32-bit PV one and 64-bit PV one). XSA-215 only affects you if your host has a very large amount of memory (either 3.5 TiB or 5 TiB depending on configuration).
Again, even with these constraints, we encourage you to update as soon as possible.
We take security very seriously and have developed security process best practices that are aimed for cloud environments that maximize fairness and transparency. We also have a very strict standard of review when it comes to new code being added to the Xen Project. We run Coverity static analyzer regularly to prevent certain classes of programming errors from being introduced. Additionally, we regularly run a generational fuzzing tool on our instruction emulator.
The Xen Project community developed Live Patching and introduced it into Xen Project 4.7. Now security fixes can be deployed without having to reboot VMs or have significant spare compute capacity to avoid reboots via VM migration.
These vulnerabilities were discovered by Jann Horn, from Google Project Zero.