Guest-to-Host VM Escape Vulnerability

[check_status]

Look out Linode!!!

The U.S. Computer Emergency Readiness Team (CERT) has issued an alert for a dangerous guest-to-host virtual machine escape vulnerability affecting virtualization software from multiple vendors.

The vulnerability, which affects 64-bit operating systems and virtualization software running on Intel CPU hardware, exposes users to local privilege escalation attack or a guest-to-host virtual machine escape.

From the advisory:

A ring3 attacker may be able to specifically craft a stack frame to be executed by ring0 (kernel) after a general protection exception (#GP). The fault will be handled before the stack switch, which means the exception handler will be run at ring0 with an attacker’s chosen RSP causing a privilege escalation.

Affected vendors include Intel Corp., FreeBSD, Microsoft, NetBSD, Oracle, RedHat, SUSE Linux and Xen.

http://www.zdnet.com/blog/security/us-cert-warns-of-guest-to-host-vm-escape-vulnerability/12471

[1715200536]

1715200536

[1715200536]

1715200536

[grue]

yay for amd!

also, linode is not affected.

The Xen security team recently made public three security advisories regarding the Xen Hypervisor. Linode customers are not affected by the issues outlined in the advisories due to proactive maintenance performed by Linode over the past few weeks.

    XSA-7 – 64-bit PV guest privilege escalation vulnerability
    XSA-8 – guest denial of service on syscall/sysenter exception generation
    XSA-9 – PV guest host Denial of Service (AMD erratum #121)

The Xen blog has a really nice writeup on the issue.

Having to deal with advisories like these is just part of our industry. One of our challenges in just about everything is our scale. Suddenly a required update means wrangling thousands of machines and causing a huge disruption for our customers.

These specific advisories had the potential to affect our entire fleet, however we were able to devise a clever plan which put the number of affected Linodes into the minority. The plan combined: 1) A rush to deploy additional capacity reserves across all facilities 2) a reboot/upgrade of only the hosts that would recover the most capacity, and 3) an automated migration queue of only the remaining affected Linodes onto the good capacity. As a result, the majority of customers were unaffected by this maintenance.

Almost everyone in the entire company had a hand in this effort – kudos to the entire team for making this as seamless and streamlined as possible.

-Chris