Virtual Machines for Security 106
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."
Auto hack response (Score:3, Funny)
Hmm.. (Score:3, Interesting)
Re:Hmm.. (Score:2, Funny)
Re:Hmm.. (Score:2)
Re:Hmm.. (Score:5, Interesting)
You asked about setting up a honeypot via VM. A pretty good way to go about things.
This takes it one step further - not only is the honeypot (or even honeynet) in a VM, there's an outer layer that's "watching" the VM(s) and recording the activity. That's really, really good. If you could actually lure some serious attacks to the honeypot then you'd have much more accurate records of what occurred. And, obviously, the observer is supposed to be invisible and undetectable.
Of course, there's the issue of actually getting real attacks in the first place, instead of just a legion of script kiddies. But that's another ball of wax.
Re:Hmm.. (Score:2)
Re:Hmm.. (Score:5, Informative)
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.
Re:Hmm.. (Score:4, Insightful)
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 [umich.edu]
user mode linux [sourceforge.net]
Bait and switch honeypots [sourceforge.net]
Solaris 10 zones [theregister.co.uk]
but.... (Score:5, Interesting)
Re:but.... (Score:2)
Re:but.... (Score:3, Interesting)
Re:but.... (Score:5, Interesting)
That can happen. There was folklore about ways to break IBM's VM/CMS, for example.
Re:That can happen (Score:2, Funny)
Re:but.... (Score:3, Interesting)
There is no way to know if there is a bug in the VM, just as there's no way to know if there's a bug in the operatin gsystem. BUT, the virtual machine montitor, which controls the VM, is a *lot* smaller piece of software than a kernel, with a much simpler interface to provide. Therefore, the hope is that there's less of a chance of an exploitable bug in the VM, than in an operating system.
The obvious comparison... (Score:4, Insightful)
Not quiet (Score:4, Informative)
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
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 (Score:5, Informative)
Re:Not quiet (Score:2, Informative)
Remember Brown Orifice in netscape VMs?
Some more: http://www.securitytracker.com/archives/target/13
Re:Not quiet (Score:5, Interesting)
When the JVM loads a class, it performs a process called verification which ensures that the class file is structurally sound. You can't, for example, push an integer onto the stack, then try to pull it off as an object reference. http://java.sun.com/docs/books/vmspec/2nd-edition
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. As an example, I've written a program which dynamically modifies the bytecode of existing Java classes using BCEL (http://jakarta.apache.org/bcel/index.html). When I made mistakes that generated subtlely invalid bytecode, the classes would fail the VM's verification stage and not load. BCEL includes its own verifier (Justice), to help you ensure your generating valid bytecode during development.
Re:Not quiet (Score:1)
1. The class loader isn't in any case an absolute defence. If I recall correctly there're a number of possible attacks to the calss loader, and new ones are still being discovered..... I can't find the link for the moment, but I'm I've found somewhere a working class spoofing example(Jasmin & Java)... If I do find it. I'll post it here.
2. There're and always will be problems
Re:Not quiet (Score:2, Interesting)
2. Yes, native methods have nothing to do with JVM security related to invalid bytecode.
3. Your point was that somehow crafting bytecode could break the VM security. My point was that that's impossible as the bytecode is verif
Re:Not quiet (Score:3, Insightful)
> 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
Re:Not quiet (Score:2, Insightful)
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 [javaworld.com].
Operating System Independence? (Score:4, Interesting)
Re:Operating System Independence? (Score:5, Insightful)
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.
Re:Operating System Independence? (Score:3, Insightful)
- Blenderfish
Re:Operating System Independence? (Score:3, Informative)
Re:Operating System Independence? (Score:5, Informative)
Re:Operating System Independence? (Score:2, Interesting)
Unfortunately, since that's not likely to happen, Plex86 isn't in good shape, and we didn't want to write our own full-fleged VM, we used UMLinux for a prototype and proof-of-concept that the ReVirt idea could work. Maybe someday VMWare or someone else will pick it up.
BTB, we do use UMLinux (now FAUmachine, I think), but we're looking into porting it to Jeff Dike's User-Mode-Linux soon.
Security cameras don't prevent break-ins very well (Score:5, Insightful)
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.
Re:Security cameras don't prevent break-ins very w (Score:4, Insightful)
Re:Security cameras don't prevent break-ins very w (Score:1)
Re:Security cameras don't prevent break-ins very w (Score:1, Interesting)
Re:Security cameras don't prevent break-ins very w (Score:1)
Also, I bet, if you're already going to the trouble of monitoring every branch your cpu takes, and all your vmkernel system calls, you could go the extra mile and proactively look for suspicious behavior (odd binaries being called, weird IP traffic, overwriting system files, etc.,) and trigger a
Re:Security cameras don't prevent break-ins very w (Score:5, Insightful)
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.
Of course they do (Score:2)
Saying "security cameras don't prevent break-ins very well" is kind of like saying "crash investigations don't prevent accidents". On a single event, you're right. But that's not the point at all.
Re:Security cameras don't prevent break-ins very w (Score:1)
Current techniques require a lot of time, a lot of expertise, a lot of Sherloc
Re:Real News (Score:1, Funny)
Innovation in repeats (Score:1, Interesting)
Neat effect, that.
Re:Innovation in repeats (Score:5, Funny)
Neat effect, that.
The one under "Older Stuff" is actually a honeypost made by a virtual editor. It appears that it successfully fooled you into thinking that the post was a mistake!
Editorial integrity through obfuscation works!
UMLinux (Score:5, Interesting)
Too much overhead (Score:5, Insightful)
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.
Re:Too much overhead (Score:5, Insightful)
If your systems are crucial enough to justify a 58% overhead, you'll know it.
virtual pc on a mac (Score:1)
if i ran virtual pc on my mac and used outlook--i could still be compromised by bugbear... and that's secure?
is this what they're trying to do? or am i on the wrong track?
Re:virtual pc on a mac (Score:5, Interesting)
Re:virtual pc on a mac (Score:5, Insightful)
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.
Re:virtual pc on a mac (Score:4, Informative)
Joel mentioned this the other day (sorta) (Score:4, Interesting)
For added security you might want a... (Score:3, Funny)
Simple solution. (Score:5, Funny)
Mr. Anderson..... (Score:5, Funny)
Neo: "No, but you must only realize the truth..."
Smith: "What truth?"
Neo: "There is no box" *Click*
Re:Mr. Anderson..... (spoiler) (Score:2)
This has been done before... (Score:5, Interesting)
I am reminded of the book "The Cuckoo's Egg" where a system admin at a university tracks down a hacker using teletype machines to monitor the hacker's tracks. Highlights include the reading of reams of teletype hardcopies, and the creation of a honeypot: At one point the author types responses to the hacker, simulating the UNIX box. Wacky!
IBM? (Score:5, Interesting)
Re:IBM? (Score:1)
If you have a reference, I'm sure the covirt group would appreciate it, so we can learn from it / acknowledge prior work more completely. =) -George Dunlap (main ReVirt author)
Re:IBM? (Score:3, Interesting)
Because it
Virtual machines for security (Score:2, Insightful)
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.
I did something sort of like this once... (Score:5, Informative)
Sandboxing (Score:3, Interesting)
I've read of this as a potential antivirus solution, but it sounds like a bit much overhead to me. It's still at least reasonably quick to do pattern scanning. Anyway, off topic... heheh
Useful for debugging also? (Score:2, Interesting)
Sandboxing computer viruses (Score:5, Interesting)
http://www.norman.com
The technology is available as part of a commercial AV product from this vendor.
The problem with virtual machines. (Score:4, Informative)
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. (Score:3, Insightful)
The clever bit is keeping the code that needs verification relatively small, which is why I believe Microsoft will fail with Palladium. Knowing t
Re:The problem with virtual machines. (Score:2)
Re:The problem with virtual machines. (Score:2)
The real key is designing so as small a part as possible of the system must be secured and then hand checking and testing of the critical code. MS isn't really good at either of these.
Re:The problem with virtual machines. (Score:2, Informative)
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 ad
Re:The problem with virtual machines. (Score:2)
article text (Score:2, Funny)
The CoVirt project is investigating how to use virtual machines to provide security in an operating-system-independent manner. Virtual-machine security services can work even if an attacker gains complete control over the guest operating system.
One hard part of designing virtual-machine security services is the semantic gap between the virtual machine and those services. Services in the virtual machine operate below the abstractions provided by the guest operating system and applicat
Just for security? (Score:5, Interesting)
Doing this for software security / anti-hacking (Score:4, Interesting)
Over the last few years, I've been developing a "thin" virtual machine that runs in user-mode. The purpose of this is to allow software to be deployed in a pre-installed state, rather than having to install a bunch of file, make registry changes, etc - just distribute a single EXE that can run directly from CDROM or a download link.
Besides simplfying the installation process and prevent conflicts with other packages (DLL Hell, etc). This method of software distribution also helps protect intellectual property - for example if you use the Macromedia Flash ActiveX component - not only can your application create object instances without having to register it in the system registry - but the macromedia code automatically goes through the virtual machine to read compress/encrypted files included in the archive.
The virtual machine only takes up about 100k on disk and 500-1MB in RAM and runs on top of any version of Windows (no linux, sorry) without drivers or reboots.
Check it out:
http://thinstall.com/help [thinstall.com]
Jonathan Clark
This reminded me of an older Symantec patent (Score:1, Interesting)
In 2000 Symantec proposed that a virus should be evaluated on a virtual machine in order to avoid any damage to the real machine. The patent also describes a virus identification, removal, and state restoration method. Is the proposed method infringing on their patent?
Re:This reminded me of an older Symantec patent (Score:1)