The Xen Project has fixed three vulnerabilities in its widely used hypervisor that could allow operating systems running inside virtual machines (VM) to access the memory of the host systems, breaking the critical security layer among them.
Two of the patched vulnerabilities can only be exploited under certain conditions, which limits their use in potential attacks, but one is a highly reliable flaw that poses a serious threat to multitenant data centres where the customers’ virtualised servers share the same underlying hardware.
The flaws do not yet have CVE tracking numbers, but are covered in three Xen security advisories, XSA-213, XSA-214 and XSA-215.
Reliably exploitable
“XSA-213 is a fatal, reliably exploitable bug in Xen,” said the security team of Qubes OS, an operating system that isolates applications inside Xen virtual machines. “In the nearly eight-year history of the Qubes OS project, we have become aware of four bugs of this calibre: XSA-148, XSA-182, XSA-212 and now XSA-213.”
Of these four highly critical and easy to exploit vulnerabilities, three have been found and patched over the past 10 months and two over the past month—XSA-182 was fixed in July 2016, XSA-212 in April and XSA-213 on Tuesday.
Another commonality is that all of them affected the Xen memory virtualisation for paravirtualised (PV) VMs. Xen supports two types of virtual machines: Hardware Virtual Machines (HVMs), which use hardware-assisted virtualisation, and paravirtualised VMs that use software-based virtualisation.
The other two flaws patched Tuesday, XSA-214 and XSA-215, also affect paravirtualised VMs. The difference is that XSA-214 requires two malicious guest VMs to work together in order to access the system memory, while XSA-215 only affects “x86 systems with physical memory extending to a configuration dependent boundary of 5TB or 3.5TB.”
One limitation for XSA-213 is that it can only be exploited from 64-bit PV guests, so systems running only HVM or 32-bit PV guests are not affected.
Patch release
The Xen developers released patches for Xen 4.8.x, Xen 4.7.x, Xen 4.6.x and Xen 4.5.x that can be applied manually to affected systems.
The open-source Xen hypervisor is used by many cloud computing providers and virtual private server (VPS) hosting companies, some of which received the patches in advance and were forced to schedule maintenance downtimes.
For example, VPS provider Linode had to reboot some of its legacy Xen PV hosts in order to apply the fix and advised customers to move to its HVM-based servers to avoid future downtimes.
Meanwhile, Amazon Web Services said that its customers’ data and instances were not affected by these vulnerabilities and no customer action was required.
The Qubes OS team, which prides itself on building one of the most secure desktop operating systems, has had enough of having to repeatedly deal with Xen PV vulnerabilities. That’s why, over the past 10 months, it has put in extra work to switch the next version of the OS—Qubes 4.0—to HVM.
PVH mode transition
“We originally hoped we could transition to running all Linux VMs in a so-called PVH mode of virtualisation, where the I/O emulator is not needed at all, but it turned out the Linux kernel is not quite ready for this,” the Qubes team said in an analysis of the latest Xen patches. “So, in Qubes 4.0, we will use the classic HVM mode, where the I/O emulator is sandboxed within… a PV VM (which is also the case when one runs Windows AppVMs on Qubes 3.x).”
The good news is that the groundwork is set to switch Qubes to PVH in the future when the Linux kernel adds the needed support, and even to replace Xen entirely with something else, if a better alternative comes along.
IDG News Service
Subscribers 0
Fans 0
Followers 0
Followers