You are here

Diversified Hypervisors

Description:

TECHNOLOGY AREA(S): Information Systems

The technology within this topic is restricted under the International Traffic in Arms Regulation (ITAR), 22 CFR Parts 120-130, which controls the export and import of defense-related material and services, including export of sensitive technical data, or the Export Administration Regulation (EAR), 15 CFR Parts 730-774, which controls dual use items. Offerors must disclose any proposed use of foreign nationals (FNs), their country(ies) of origin, the type of visa or work permit possessed, and the statement of work (SOW) tasks intended for accomplishment by the FN(s) in accordance with section 5.4.c.(8) of the solicitation and within the AF Component-specific instructions. Offerors are advised foreign nationals proposed to perform on this topic may be restricted due to the technical data under US Export Control Laws. Please direct questions to the AF SBIR/STTR Contracting Officer, Ms. Gail Nyikon, gail.nyikon@us.af.mil.

OBJECTIVE: Develop a new generation of small-footprint hypervisors that provide novel security and forensic mechanisms while resisting reverse-engineering through diversity: every instance of a hypervisor should present a unique attack surface.

DESCRIPTION: In recent years, hypervisors have become the mainstay of cloud computing allowing multiple operating systems to execute concurrently on shared hardware, thereby providing unprecedented improvements in resource utilization. Unfortunately, they have gradually expanded in their capabilities and are now as large and vulnerable as the operating systems that operate on top of them. They were never designed with security and forensics as a primary goal: Much like monolithic operating systems and networks, they evolved with security as an afterthought. Adversaries have consequently developed techniques to detect the presence of popular hypervisors--including VMWare, VirtualPC, Hydra, Xen, and QEMU--and adjust their attacks to handle their presence.

Modern computer network attacks, by operating at the kernel-level, are able to hide their behavior, making forensic investigation of their ingress, operation, and attribution extremely difficult. This in turn makes the development of mitigations and countermeasures time-consuming and error prone. These problems are exacerbated by the lack of support in memory management hardware for the two-way mapping between guest-virtual, virtual-, and physical-memory addresses. This makes it costly and difficult for a hypervisor to explore the internal structure of an application that executes on top of an operating system that sits above the hypervisor. In addition, due to the complexities of bootstrapping, no capability yet exists to resist reverse-engineering through hypervisor diversification, i.e., changing the structure of the hypervisor to remove exploitable addresses that are shared between instances of the hypervisor. Finally, hardware support for hypervisors, similar to VTx/VT-d/VT-c, has begun to emerge only recently in the commodity processors used for embedded systems. Thus the security opportunities afforded by the isolation properties of these technologies, in the presence of extreme resource constraints, has yet to be explored in the embedded realm.

This topic seeks to generate a radical new generation of hypervisor designs that blur or eliminate the distinction with the operating system kernel, utilizes a small-footprint (attack surface) to operate in scarce resources, takes active steps to avoid detection, and/or utilizes diversity to ensure that each instance of a hypervisor is unique. The goal is to leverage hardware-supported guest-virtual isolation to increase security and provide forensics. This requires a fundamental change in the overall structure of operating system internals using the protections afforded by hypervisors as a new method to protect what are normally considered user- and kernel- level components. For example, individual device drivers might be located within designated virtual machines or replicated to provide resilience without kernel intervention. Some guest-virtual machines might be used solely for security and forensics, with associated methods for reserving resources and scheduling these virtual machines separately. A challenge with this approach is that the use of a small-footprint may limit the level of diversity achievable. The ability to execute existing commercial and/or open-source operating systems within such a radical new structure is of particular concern in maintaining DoD’s long-term legacy software investments.

PHASE I: Phase I should involve a collaborative effort to establish a baseline, small-footprint hypervisor. This technology should have the capability to execute an operating system and schedule user processes on a generic commodity processor. A technology development plan that will allow the hypervisor to be diversified and new security technologies integrated should also be developed in Phase I.

PHASE II: The primary goal research in Phase II is to develop a proof-of-concept (TRL 3) diversified hypervisor that is able to operate on both a general purpose (e.g., Intel/AMD) and embedded processor (e.g., ARM). The hypervisor should be able to execute a legacy commercial or open-source operating system and utilize novel security functions in separate guest virtual machines. As part of Phase II, the contractor will also develop a transition partnership with an appropriate DoD partner.

PHASE III DUAL USE APPLICATIONS: The contractor will work to mature the technology for DoD applications (TRL 4). These efforts shall be associated with the defense of embedded systems and/or mobile devices, forensic investigation of network intrusions, cross-domain operations, or other DoD designated activities.

REFERENCES:

    • R. Denz, and S. Taylor, “A Survey on Securing the Virtual Cloud,” Advances, Systems, and Applications, Volume 2, Issue 1 on 6 November 2013. http://www.journalofcloudcomputing.com/content/pdf/2192-113x-2-17.pdf.

 

    • R. Paleari, L. Martingnoni, G.F. Roglia, D. Bruschi, “A fistful of red-pills: how to automatically generate procedures to detect CPU emulators,” Proceedings of the 3rd USENIX conference on Offensive technologies. Http://roberto.greyhats.it/pubs/woot09.pdf.

 

  • Peter Ferrie, “Attacks on Virtual Machine Emulators,” Semantec Advanced Threat Research. Http://www.symantec.com/avcenter/reference/Virtual_Machine_Threats.pdf.

KEYWORDS: diversity, hypervisor, virtual machines, forensics, cyber defense

  • TPOC-1: Matthew Shaver
  • Phone: 315-330-3295
  • Email: matthew.shaver.1@us.af.mil
US Flag An Official Website of the United States Government