Xen patches 7-year-old bug that shattered hypervisor security

Nytro · October 30, 2015

Critical vulnerability allowed some guests to access underlying operating system.

by Dan Goodin - Oct 29, 2015 7:34pm EET

For seven years, Xen virtualization software used by Amazon Web Services and other cloud computing providers has contained a vulnerability that allowed attackers to break out of their confined accounts and access extremely sensitive parts of the underlying operating system. The bug, which some researchers say is probably the worst ever to hit the open source project, was finallymade public Thursday along with a patch.

"Venom" allows attackers to break out of guest OS, escape into host. Patch now!

As a result of the bug, "malicious PV guest administrators can escalate privilege so as to control the whole system," Xen Project managers wrote in an advisory. The managers were referring to an approach known as paravirtualization, which allows multiple lower-privileged users to run highly isolated computing instances on the same piece of hardware. By allowing guests to break out of those confines, CVE-2015-7835, as the vulnerability is indexed, compromised a core tenet of virtualization. It comes five months after a similarly critical bug was disclosed in the Xen, KVM, and native QEMU virtual machine platforms."The above is a political way of stating the bug is a very critical one," researchers with Qubes OS, a desktop operating system that uses Xen to secure sensitive resources, wrote in an analysis published Thursday. "Probably the worst we have seen affecting the Xen hypervisor, ever. Sadly."

Thursday's disclosure comes a few weeks after Xen Project managers privately warned a select group of predisclosure members of the vulnerability. That means Amazon and many other cloud services have already patched the vulnerability. It would also explain why some services have recently required customers to restart their guest operating systems. Members of Linode, for instance, received e-mails two weeks ago notifying them of Xen security advisories that would require a reboot no later than October 29, when the updates would go live. An Amazon advisory, meanwhile, said the update required no reboot.

“Really shocking”

The Qubes OS analysis criticized the development process that allowed a bug of such high severity to persist for such a long time. It also questioned whether it was time for Xen developers to redesign the hypervisor to do away with paravirtualized virtual machines. Qubes researchers wrote:

Admittedly this is subtle bug, because there is no buggy code that could be spotted immediately. The bug emerges only if one looks at a bigger picture of logic flows (compare also QSB #09 for a somehow similar situation).

On the other hand, it is really shocking that such a bug has been lurking in the core of the hypervisor for so many years. In our opinion the Xen project should rethink their coding guidelines and try to come up with practices and perhaps additional mechanisms that would

not let similar flaws to plague the hypervisor ever again (assert-like mechanisms perhaps?). Otherwise the whole project makes no sense, at least to those who would like to use Xen for security-sensitive work.

The vulnerability affects Xen version 3.4 and later, but only on x86 systems. ARM systems are not susceptible. Only paravirtualization guests can exploit the bug, and it doesn't matter if the guests are running 32-bit or 64-bit instances. Now that the vulnerability has gone public, it's a fair bet that unpatched systems will be exploited. Anyone relying on Xen who has not yet updated should install the patch as soon as possible.

Sursa: http://arstechnica.com/security/2015/10/xen-patches-7-year-old-bug-that-shattered-hypervisor-security/