eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The open-source Xen hypervisor is widely used to help enable public cloud operations. Back in October 2014, a vulnerability in Xen led to a reboot of public cloud services at Amazon, Rackspace and IBM SoftLayer. This week a new vulnerability was disclosed in Xen, with the potential to enable a guest virtual machine to break out of the hypervisor isolation. But in contrast to the issue in 2014, the new XSA-212 vulnerability did not require a reboot of the public cloud.
The promise of guest virtual machine isolation is a core element of virtualization hypervisor security. The new XSA-212 vulnerability, also known as CVE-2017-7228, is titled by the open-source project as, ‘broken check in memory_exchange() permits PV guest breakout.’ The flaw was reported to the project by Google Project Zero security researcher Jann Horn.
“A malicious or buggy 64-bit PV guest may be able to access all of system memory, allowing for all of privilege escalation, host crashes, and information leaks,” the Xen advisory warns. PV refers to Paravirtualization and is a different from of virtualization than Hardware Virtualization, also referred to as HVM. With PV a host operating system is able make use of virtualization without needed specific hypervisor extensions on the server’s CPU.
As it turn out, the vulnerability does not impact HVM guests, restricting the impact only to x86 64-bit PV guests. Additionally, the Xen advisory notes that the vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator.
Disclosure Process
Ever since the 2014 incident, Xen has had a very mature process for handling security vulnerabilities, which played out well with the new XSA-212 issue. Xen Project Chairperson Lars Kurth explained that there was nothing unusual about XSA-212 from a process perspective. He said that the bug was pre-released to members of the Xen pre-disclosure list on March 22 and released on April 4.
“This gave service providers and software vendors on our pre-disclosure list two weeks to verify whether they are affected and if so, address the issue in private and update their systems, such that their users would not be impacted by this XSA,” Kurth told eWEEK. ” The timing and process worked exactly as designed according to our security process. ”
Kurth noted that the Xen Project constantly refines its processes, both in terms of how the Xen Security Team works and in terms of the public facing process. That said, he noted that Xen Project Security Response Process has been very stable and has been working extremely well.
For the XSA-212 issue itself, it was actually first introduced into the Xen Project code in December 2012, where it lay dormant until being discovered in 2017. Kurth said that the flaw was a logical error that could have been spotted sooner. Kurth added that Xen Project makes use of static code analysis tools, such as Coverity, to look at the code base. Additionally, Xen makes use of fuzzing tools including American Fuzzy Lop to look at code to find potential flaws. That said, Kurth noted that tools such as Coverity and AFL will not be able to detect certain classes of bugs.
From a deployment perspective for the patch, while the XSA-108 issue in 2014 required a system reboot, the same is not true for the new XSA-212 issue for a number of reasons.
“After XSA-108, a number of contributors including AWS, Alibaba, Citrix, SUSE and Oracle collaborated on first defining a specification for Live Patching, which was subsequently implemented by Citrix and Oracle and first released in Xen 4.7,” Kurth explained. “Now security fixes can be deployed without having to reboot VMs or having significant spare compute capacity to avoid reboots via VM migration.”
“This means that the cloud reboot” as triggered by XSA-108 should now be a thing of the past,” he said.