CPU Virtualization Extensions: Analysis of Rootkit Issues

Updated: October 20, 2006

A recent demonstration showed how an attacker could take advantage of new processor virtualization extension instructions to install a hypervisor-based rootkit on a system that has hardware-assisted virtualization enabled and no virtualization software installed.

This article shares Microsoft's analysis of the exploitability and seriousness of this threat and recommends configuration options to increase the security of the processor virtualization extension feature.

On This Page

  The Threat: A Hypervisor-Based Rootkit
  Viability and Exploitability of the Threat
  Recommendations for Additional Protection
  Resources

The Threat: A Hypervisor-Based Rootkit

The threat, which was the subject of two presentations at Black Hat 2006, is that someone with administrator privileges on a system that has hardware-assisted virtualization enabled and no virtualization software installed can install a hypervisor-based rootkit. This hypervisor-based rootkit would then be running at a higher privilege level than the operating system itself. The advantage that a hypervisor-based rootkit offers to an attacker is the reduced ability of legitimate kernel-mode code to detect the attacker's hypervisor-mode code.

A system that has a legitimate hypervisor installed is not susceptible to this attack, because as soon as a hypervisor has enabled and used the processor virtualization extensions, a second hypervisor cannot use the extensions.

 Top of page

Viability and Exploitability of the Threat

Contrary to the presentations that describe this type of attack, a rogue hypervisor can be detected using standard rootkit detection mechanisms because the rootkit cannot protect itself from the operating system running on top of it. The claim that the hypervisor-based rootkit could be made "undetectable" would make implementing the rootkit significantly more complex for developers.

Rootkit developers have traditionally shown a strong desire to write code that runs in user mode rather than in kernel mode. Given the additional complexity of properly exploiting the processor virtualization extensions, a successful attack based on the processor virtualization extensions would challenge rootkit developers in ways that a traditional rootkit attack does not.

In addition, this attack vector is somewhat less appealing to developers than a traditional rootkit attack for these reasons:

• A hypervisor-based rootkit cannot be run unless the attacker is already executing kernel-mode code.

• A hypervisor-based rootkit gives an attacker no new access to user data that the attacker would not already have through a traditional kernel-mode rootkit.

• A hypervisor-based rootkit must implement complex mechanisms and utilize secure hardware in order to protect itself from the operating system, and it must also do so in ways that avoid detection.

Although these challenges make it less likely that a rootkit developer would choose to implement a hypervisor-based rootkit, security experts agree that the most effective threat mitigations involve multiple layers of defense. We must therefore consider whether an additional protection mechanism is called for.

 Top of page

Recommendations for Additional Protection

Microsoft believes that it would be very valuable to have a mechanism in the system firmware to enable and disable virtualization extensions, both from the defense-in-depth perspective and to alleviate the concerns of end users. Such a mechanism could take the form of a switch in system firmware that allows a user to enable or disable the virtualization extension feature, thus protecting them from exploits on systems that will not be running a legitimate hypervisor. Given the broad publicity received by the presentations about hypervisor-based rootkit attacks, there is significant value in making this choice available to end users so that their concerns can be alleviated.

It is extremely important that any mechanism for enabling virtualization must not be accessible by unauthorized software, even local privileged software, because an attacker could take advantage of such mechanisms to turn virtualization back on.

Recommended Defaults for Enabling/Disabling Virtualization Extensions. The default setting of this switch requires some thought. Consider the costs of disabling Intel Virtualization Technology/AMD Virtualization through a system firmware setting: If these facilities are disabled by default in system firmware, users would have to explicitly enable that support on each platform instance for legitimate uses, which would represent a significant challenge for enterprises that have thousands of machines and plan on using the hardware extensions. The cost of enabling virtualization hardware support through a manual system firmware setting would result in an increase in deployment time and cost. This cost can be mitigated through the use of various in-band and out-of-band mechanisms for remote management. (More on this in a moment.)

Given the current usage model for the virtualization extensions, we believe that the following default settings are the right ones for system firmware:

• For systems that are destined for a server role (and for only these systems), enable the virtualization extensions. The threat of running malicious code as an administrator on servers is reduced through Windows Server policies and organizational best practices.

• For systems that are destined for a client role, disable (and lock off) the virtualization extensions.

• For systems that might be deployed in either a server or client role (such as high-end workstations), it would be prudent to disable the extensions by default.

As always, the exception to any guideline is when a customer specifically indicates to a manufacturer that they do not want to follow that guideline.

Recommended Language for Describing Enable/Disable Functionality. Additionally, Microsoft believes that using a consistent location and consistent language to describe the enable/disable functionality in firmware setup programs has strong customer value. Given a single phrase in a standard location, operating system Setup can inform customers what action to take if they attempt to install an operating system that requires the virtualization extensions on a system that has the virtualization extensions disabled.

We recommend the following location and language for this functionality:

• Location. The option to enable or disable the virtualization extensions should be expressed in a consistent location across system firmware implementations. We recommend that system firmware implementations place the enable/disable option in the same system firmware Setup section that displays the processor-related fields (such as "Brand String," "Speed," and "System Bus Speed").

• Option Text. We recommend that this option be labeled "Virtualization Technology." When this option is chosen, system firmware would allow the user to enable or disable the virtualization extensions.

• Help Text. We recommend the following help text for this option: "When enabled, a VMM can utilize the additional hardware virtualization capabilities provided by this technology."

Example Scenario for the Enable/Disable User Experience. The following scenario illustrates the user experience for this mechanism: An end user decides to re-provision a machine to take on a role that requires the virtualization extensions. As soon as Setup detects the need the virtualization extensions, it checks whether they are present and whether they are enabled or disabled. If the extensions are enabled, Setup proceeds normally. If the extensions are disabled, Setup displays a dialog box with a message such as the following:

"This installation requires the use of processor virtualization extensions which are currently disabled. Please check system firmware settings and set the Virtualization Technology option to Enabled."

Out-of-Band Enable/Disable Method for Enterprise Client Systems. Microsoft recommends that enterprise client systems be designed to take advantage of an out-of-band enable/disable method that uses Web Services for Management (WS-Management) and out-of-band management hardware. The industry-standard approach and robust security of WS-Management makes it a great tool for controlling this functionality. For a managed environment, this enables a centralized method of configuration for IT departments.

 Top of page

Resources

For questions about CPU virtualization extensions and the recommendations in this paper, send e-mail to MSVirtEx@microsoft.com.

• Windows Virtualization on WHDC

• Web Services for Management
  Windows Remote Management
  Web Services Management Specifications Index Page

 Top of page