OVERVIEW

In this the third technical article from Orthus that summarises much of the platform focused industry research that has taken place as regards issues associated with the security of virtualisation platforms, we outline the second  of three categories of virtualised platform specific vulnerabilities, namely that of virtual machine environment protection bypasses.

CONCERNS OVER ISOLATIONISM…

The detection of virtual machine environments (see previous article) is merely one weapon in the attackers’ armoury, and there exists a number of mechanisms for bypassing the supposed isolation between guest and host operating systems and processes. In the same presentation in which Ed Skoudis and Tom Liston discussed potential remote virtual machine environment detection, a number of utilities were highlighted that can bypass the isolation supposedly inherent in platform virtualisation technologies, particularly VMware. The utilities discussed were operable in VMware Workstation 4 and 5 (and may well be applicable to VMware Workstation 6). VMware Worsktation has an inbuilt communications channel that allows host and guest operating system instances to communicate (commonly referred to as a backdoor). By exploiting this functionality as well as DLL injection it was possible to generate a suite of tools designed to circumvent the isolation of partitions and platforms. As highlighted these tools have not been publicly disclosed as of the time of writing (this may be in no small part due to the fact that much of the research conducted by Ed Skoudis and Tom Liston is formerly sponsored by the United States Department of Homeland Security), however publicly released tools are available for both the attacker and legitimate researchers to utilise. Most notable amongst these is the VM Back suite of tools developed by Ken Kato[i] and other contributors. The VM Back suite of utilities exploits the Backdoor / IO functionality that forms part of many VMware binary distributions. This backdoor is used by the binary distribution to configure deployments of VMware during application runtime (interestingly, the official VMware Tools utilise this backdoor).  At the time of writing there are twenty known commands that can be issued via this backdoor functionality and impact upon VMware products for both Windows and Linux hosts, namely:

Command Number

Description

01h

Get Processor Speed

02h

Invoke APM function on virtual machine

04h

Get mouse pointer position

05h

Set mouse pointer position

06h

Get text length from clipboard

07h

Get text from clipboard

08h

Set text length to clipboard

09h

Set text to clipboard

0Ah

Get VMware version information

0Bh

Get device information

0Ch

Connect / Disconnect a device

0Dh

Get GUI options setting

0Eh

Set GUI options setting

0Fh

Get Host screen size

11h

Get virtual hardware version

12h

Popup “OS Not Found” dialog

13h

Get BIOS UUID

14h

Get Memory size

17h

Get Host system time

1Eh

Enhanced RPC

TOOLING & EXPOLITATION

By exploiting the functionality of Backdoor/IO operations, Ken Kato (and others) have been able to create a number of utilities that can be used to bypass the supposed isolation between guest and host operating systems operating in a virtual machine environment. Indeed in February 2008, security research group Core Labs, utilised one such application VMFTP to help exploit a vulnerability within VMware shared folders functionality (which was enabled by default) that allowed for users of a guest OS to obtain read and write access to the host OS.

NEXT TIME…

In our next article we will discuss final category of virtualised platform specific vulnerability, namely that of virtual machine environment destruction.

OVERVIEW

In this the second of six technical articles from Orthus we summarise much of the platform focused industry research that has taken place on issues associated with the security of virtualisation platforms.  We also outline the first of three categories of virtualised platform specific vulnerabilities associated with virtual machine environment security anomaly detection.

SUFFERING FROM POOR MEMORY…

It is possible for attackers to detect virtual machine instances in a number of ways, but one of the most obvious attack vectors is to check for running processes in memory, for example reviewing Registry entries (if attackers are within a Microsoft Windows based OS), as well as reviewing the OS file system, for known files associated with particular virtualisation platform vendors. In such an approach an attacker is limited to the discovery of visible processes and assets, and many vendors may actively seek to obfuscate these values to help resist detection attempts.

