Slashdot Mirror
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."
Isn't this called Java?
Never trust a man in a blue trench coat, Never drive a car when you're dead
Seems like this is a solution for recording the every move a computer makes, so when it is hacked you can play back moment-by-moment what exactly happened.
The only problem... by the time you realize it's time to look at the playback, the "virtual machine" is already 0wned. Useful for honeypots, but this isn't going to secure a production system... it's not a line of defense, it's a just a very detailed logging of what happened.
You can build another virtual machine that runs on a different platform (Windows) and have the high-level operations of the virtual machine stay the same. So, therefore, the interface that the (potentially attacking) user sees is independent of both the OS and its hardware.
Simply because they built it on linux first doesn't mean they won't make a VM for another platform, much like Java does. I have a feeling that they're trying to get it right on Linux before they build another VM.
--My other sig is a ferrari.
There is some validity to your point. However you underime this project and all honey pots/nets when you say they are not a line of defense. They provide very valuable information that then goes into that line. Not to mention if you have a Decoy (one configured exaclty as the real and thought to be secure, except it has no valuable data) honey machine that gets hacked before your production one is. You now know how to prevent the intrider from attacking the real machine.
"We believe that even an overhead of 58% is not prohibitive for sites that value security."
I really wonder if 58% overhead is worth it. It seems to me this is still a little massive for this kind of thing. ReVirt and VMWare both do a good job of keeping the overhead down but I think there will have to be innovations in areas other than virtual machines for this kind of thing.
___ Shout Central - Crushes your nuts!
The source is UM-linux specific, but the techniques they are using (i.e., create a narrow secure interface into the kernel, and watch the processor) are applicable to any OS. In particular, if someone could attach this to VMWare, that'd be pretty damn cool!
- Blenderfish
Ah, but you seem to miss the advantages of a VM. If you can see exactly how you were compramised, you can then repeat the attack after going back and securing the vulnerability. Thus enabling you to have a fast and easy way to determine vulnerabilities in your code execution. Another great advantage of a virtual machine is that you can very simply and easily revert to a "clean" copy of your machine, before the attack, and have an effective downtime of 3 seconds (the time it takes to stop the VM, select the clean copy, and boot the VM again). So in a production enviornment, you have an added layer of redundancy.
Take a database as an example. You have your tape backups, your transaction logs, etc. etc, but what if your registry (I'm talking people running MSSQL, but for other platform, think of what happens when someone crafts an improper looping arguement into an SQL write query, hosing your data structures) gets completely foobared. What do you do? Do you a) pull out the tape and have a whole bunch of downtime? Or do you just boot an older VM and apply the transaction logs to the database just before the point where everything went stupid? I think the VM would be a much faster recovery (if you consider that you are running a database that stores several hundred gigs of data, this makes more and more sense). Anyway. It's just a question of whether you feel you can implement and manage it.
Don't Ask Questions. I don't know the answers and even if I did I wouldn't tell you.
Right, you'd still be compromised.
What this tool does is add a very detailed logging component to the VM software, so that when you're compromised, you have a much easier time figuring out what hit you.
The problem with most current system logging tools is that they run on the system that they are logging, which means if the attacker gains root access they could kill the logging tool's process first, or tamper with the logs to erase their activities.
By making the logging tool one in the same with the VM software, if the hacker kills the logging tool the machien they were trying to hack vaporizes. And, if they are able to obtain root on the virtual machine, they'd still need to obtain root on the host OS (which is intentionally a lightwieght OS to decrease the likelyhood of that ever happening) to clean their tracks.
Once Solaris 10 comes out, its zomes might be able to provide a better infrastructure for what the original article was talking about, but the last presentation i saw on zones was unsure about the monitoring capabilities to be built in.
The performance boost this article mentions sounds nice, but i don't understand what else they accomplished that a tcpdump on the host machine couldn't do.
links:
honeyd
user mode linux
Bait and switch honeypots
Solaris 10 zones
-f
www.blackant.net
the more things change, the more they stay the same. virtual machines were used extensively in the '60s and '70s at time-sharing service (both service bureaus and various kinds of institutional in-house) operations .... in part because of the paradigm's isolation capability
in the early '70s had an operation that had the most sensitive of a large corporation financial & business operations being run on the same online computer that also had significant number of BU and MIT students.
Sure, it's possible to generate a class file with invalid, 'dangerous' byte code by using a Java assembler, but it won't pass the mandatory verification stage of the virtual machine.
Unless you turn the verifier off.
Suck figs.
> 2. Yes, native methods have nothing to do with JVM
> security related to invalid bytecode.
Just to back up what Toby's saying here, native access is controlled by the secutity manager attached to the classloader. If the classloader doesn't allow it, there can be no native code. An example of this is Applets which implicitly prevent DLLs from being loaded.
> 4. I honestly don't remember how I came across
> BCEL - I knew of it, though, back when it was
> called JavaClass.
IIRC, it was one of the few successful projects produced by the Java Operating System project.
Javascript + Nintendo DSi = DSiCade
The clever bit is keeping the code that needs verification relatively small, which is why I believe Microsoft will fail with Palladium. Knowing them, the trusted base will be too large to thoroughly check.
See my journal, I write things there