A new whitepaper from Symantec - written by Peter Ferrie, Senior Principal Researcher - talks about security issues with today's virtualization solutions. This 13 page document discusses the following:
As virtual machine emulators have become commonplace in the analysis of malicious code, malicious code has started to fight back. This paper will explain known attacks against the most widely used virtual machine emulators (VMware and VirtualPC). It will also demonstrate newly discovered attacks on other virtual machine emulators (Bochs, Hydra, QEMU, and Xen), and describe how to defend against them.
Introduction:
Virtual machine emulators have many uses. For anti-malware researchers, the most common use is to place unknown code inside a virtual environment, and watch how it behaves. Once the analysis has been completed, the
environment can be destroyed, essentially without risk to the real environment that hosts it. This provides a safe way to see if a sample might be malicious.
This brings us to the simplest attack that malicious code can perform on a virtual machine emulator: to detect it. As more security researchers come to rely on virtual machine emulators, malicious code samples have appeared that are intentionally sensitive to the presence of virtual machine emulators. Those samples alter their behavior (including refusing to run) if a virtual machine emulator is detected. This makes analysis more complicated, and possibly highly misleading. Some descriptions and samples of how virtual machine emulators are detected are presented in this paper.
A harsher attack that malicious code can perform against a virtual machine emulator is the denial-of-service, specifically by causing the virtual machine emulator to exit. Some descriptions and samples of how that is done are presented in this paper.
Finally, the most interesting attack that malicious code can perform against a virtual machine emulator is to escape from its protected environment. No samples of that are presented in this paper.
It is important to note here that most virtual machine emulators are not designed to be completely transparent. They are simply meant to be "good enough" so that typical software can be fooled to run inside it. Their use in the
analysis of malicious code was never a requirement. This situation is changing, though, with the creation of new virtual machine emulators, such as Hydra. However, even with full knowledge of what has been used to detect existing virtual machine emulators, it is clearly difficult to write a virtual machine emulator that cannot be detected. Some descriptions and samples of how to detect Hydra are included in this paper.
The interest in detecting virtual machine emulators is also not limited to the authors of malicious code. If malicious code is released that makes use of its own virtual machine emulator, then it will become necessary for anti-malware researchers to find ways to detect the virtual machine emulator, too.
Sample detection code is presented in the appendix. For simplicity and to prohibit trivial copying, only 16-bit real mode assembler code for .COM-format files is supplied.
Virtual machine emulators come in two forms: "hardwarebound" (also known as "para-virtualization") and "pure software" (via CPU emulation). The "hardware-bound" category can be split into two subcategories: "hardwareassisted" and "reduced privilege guest" (or "ring 1 guest").
Both forms of the "hardware-bound" virtual machine emulators rely on the real underlying CPU to execute nonsensitive instructions at native speed. They have better performance for this reason, when compared with "pure
software" implementations. However, since they execute instructions on a real CPU, they must make some changes to the environment, in order to share the hardware resources between the guest operating system and the host operating system. Some of these changes are visible to applications within the guest operating system, if the applications know what those changes look like.
Read the entire paper, here.