Attackers can also seek to discover specific memory artefacts and detect anomalous behaviours introduced into memory by the virtualisation process. It may be possible for an attacker to search system memory for references to known virtual machine variants. This is not a trivial task to accomplish however, can be resource and performance intensive, and in addition attackers will need to compare the memory of both Host and Guest instances. Another potentially more elegant solution available to attackers seeking to detect virtual machines is to examine memory for pointers to critical Operating System tables.

One known memory differential is the location of the Interrupt Table Descriptor (IDT), which is responsible for determining where various OS system interrupt handlers are located in memory (and is often exploited by rootkit technologies). In many implementations of virtual machines, the IDT is commonly situated in a lower memory location than on a conventional OS. A number of tools exist to assist an attacker seeking to exploit this issue in relation to the discoverer of virtual machine environments, most notably, Kad’s CheckIDT which was detailed in Phrack 59 in 2002[1].

It is not necessary however for attackers to physically examine memory structures to detect virtual machine environments, and a number of widely available applications are available to assist in this process.  A number of researchers have taken advantage of the IDT checking concept, most notably Joanna Rutkowska, and Tobias Klein to detect virtual machine instances.

In 2004, Rutkowksa debuted the Red Pill[2], which utilises a single machine language instruction, SIDT (Store Interrupt Descriptor Table) which checks the IDT entries situated in the Interrupt Table Descriptor Register (IDTR).

In VMware guest machine instances, the IDT entry is typically situated at memory location 0xffXXXXXX, for Virtual PC instances, it is typically situated at 0xe8XXXXXX. The scoopy[3] utility issued by Tobias Klein in 2003 also utilises the SIDT instruction to check memory values and discover virtual machine environment instances, but is specifically directed towards the discovery of VMware instances.

In addition to utilising the SIDT instruction, Scoopy also checks for SGDT and SLDT. As with the IDT (measured using the SIDT instruction) other tables exist in memory whose location is shifted by the introduction of a virtual machine environment, namely the Global Descriptor Table, and the Local Descriptor Table. What Scoopy seeks to accomplish is a check of the results set created by utilising a SIDT instruction, by way of comparing the memory location of GDT and LDT with known virtual environment variables.  In addition to these tools, attackers have a variety of other resources that may be utilised to detect a virtual machine environment, most notably, VMDetect from Danny Quist, and the VME specific hardware checking utility, Doo from Tobias Klein.

CURRENT BARRIERS TO EXPLOITATION

In relation to current methods of detecting virtual machine environments, attackers and researchers alike are bound by one common issue namely that most available mechanisms require them to be authenticated, or else have physical access to the target machine.

A number of research projects are currently underway to overcome this limitation. In July 2007, Ed Skoudis and Tom Liston presented a number of findings concerning virtualisation security at the SANSFire conference[4]. As well as discussing a number of as yet to be released utilities, a method for the remote detection of virtual machine environments was discussed.

In their current research, Skoudis and Liston are seeking to define anomalies that exist in the timing of ICMP and TCP packets.  In addition, they have turned their attentions to timestamps and pattern recognition within packet headers. As virtual machine environments can often possess timing disparities (particularly with regards virtualised resources) this may well prove a fertile area of research, and remote detection utilities may well be available to attackers and researchers alike shortly.

NEXT TIME…

In our next article we will discuss second of three categories of virtualised platform specific vulnerabilities, namely that of virtual machine environment protection bypasses.

A number of security research projects have been undertaken into gaining an insight into the security vulnerabilities associated with platform specific virtualisation technologies and / or the hosting of one operating system environment on another. There has arguably been less focused research into resource specific virtualisation issues, and the allocation of specific system resources (e.g. storage and memory areas, name spaces etc.). The race for the discovery of undisclosed security vulnerabilities and software bugs with popular platform virtualisation environments (most notably those produced by VMWare Inc.) has led to a situation whereby physical virtualised resources have been largely stricken from the collective consideration of the security research community.

In this series of six independent technical articles from Orthus we will present an overview of much of the platform focused research that has already been undertaken, what differentiates this from resource specific issues and considerations.  As increased numbers of enterprises move towards adoption of virtualised resource technologies, and infrastructure associated with critical national security and industrial control systems also adopt these technologies, the risk exposures increase, and it is of vital significance that security research efforts are focused upon these technologies.

