A new security exploit in the Xen hypervisor raised eyebrows and generated headlines this week.  The uncovered bug in the server virtualization platform could potentially allow guests to escalate their privileges until gaining full control of the hosts they're running on -- guest escape!

The open source Xen hypervisor is used by cloud giants Amazon, IBM and Rackspace.  And it is also the basis of the Qubes OS secure operating system.

The vulnerability was discovered by Jérémie Boutoille of Quarkslab and has been identified as XSA-182 and further identified as CVE-2016-6258.  It affects all versions of Xen; however, it was also reported that the vulnerability is only exposed to paravirtualized or PV guests running on x86 hardware.  The vulnerability is not exposed to x86 systems running full hardware assisted virtualization HVM guests or ARM guests.

Inadequate security checks of how virtual machines access memory means a malicious, paravirtualized guest administrator could raise their system privileges to that of the host on unpatched installations.

The security issue was officially described as such:

The PV pagetable code has fast-paths for making updates to pre-existing pagetable entries, to skip expensive re-validation in safe cases (e.g. clearing only Access/Dirty bits). The bits considered safe were too broad, and not actually safe.

In other words, the security checks implemented for the host server to stop guests from affecting each other's memory didn't always work.  If exploited, a malicious guest could not only obtain full access to the host system but to other VMs running on it as well.  To make matters worse, it was identified that those full security checks were slowing things down, so a shortcut may have been programmed in to address the speed issue but then introduced the loophole for would-be attackers.

Cloud companies like Amazon, IBM and Rackspace should have already been patched.  Cloud vendors typically receive advanced notice in situations like these so they can address the issue internally before the public is notified of the vulnerability.  Amazon even issued their own statement to customers, stating "AWS customers' data and instances are not affected by this issue, and there is no customer action required."

Qubes OS security researcher Joanna Rutkowska discussed this latest security exploit and expressed a few choice words over it and Xen Security in general on GitHub.    

In her GitPub post, Rutkowska writes:

If this sounds familiar to the infamous XSA 148 bug which was disclosed last year [2], it is because it is indeed a very similar type of vulnerability, in almost the same piece of Xen hypervisor code, the code that implements PV memory virtualization. Like XSA 148, this seems to be a fatal security bug which regrettably affects Qubes OS.

An attacker who exploits this bug can break Qubes-provided isolation. This means that if an attacker has already exploited another vulnerability, e.g. in a Web Browser or Networking or USB stack, then the attacker would be able to compromise the whole Qubes system. 

Although she and her team have so far been unable to exploit the bug in their own experiments, they have continued to treat it as a critical bug nevertheless because as she puts it, "the bug does violate some fundamental assumptions about immutability of certain memory mapping structures."

Rutkowska went on to address Xen security in a more critical way, writing:

This bug, being the second critical bug in the Xen PV virtualization code publicly discussed in a relatively short period of time, cannot simply be shrugged off, patched, and forgotten. It begs for answers to critical questions, such as: 1) has Xen been written by competent developers? 2) how many more bugs of this caliber are we going to witness in the future? 3) what can or should we do to protect against such gaping holes?

Like Xen, Qubes OS has offered patches for affected systems and all supported Qubes OS versions.  But Rutkowska said they are taking it one step further with their next release, version 4.0, by moving to hardware memory virtualization.