VUPEN Security has detailed how to exploit a critical memory corruption vulnerability in Xen hypervisors to break out of virtual machines and execute code.
The attack leverages a now-patched vulnerability discovered by researchers Rafal Wojtczuk of Bromium and Jan Beulich of SUSE Linux and demonstrated earlier this year at the Black Hat security conference. The vulnerability, CVE-2012-0217, exists because the system-call functionality in Xen 4.1.2 and earlier, when running on an Intel processor, improperly uses the sysret path in cases where a certain address is not a canonical address, resulting in local users being able to gain privileges via a “crafted application,” according to an advisory for the issue. In the case of France-based VUPEN, exploitation has been achieved under a 64-bit Linux PV guest running on Citrix XenServer 6.0.0 with Xen version 4.1.1.
In order to trigger the bug, explained VUPEN Security Researcher Jordan Gruskovnjak, one has to map memory close to a non-canonical address and perform a SYSCALL instruction in such a way that the address of the instruction after the SYSCALL instruction will point inside a non-canonical address.
“A local attacker within a guest virtual machine will be able to escape his restricted virtual environment and execute arbitrary code on the host system with permissions of the most privileged domain (‘dom0’), which has direct access to hardware and can manage unprivileged domains (‘domU’),” Gruskovnjak blogged.
The attack assumes the attacker already has root access on the guest virtual machine. With that in hand, the flaw can be used to target the dom0 virtual machine, he noted.
“The strategy here will be to inject a dom0 root process with a bindshell (or reverse shell) payload in order to get a root shell from dom0,” the researcher continued. “The same idea as in remote kernel exploitation will be used: hijack the interrupt 0x80 syscall handler in order to wait for an interruption from dom0 to occur. When an interrupt is triggered from dom0, one is assured that dom0 virtual pages are mapped into memory.”
Xen developers patched the vulnerability in June, and Microsoft, Red Hat, Oracle and other virtualization vendors impacted by the vulnerability followed suit and fixed their respective products as well. Unpatched versions, however, remain vulnerable.
“If you run a virtualization or cloud infrastructure based on Xen, it is thus highly recommended to upgrade to version 4.1.3, which fixes this critical flaw,” blogged Gruskovnjak.
Chaouki Bekrar, CEO and head of research at VUPEN, called vulnerabilities that allow attackers on guest virtual machines to escape and compromise a physical host “the worst and most dangerous security risk that can threaten cloud infrastructures” even if they are relatively uncommon.
“A similar vulnerability affecting VMware products was discovered in 2008, but since then, no such vulnerability was publicly disclosed in virtualization products until the recent Xen one,” Bekrar said. “Exploiting and weaponizing this vulnerability was complex and took us many days of full-time work; however, our final exploit is 100 percent reliable and works on any vulnerable version of Xen and Citrix XenServer.”
“Unfortunately,” he added, “cloud infrastructures are not often updated or patched by administrators to prevent regressions or potential downtime issues, thus our blog aimed to alert cloud owners using Xen to pay attention to this critical vulnerability and fix it as soon as possible since the patch is available for weeks.”