Many modern computing environments are sufficiently powerful to support the use of platform virtualisation technologies to facilitate the deployment of virtual machine instances which utilise a separate Operating System. Depending upon deployment requirements (and indeed the hardware and software vendors selected to facilitate such deployments) a platform specific virtualised environment may consist of some (or all) of the following components: virtual machine instances, guest and host Operating Systems, virtual machine monitors (VMMs), the virtual machine environment (VME) itself, in addition to hardware.

A variety of protection mechanisms may also be employed which range from hypervisors to appliances.  As discussed in the abstract, a considerable amount of focused security research has been undertaken concerning platform virtualisation technologies however as of the time of writing, little attention has been directed towards virtualised resource platforms. This is not to imply that these technologies are not receiving the attentions of researcher owing to the rarity of their deployment.

The use of virtualised resources is a growing trend, and they can be found operating in many computing environments, including the financial, governmental, health care, and military sectors.  Additionally, popular vendors of SCADA based systems and software, PROCSYS and Wonderware allow for their technologies to be scaled and deployed within virtual resources.

A number of specific business drivers may be utilised when making the decision to deploy virtualised resources, however there is a common misconception that the deployment of such assets will lead to increased productivity and reduced costs. Regardless of deployment drivers, the use of virtualised resources and a move away from the notion of network based computing models (e.g. the computer is the network, and the network is at its best, when distributed) is a growing trend that has arguably received little attention from security researchers to date.  

Most technical and business staff in enterprise environments understand the difficulties inherent in securing distributed environments, however the ugly kernel remains that in relation to virtualised resources the scope and impacts of security threats are rarely fully understand and addressed.

Prior to discussing the security threats and vulnerabilities that face virtualised technologies (be they platform or resource specific) the elements that constitute a secure environment should first be considered. Virtualised technologies arguably have a number of distinct elements that need to exist for them to be classified as secure. A number of researchers have focused their attentions towards defining these, most notably, Reiner Sailer et al of IBM, in the paper ‘sHype: Secure Hypervisor Approach to Trusted Virtualized Systems’[i].

A number of constituent security goals are defined by Sailer at al, as forming secure virtualised environments, namely:

These elements are an excellent starting point however they disregard a number of key requirements from a security perspective. Although Sailer et al recognise the need for isolation and separation between virtual machine partitions this should arguably also be applied to processes and users.  From a security perspective it is also imperative to ensure that not only is controlled sharing enforced for partitions but also those resources they may access (such as memory).

Additionally, although the necessity of auditing is recognised, the value of virtualisation lies in its inherent flexibility and, and this too should be considered especially with regards secure and scaleable deployments. Regardless of the theory of what constitutes a secure virtual machine environment, the reality remains that at present many environments are anything but.

A number of security research groups and individuals are conducting research into bypassing the security restrictions in place within virtual machine environments, and as highlighted in the abstract for this paper this has proved a fertile area. A number of security vulnerabilities have been highlighted in products issued by VMware Inc over recent years, and this is a trend that doubtless will continue. The VMware product suite (i.e. VMware Server, VMware Player, VMware Workstation etc.) or elements thereof, is widely deployed in many environments, and importantly comparatively inexpensive to obtain. Regardless of the individual vendor however, virtualised platform specific vulnerabilities can loosely be classed into three major groupings, namely:

NEXT TIME…

In our next and second article of six we will explore how the first of these j

[i] sHype: Secure Hypervisor Approach to Trusted Virtualized Systems; Reiner Sailer, Enriquillo Valdez, Trent Jaeger, Roland Perez, Leendert van Doorn, John Linwood Griffin, Stefan Berger. IBM Research Division. February 2005.

 http://domino.watson.ibm.com/library/cyberdig.nsf/papers/265C8E3A6F95CA8D85256FA1005CBF0F/$File/rc23511.pdf