Virtual Machines for Security

k-hell writes "Researchers from the University of Michigan are using virtual machines to 'to provide security in an operating-system-independent manner.' They have designed and implemented a replay service for virtual machines called ReVirt, which 'logs enough information to replay a long-term execution of a virtual machine instruction-by-instruction.' A system called BackTracker 'automatically identifies potential sequences of steps that occurred in an intrusion,' and they provide a nice example of BackTracker's output for an attack against a machine that they set up as a honeypot, where an attacker gained access through httpd. Here's the source code."

Comments

Not quiet

[botzi]

Actually your question does make some sense, but isn't completely right.
The JVM itself is not as secure as its architects would like it to be. When you program for the JVM, you're supposed to use a Java compiler, and actually a lot of the safeguard features come from the compilation process and the specification of the Java language.
However, in the doc it is stated that the JVM may interpret *every* valid .class file, and although the .class files has a lot of restrictions, it's still possible to write dangerous code.
Anyway, this VM guys have an interesting idea...

PS: I'm currently working on a JVM assembler(nothing to take from Jasmin, but the inspiration), that'll have no practical use, of course, but I still hope that there're some people that'll find it interesting......

Re:Not quiet

[AKAImBatman]

Another assembler for Java? How quaint. Seriously, the JVM is one of the most secure VMs in existance. It is also rather pragmatic. The default is to leave the door open for programs, but allow them to install security managers at any level in order to lock down code in the VM. Don't want code to use reflection? Bam! Security manager's got it locked down. Both Applets and Java Web Start include security managers by default to prevent malicious code. The *only* examples of true VM exploits are via Microsoft's VM. That thing has holes so large you can drive the U.S.S. Enterprise (CV-65, not CV-6) through them. Of course, that isn't actually Sun's fault, that's because Microsoft *likes* to punch security holes in the name of "ease of use". Don't even get me started on ActiveX.

Re:Not quiet

[eckes]

JavaVMs had exploits in the past, so I do not see ground for your claim that they are the most safe VMs. I know simulations of turing engines which are far more secure and less exploitable.

Remember Brown Orifice in netscape VMs?

Some more: http://www.securitytracker.com/archives/target/130 1.html

Re:Operating System Independence?

[LostCluster]

The UMLinux OS is there to be a thin real OS that runs the simulator which runs the guest OS and their goal is for the simulator to be a good enough emulation of real hardware so that any operating system can be installed as that guest OS....

Re:Operating System Independence?

[dki]

Not to nitpick, but they don't use User Mode Linux. They use UMLinux, which differs from the former in that in UMLinux the VM is contained in a single host process, whereas in User Mode Linux each guest app has its own process. The confusion comes in because UMLinux is considered a type of User Mode Linux, hence the name. Confusing enough?

Re:virtual pc on a mac

[DarkBlackFox]

I think that's exactly what they are trying to do, but because of the outer layer (in your case, the mac, in their case, linux), they have some mechanism to examine the network traffic and produce a detailed log of the hack. While it wouldn't directly protect you from the hack, it would provide valuable information as to what exactly was hacked, such that it can be patched to prevent that method from affecting other systems. More or less a tattle-tail for network security than a buffed up security guard.

I did something sort of like this once...

[Anonvmous Coward]

Not entirely on topic, but I don't have anything really to add to this subject. Back in my Kazaa days, I was a little concerned about viruses etc getting me. So I set up a VM in VM-Ware and ran Kazaa on that. It did lag my computer considerably, but if Kazaa were to infect my machine, it would (in theory) be contained. Sadly, I didn't get infect with anything so I couldn't tell you how effective that was. I was kinda hoping it would be infected so I could analyze what happened. The funny result of this setup was that if you scanned my hard drive, you couldn't find any of the stuff I downloaded unless you fired up VM-Ware.

The problem with virtual machines.

[cyt0plas]

Virtual machines are inherantly insecure. Because the internal virtual address space is accessable externally, it can be modified, tampered with, or viewed at will. Regardless of the cryptography, the process can be slowed down, stepped through, and have any protections disabled, or even reversed.

While it's a nice thought, it doesn't add too much in terms of security, a virtual machine compromised still allows access to the rest of the virtual machine. Raw harware access is not needed to wreak havoc.

Re:The problem with virtual machines.

[multi io]

Because the internal virtual address space is accessable externally, it can be modified, tampered with, or viewed at will.

You can modify, view, and tamper with native assembly code as well. I don't know what you mean by "accessable externally". The virtual address space of a server application running on a virtual machine most definitively isn't accessible automatically to the clients.

I don't see how additional possibilities in the hands of *the server's administrator* could weaken security.

The additional software layer in virtual machines enables you to easily impose all kinds of restrictions like very fine-grained access control etc. on the running code.

Imagine you have written a server application running as root. The application reads "untrusted" configuration files written by less privileged users. You want to make those configuration files as powerful and flexible as possible. So you might want to define a turing-complete configuration language for use in those files. The "easiest" solution would be to allow arbitrary shared libraries containing assembly code to be used as configuration files. Of course, this solution throws all security measures out of the window. So, in order to still retain a decent level of security in this situation, you have to settle on a software layer of some sort in your server, which reads and executes the the configuration files written by the users on their behalf, applying all necessary security checks on the fly. Voila - you have written a virtual machine.

(in fact, scripting languages like Perl and Ruby have special "tainted modes" to facilitate such uses)

Re:Hmm..

[martyros]

Putting security services in VMs has been done for years.

The particular service we're providing, ReVirt, is new to Virtual Machines (as far as we know). We don't log normal "security" information, like login attemps, etc. We log just enough information to be able to roll the virtual machine back to a previous state, and make it execute exactly the same way.

One of the (many) problems with security logs is that you frequently don't know everything that you really need to log until after the fact. With our system, you can go back and find out anything you want to know, because you have a live VM doing exactly what it did during the attack.

BTW, the technique we're using for ReVirt was described back in the late 80's, and implemented in the mid 90's for debugging purposes; we're the first ones, as far as we know, to put it in a (somewhat) general-purpose virtual machine, like UMLinux.