High Quality
Open the downloaded document, and select print from the file menu (PDF reader required).
An Empirical Study into the Security Exposure to Hosts of Hostile Virtualized Environments
Tavis Ormandytaviso@google.com
Google, Inc.
Abstract
As virtual machines become increasingly commonplace asa method of separating hostile or hazardous code from com-modity systems, the potential security exposure from imple-mentation flaws has increased dramatically. This paper investigates the state of popular virtual machine implementa-tions for x86 systems, employing a combination of source codeauditing and blackbox random testing to assess the securityexposure to the hosts of hostile virtualized environments.
Keywords
virtualization, security, software testing
I. I
NTRODUCTION
Secure isolation is one of the fundamental concepts of vir-tualization[15], confining a program to a virtualized environ-ment should guarantee that any action performed inside thevirtual machine cannot interfere with the system that hosts it
1
.Consequently, virtual machines have seen rapid adoption insituations where separation from a hostile or hazardous pro-gram is critical.We can consider a virtualized environment hostile whenuntrusted code is being executed or when untrusted data isbeing processed by services inside the virtual machine
2
. Theuse of virtual machines in malware analysis is well docu-mented[22][11],as are numerous proposals for hosting haz-ardous applications such as honeypots or intrusion detectionsystems[10][23].This paper seeks to test how safe the assumptions of isola-tion and containment are in practice through the analysis of several popular virtual machine implementations for the x86architecture in use today. While this is not a new concept, Fer-rie describes how DOS-based, reduced privilege virtualmachines could be trivially escaped from[22],and Tim Shel-ton describes a flaw in the VMware Workstation NAT servicethat could result in compromising the host machine[24], littleother research has been published in this area.
A. Virtual Machine Threats
Root Secure Monitors
Commodity operating systems can often be compromisedand privileges escalated[18], it is essential that a virtualmachine monitor is ‘root secure’[25],meaning that no level of privilege within the virtualized guest environment permitsinterference with the host system.
Detection
Detecting virtualized environments has been explored indetail by other researchers[22]. Virtual machines employed inmalware analysis or honeypots should endeavour to be unde-tectable or risk changing the behaviour of the emulated code.An emulated malware sample could choose to act benignly,for example, but when executed on a physical machine imme-diately performs some malicious action.Detection will not be considered any further in this paper,although being able to detect a virtual machine, or more spe-cifically, virtual machine implementation, may be a prerequi-site for the more serious attacks investigated in this paper.Without being able to identify which virtual machine imple-mentation is present, an attacker would have difficulty deter-mining how to escape the environment.
Security Threats
The level of threat posed by a hostile virtualized environ-ment that can subvert the normal operation of the virtualmachine will be classified as follows•
Totalcompromise.
The virtual machine monitor is sub-verted to execute arbitrary code on the host with the privi-leges of the vmm process.•
Partialcompromise.
The vmm leaks sensitive informa-tion about the host, or a hostile process interferes with thevmm (e.g., allocating more resources than the administra-tor intended) or contaminating state checkpoints.•
Abnormaltermination.
The virtual machine monitorexits unexpectedly or triggers an infinite loop that preventsa host administrator from interacting with the virtualmachine (for example, suspending, rolling back, etc.), par-ticularly if accessible as an unprivileged user within theguest.
Overview
The next sections describes the testing procedure and toolsused during this investigation. SectionIV.presents the resultsof testing, and in Section X those results are analyzed. Relatedwork in this field known to the author is described in SectionVI.,and my conclusions are presented in SectionV.
II. TESTING
Three of the virtual machine emulators selected for thisinvestigation are open source software, which permitted man-
1. Excepting the allocated use of the hosts resources.2. And thus a compromise of the service by an attackercould result in untrusted code being executed.
ual analysis of the code by inspecting relevant sections forprogramming errors. The remaining emulators are proprietarysoftware products distributed without source code available,thus an automated blackbox testing procedure based on thefuzz technique pioneered by Miller, Fredriksen and So[1]wasdesigned.Two subsystems were identified through comparison of metrics as the most complex components of the virtualmachine emulators
1
. It is reasoned that the most complex codeis most likely to harbour the subtle bugs that can be exposedthrough the random blackbox testing methods employed here.The subsystems that have been identified are:•
Instructions
;
correctly parsing and trapping privileged instructions, and handling illegal, unrecognised and fault-ing opcodes correctly.
•
EmulatedI/ODevices
; handling invalid, illegal, or non-sensical I/O activity.
Multiple tools were selected or written to exercise thiscode in the same manner as[1].Two of the main toolsemployed during this investigation were
crashme
[26],and
iofuzz
.
A. CRASHME
Testing hardware and operating system robustness to mal-formed, illegal or nonsensical instructions has been well docu-mented[27], and tools are already part of common operatingsystem test suites, such as the Linux Test Project
2
. Wood andKatz[16]proposed validating cache controllers with randomdata as early as 1990. For the purposes of this investigation,the simple usermode tool
crashme
by George Carrette wasselected.
crashme
subjects the emulated environment to astress test of fault handling by continually attempting to exe-cute random byte sequences until failure is encountered.
B. IOFUZZ
Implementing an accurate emulation of a hardware devicein software is undoubtedly a challenging task, the correctnessof the implementation is not considered here, only the han-dling of invalid operations. A simple tool was developed mod-eled on fuzz to generate random I/O port activity inside thevirtual machines, and any errors encountered were cataloguedand analysed.To the authors knowledge no similar testing has been per-formed before.
III. PROCEDURE
A. Test platform
All tests were performed on a typical commodity system, aPentium IV 3.2GHz running a Linux 2.6 based operating sys-tem, with the exception of Virtual Machine Y which only sup-ports Microsoft Windows hosts. All virtual machines testedwere the latest versions available at the time of writing andused in their default configuration state where possible. Whensome minimal configuration was required, the options selectedhave been described in the relevant sections.All flaws identified as a result of this investigation werereported to the respective developers. In the case of opensource implementations, patches were provided.Two vendors were unable to respond to the reports pre-sented in time for publication, so the names of their productshave been obscured in the remainder of this paper.
B. Failure Criteria
An implementation is considered to have failed the auto-mated tests performed if emulated code in the virtualized envi-ronment can crash or cause the emulator to abnormally exit.Each crash is reproduced and investigated and its impactdetermined, which is classified as full, partial, or minor com-promise as defined above.Causing the emulator to crash is not necessarily a securityflaw, as a privileged user in the virtualized environment maylegitimately request the emulated machine is halted. However,there are implications for malware analysis, where a hostilesample can perform some harmless operation that has noeffect on a physical machine but immediately halts any emula-tor being used to analyse it. Additionally, this can be consid-ered a simple litmus test as to the quality of the code and theamount of testing performed. An implementation that continu-ally crashes or aborts is unlikely to have seen significant test-ing and is a good candidate for further research. By carefullyanalysing any crashes encountered it may be determined
1.[13]provides some insight into the most error pronecomponents of operating systems.2. Linux Test Projecthttp://ltp.sourceforge.net/ Table 1: Virtual Machine Emulators Tested
NameType
Bochs Open source pure software emulator.VirtualMachine X
a
a. The product name has been obscured as the vendor failedto respond in time for publication.
Proprietary virtual machine popular on the Macintoshplatform.QEMU Open source pure software virtual machine emulator.VirtualMachine Y
b
b. The vendor was unable to investigate the issues presentedin time for publication.
Proprietary virtual machine popular on the MicrosoftWindows platform.VMware Proprietary virtual machine.Xen Open Source paravirtualisation based emulator.
where the weakest code exists and where future research mayprove to be most fruitful.
C. Testing Procedure
Where source code is available, a source code audit is per-formed to identify as many flaws as possible. The auditinvolves a human researcher familiar with programming errorsmanually reading the source code and identifying possiblecodepaths that could result in security problems. Once theaudit has been completed, any flaws identified are reproducedin a live environment and documented.Secondly, the virtual machine is subjected to stress testingusing the
crashme
utility described in Section I. If a fatal erroris encountered, the error is reproduced, analysed then cor-rected if feasible, and the test continues until run without errorfor a period of at least 24 hours.Finally, the machine is subjected to 24 hours of
iofuzz
, anyfailures are reduced to the minimum series of peeks andpokes, and the results are collected and tabulated.
IV. RESULTS
Table 2, “Virtual Machine Failure Impact,” on page 3sum-marises the flaws found, and their impact to the respectiveemulator. Each emulator is discussed in depth in the sectionbelow, where appropriate serious flaws are described in detail.
A. QEMU
QEMU
1
is an open source pure software emulator by Fab-rice Bellard that boasts many advanced features and adynamic translation system that offers better performancethan typically seen in similar emulators.As QEMU is distributed with full source code under theGPL license, a detailed source code audit was possible whichrevealed the presence of multiple exploitable implementationflaws.QEMU 0.8.2 was the latest version available as of thiswriting, which was used in its default configuration. A boota-ble ISO image was prepared with the software required fortesting. According to[28]the proprietary virtual machineemulator win4lin
2
is based on source code licensed from theQEMU project, a copy of this software could not be obtainedfor testing, but could also be affected by the same issuesdescribed here. KVM
3
and VirtualBox
4
also appear to includeor derive code from QEMU.
QEMU Cirrus CLGD-54XX “bitblt
5
” heap overflow
The
cirrus_invalidate_region()
routine usedduring video-to-video copy operations in the Cirrus VGAextension code omits bounds checking in multiple locations,seeTable 4,allowing you to overwrite adjacent buffers byattempting to mark non-existent regions as dirty.While the overflowing data is not controllable, the over-flow allows the LSB of nearby function pointers to be movedto an attacker controlled location.
QEMU NE2000 “mtu
6
” heap overflow
Ethernet frames written directly into the NE2000 deviceregisters do not have their size checked against the mtu beforebeing transferred, seeTable 5, resulting in large values in theEN0_TCNT register overwriting a heap buffer in the slirplibrary with arbitrary attacker controller data from the devicesmemory banks.This flaw is most likely also reachable via the alternativeNIC emulated by QEMU, a PCNet32, however this has notbeen verified, as the fix would be the same.
QEMU NE2000 “receive” integer signedness error
Nonsensical values in specific device registers can result insanity checks being bypassed, an integer overflowing andattacker controlled data overflowing a heap buffer, seeTable 6.
QEMU “net socket” heap overflow.
QEMU does not perform adequate sanity checking on datareceived via the “net socket listen” option, resulting in anexploitable heap overflow. Other guests, or local attackers,who can send traffic to this port could potentially compromisethe QEMU process.
QEMU Miscellaneous
• An infinite loop was discovered in the emulated SB16device.• The DMA code will dereference an uninitialized functionpointer if commands are issued to an unregistered dmachannel.• The unprivileged ‘aam’
7
instruction does not correctlyhandle the undocumented divisor operand, resulting in theqemu process performing an integer divide-by-zero. SeeTable 7.
Table 2: Virtual Machine Failure Impact
NameFullPartialMinor
Bochs • •Virtual Machine X
a
• • •QEMU •
b
b. these flaws may impact other implementations derivedfrom the same code.
• •Virtual Machine Y • •VMware • • •Xen •
c
c. due to lack of appropriate hardware, these findings werenot tested.1. QEMUhttp://fabrice.bellard.free.fr/qemu/ 2. Win4linhttp://www.win4lin.com/ 3. KVMhttp://kvm.qumranet.com/kvmwiki4. VirtualBoxhttp://www.virtualbox.org/ 5.http://www.catb.org/~esr/jargon/html/B/bitblt.html6. Maximum Transmission Unit7. ASCII Adjust for Multiplyhttp://www.x86.org/secrets/opcodes/aam.htm
Add a Comment