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: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?

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.

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.