Why Injectable Virtual Machines?

My Top 3

In hindsight, rather than write a post about injectable virtual machine specifications, I should have started off with the rationale behind the whole concept and explained what they are to provide context to the readers. In this post, when we speak of virtual machines, we are discussing bytecode virtual machines such as UCSD Pascal’s p-Code machine, or the Java Virtual Machine.

All what an exploit by itself does is open the door to allow attacks in the form of payloads. To do something useful, we need a payload which is a block of code that is injected and then does tasks for us. Sometimes an exploit is tightly coupled with the payload, but it is important to keep the two components distinct organizationally.

There are different classes of payloads akin to the classes of exploitable vulnerabilities. The oldest and most well known is the traditional shellcode. Shellcode is commonly written in machine code and many spawn a command shell to allow the attacker to interact with the operating system. However, they are static, inflexible, and targeted to one execution environment. Machine code needs to be written to the specific architecture of the victim. It can break with patches or other changes to the environment.

Another common payload is the syscall proxy. The attacker sends messages to the proxy to execute system calls. This is more flexible than the traditional shellcode as it allows the attacker to dynamically react to the situation in the target execution environment. A major weakness is that the driving logic is on the attacker side, and this can make it fragile.  Examples of software that uses this technique include CORE IMPACT and Metasploit.

DLL Injection is another payload technique, and its advantage lies leveraging the existing program code and libraries in memory. This allows easy implementation of higher level features. Logic can be placed on the target side, rather than relying on a proxy. However, it is static and it is usually Windows specific.

Another payload type that I find very interesting are exploit compilers. This is typically an intelligent compiler with retargetable backends that are written in a high level language. A notable example of this is Dave Aitel’s CANVAS. It offers a very nice abstraction of lower level code, and is very flexible. However, capabilities are often fixed at compile-time.

This brings us to a payload type that I have been researching: injectable virtual machines, which are bytecode executing environments as a payload. The driving logic is in the bytecode which can be embedded in the payload, or transmitted remotely.

Typical advantages are:

• A well structured bytecode language is more compact than machine code. Once the cost in memory space is paid for the virtual machine, the actual program to be executed can be much smaller than equivalent machine code.
• . A well written virtual machine can abstract enough that bytecode can execute regardless of the underlying architecture. There are some limitations here, such as the difference between syscall proxying on a Unix versus Windows system, but this can be abstracted by yet another layer.
• Because it is a virtual machine, ‘in flight missile repair’ can be conducted, changing the entire characteristic of the program environment. This is especially useful with one-shot exploits.
• Due to the inherent flexibility of virtual machines, this payload type is free to incorporate other techniques such as those mentioned earlier.  A syscall proxy can be implemented, and DLL injection can be used to provide the virtual machine with virtual machines have a long history that dates back past the more common modern ones such as Python or Java. By looking at the early examples that ran in very constrained computing environments, we can transfer what we learn to a similiar context.

  This post should hopefully help provide more context for the readers to understand the raison d’etre behind injectable virtual machines and my research. As always, I welcome feedback and comments.