Security issue found in 64-bit virtualization software running on Intel CPUs

Virtualization software has long been the subject of criticism because of real or perceived security flaws. Over the years there have been numerous virtualization exploits identified and resolved, but last week there was a significant uptick in the conversations about security issues around hypervisors and operating systems, because this time it didn’t just affect a single vendor. Instead, the issue seems to affect a number of different 64-bit hypervisors and operating systems based on the type of processor they are operating.

The new security warning came down from the U.S. Computer Emergency Readiness Team (US-CERT) for some virtualized systems running on Intel processors. According to security researchers, some 64-bit operating systems and virtualization software that are operating on Intel CPUs can be vulnerable to a local privilege escalation attack. The vulnerability may be exploited for local privilege escalation or a guest-to-host virtual machine escape.

[ Also on InfoWorld: Veeam has released a free virtualization backup tool for VMware vSphere and Microsoft Hyper-V. | Read about what VMware’s CTO said about the future of vSphere while at a VMUG meeting in Italy. | Keep up on virtualization by signing up for InfoWorld’s Virtualization newsletter. ]

According to US-CERT KB VU#649219, “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.”

What this means is that someone may be able to cause a system exception in virtualized code and escape from the guest OS into the host environment with elevated privileges. Intel and AMD both package security features that are supposed to isolate the guest operating systems from each other and from the host to prevent this type of attack. Unfortunately, it looks as though there may be a flaw in Intel’s implementation of this protection schema, allowing an attacker to break free and jump into the protected host OS.

In a recent blog post written by Xen.org, the official Xen Project community blog, the vulnerability was explained as follows: “It has to do with a subtle difference in the way in which Intel processors implement error handling in their version of AMD’s SYSRET instruction. The SYSRET instruction is part of the x86-64 standard defined by AMD.”

It continued, “If an operating system is written according to AMD’s specification, but run on Intel hardware, the difference in implementation can be exploited by an attacker to write to arbitrary addresses in the operating system’s memory.”

Intel claims that this is a feature and not a bug. The company’s vendor disclosure page states, “This is a software implementation issue. Intel processors are functioning as per specifications and this behavior is correctly documented in the IntelR64 Software Developers Manual, Volume 2B Pages 4-598-599.”

Given that AMD chips aren’t affected and AMD wrote the x86-64 standard that Intel is working off of, it seems dubious of Intel to brush this off as a software implementation issue. The subtle difference alluded to above is that certain hardware functions are performed differently on Intel CPUs than they are on AMD processors. As the Xen.org blog states:

Because Intel’s implementation of SYSRET matches [AMD’s] published spec, they consider their processors to be behaving correctly. However, the SYSRET instruction was defined by AMD as part of the x86-64 architecture, and Intel’s version is obviously intended to be compatible with AMD’s version. If the majority of operating systems (acting independently) managed to “not properly handle uncanonical return addresses on Intel EM64T CPUs,” it’s hard not to conclude that Intel made a mistake when designing their specification.

But beyond the “he said, she said” and finger-pointing blame game, it’s important to note that not all virtualization platforms and operating systems are affected. Unfortunately, the list does include quite a few vendors, so it is important to make sure that your platform isn’t on the list. If it is, be sure to review the vendor information for specific patch and workaround details.

Those listed as being affected include Citrix, FreeBSD Project, Intel, Joyent, Microsoft, NetBSD, Oracle, Red Hat, Suse Linux, and Xen. VMware, Apple, and AMD appear to be unaffected at this time. OpenBSD and Linux operating systems should be unaffected as well since the underlying flaw was reportedly fixed in Linux back in 2006.

If we’re talking about a numbers game when it comes to the hypervisor, there’s at least some good news. Because the majority of companies out there are currently running VMware vSphere, these organizations may be better off and might remain somewhat safe from this security issue. I use the words “somewhat safe” because keep in mind, this vulnerability isn’t just about the hypervisor. It also affects the operating systems themselves. Since the virtual machines running within the VMware environment are using installed operated systems, VMware users aren’t completely out of the woods.

This issue was reiterated in an official statement made by VMware, saying, “The ‘sysret’ instruction is not used in VMware hypervisor code, therefore VMware products are not affected by this issue. Please note that guest operating systems that are installed as virtual machines may be affected and should be patched based on the recommendation of their respective OS vendors.”

While VMware as of late has been hit with ESX source code leak problems and have had to recently patch arbitrary code execution flaws in desktop and server virtualization products, the virtualization giant seems to have dodged at least one bullet this go round.

This article, “Security issue found in 64-bit virtualization software running on Intel CPUs,” was originally published at InfoWorld.com. Follow the latest developments in virtualization and cloud computing at InfoWorld.com.