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."

Auto hack response

[draziw]

See an attack and have it try the same one right afterwards on the source ip. Oh wait - that's probably a box they hacked first. d'oh!

Hmm..

[Loki_1929]

Using a Virtual Machine as a honeypot? Why didn't I think of that [slashdot.org]? ;)

Re:Hmm..

[rkz]

SCO thought of it first!

Re:Hmm..

[clarkcox3]

"Simpsons did it!"

Re:Hmm..

[Zathrus]

Heh... but what's being discussed here seems somewhat different.

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..

[Telastyn]

And this has still been done for more than 3 years. (albeit not open source)

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.

Re:Hmm..

[friscolr]

honeyd mentions this sort of use. So does uml. also look into bait and switch honeypots, they mention using virtual machines as the honeypots (at least they did in a presentation i saw).

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....

[HowlinMad]

what if the virtual machine is not secure?

Re:but....

[gmajor]

Can't they be logically proved to be secure? IIRC, the Java VM is theoretically secure; any exploits come from an improper implementation of the VM. I would think it would be a similar case here.... correct?

Re:but....

[Monkey-Man2000]

But then couldn't they prove a real machine is logically secure? Just the implementation may not be. It seems that the implementation is the thing that practically matters in both cases.

Re:but....

[Beryllium Sphere(tm)]

Do you mean, what if the virtual machine has a bug that breaks virtualization and allows an attacker to 0wn the real hardware?

That can happen. There was folklore about ways to break IBM's VM/CMS, for example.

Re:That can happen

[makapuf]

you just need to choose the right pill ...

Re:but....

[martyros]

I'm George Dunlap, the main author on the ReVirt paper. So, IIAP/R (programmer/researcher). =)

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...

[nut]

Isn't this called Java?

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 [wustl.edu]? 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:Not quiet

[rreyelts]

If I had mod points, I would mod this down -1 Misinformed.

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/ html/ConstantPool.doc.html#71817

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

[botzi]

When the JVM loads a class, it performs a process called verification which ensures that the class file is structurally sound.

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

[rreyelts]

1. If you can name a single attack that works against the classloader I'd like to see it. Spoofing is a very old suggested research attack, that was immediately fixed by Sun changing the classloader model so that classes are distinguished by the classloader in which they were loaded.

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

[AKAImBatman]

> 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

Re:Not quiet

[Dan-DAFC]

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?

[kevin_conaway]

They seems make a big point that they want OS independence for their system but they built it using User Mode Linux. How will this be OS independent?

Re:Operating System Independence?

[MyPantsAreOnFire!]

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.

Re:Operating System Independence?

[blenderfish]

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

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:Operating System Independence?

[martyros]

We'd gladly use VMWare, if they'd just GPL the source code. =)

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

[LostCluster]

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.

Re:Security cameras don't prevent break-ins very w

[Chris_Stankowitz]

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.

Re:Security cameras don't prevent break-ins very w

[zogger]

that seems to be it. It's like guard dogs, they give a warning, and also if the bad guys are armed, serve as expendable bullet magnets.

Re:Security cameras don't prevent break-ins very w

[Anonymous Coward]

I would have a virtual machine hosting another virtual virtual machine. If the virtual virtual machine gets owned, the real virtual machine will log on.

Re:Security cameras don't prevent break-ins very w

[blenderfish]

Sure, but there's a lot of peace in mind in knowing nobody has rootkitted your production server, not to mention knowing the exact hole used to obtain access. Even better than sending your logs to a line printer ;)

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

[DAQ42]

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.

Of course they do

[freeweed]

Security cameras may not prevent a *specific* break-in, but information gained from that break-in can help to further secure a location. How did the burglar get in, how did she bypass our security mechanisms, etc. Same goes for honeypots and computer networks.

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

[martyros]

Here's the problem we're trying to address. Say someone breaks into your system. At some time later you notice something strange, follow it up, and find that you've been hacked. You don't know:

• How they broke in (what the exploit was)
• When they broke in
• What they saw (if they d/l'd any sensitive data: credit cards, company information, whatever), or
• What they changed (if they installed any backdoors, trojaned binaries, etc).

Current techniques require a lot of time, a lot of expertise, a lot of Sherloc

Re:Real News

[stratjakt]

We hardly care about stuff like that in the tech industry. Not when there are buzzwords like "wifi" or "honeypot" to be bandied about.

Innovation in repeats

[Anonymous Coward]

That's the first time i've ever seen a story on slashdot simultaneously sitting at the top of both the main story page and the "Older Stuff" box.

Neat effect, that.

Re:Innovation in repeats

[American AC in Paris]

That's the first time i've ever seen a story on slashdot simultaneously sitting at the top of both the main story page and the "Older Stuff" box.

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

[dki]

The virtual machine that ReVirt and its predecessor are built on is called UMLinux. I used it for a school project that analyzed a virtual kernel that had been minimized to achieve improved performance. The current incarnation of UMLinux, now called FAUmachine, is available from the FAUmachine project site [uni-erlangen.de].

Too much overhead

[emo boy]

"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.

Re:Too much overhead

[poot_rootbeer]

I really wonder if 58% overhead is worth it.

If your systems are crucial enough to justify a 58% overhead, you'll know it.

virtual pc on a mac

[double_plus_ungod]

hypothetically...

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

[El Pollo Loco]

What they're trying to do, as far as I understand, is put a shell around what's gonna be comprimised. In your example, it would be virtual pc. If outlook gets comprimised, you can shut down virtual pc and it's all good. But in reality, it's not that easy, because virtual pc isn't designed for that. They've designed a different kind, one that's supposed to be secure, and one that even acts on a differnt layer then the OS. Then they added tracking abilitys, etc.

Re:virtual pc on a mac

[LostCluster]

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.

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.

Joel mentioned this the other day (sorta)

[kworthington]

Joel Spolsky [joelonsoftware.com] had a similar thought on Monday about using VMWare to run webservers in a virtual machine, and to always have similar virtual machines ready, in case the server is hacked etc. (See his June 2, 2003 entry)

For added security you might want a...

[Anonymous Coward]

VM within a VM. You know.. just in case attackers who can bend rules start popping up. Can attackers find out whether or not they're in a VM, or can that happen only after december?

Simple solution.

[gilesjuk]

Give hackers and virus authors virtual computers made of cardboard :)

Mr. Anderson.....

[DarkBlackFox]

Smith: "Surprised to see me hack your box?"

Neo: "No, but you must only realize the truth..."

Smith: "What truth?"

Neo: "There is no box" *Click*

Re:Mr. Anderson..... (spoiler)

[FauxPasIII]

-nod- In fact, the last couple scenes in Reloaded make it seem like The Matrix is based upon just this kind of layered VM model... the world where Zion exists is a simulation running on bare metal (or is it ?), inside of which there is a virtual machine running The Matrix... and everytime The One owns it, they just roll it back and start over.

This has been done before...

[yorkrj]

But not in exactly the same manner:

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?

[BrynM]

Isn't this how IBM has been running Linux on it's S390 mainframes? They can virtualize just about anything because of VM. I remember a disaster recovery simulation at IBM where we restored a copy of our MVS/S390 mainframe within their VM system from our backup tapes. For all intents and purposes, it was our mainframe running inside another OS, and the other OS (VM) logged all of our activity too. We even joked with the IBMers about being able to run VM within VM and MVS within that. This is not new technology, it's just new(ish) to the smaller architectures and a new implementation of the idea.

Re:IBM?

[martyros]

Did you restore a copy at some point (i.e., a checkpoint), or did you log all the input going into it, so that you could replay it, and generate exactly the same execution, race conditions and all?

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?

[BrynM]

We did a checkpoint restore and ran some tests. Our customer support staff spent a few hours on the "system" remotely, but we couldn't justify the cost of continual testing so we planned to capture their activity. We then used the captured data from the tests to repeat the process for further testing. If I remember right (it was a few years ago), the IBM sys-programmers captured the data from the initial restore as well. For them, the second restore process was kicked off with a single command.

Because it

Virtual machines for security

[Anonymous Coward]

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.

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.

Sandboxing

[OrangeGoo]

Is this similar to the concept of sandboxing, in which a process is executed in a VM where it is isolated from the rest of the system while the OS outside watches to make sure nothing bad happens?

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?

[Fastolfe]

This seems like it could be an interesting technique for debugging systems as a whole. Like when my Windows PC hangs randomly for 30 seconds, or does something quirky, it'd be nice if I (or preferably, Microsoft) can understand *why* so that the problem can be corrected. Bit rot sucks.

Sandboxing computer viruses

[Logopop]

Virtual PC environments, complete with IP networking and various common protocols are already being used to catch viral behaviour in software before signature files for a new virus are available. New, unknown viruses will actually spread and send mail from one virtual PC to another inside your PC. There's a paper about it here, which was presented at the Virus Bulletin conference last year:
http://www.norman.com /documents/nvc5_sandbox_technology_2002.pdf
The technology is available as part of a commercial AV product from this vendor.

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.

[hughk]

It really depends on how the VM is configured. If it is correctly setup then there is remarkably little that can be done. If you remember the so-called' "Orange" book standards for computer security, the only implementations for the highest level were virtual machines running under control of security refence monitor which had been extensively checked and tested.

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.

[cyt0plas]

Or, they could do something dumb like allocate a 256 character buffer, then actually let 256 characters be entered in (null termination assumed here). And, since it would be digitally signed (to prevent tampering, of course), changing it would break all the apps. It would be rather appropriate to exploit the palladium "secure" subsystem by using palladium itself to load arbitrary code to the secure area.

Re:The problem with virtual machines.

[hughk]

Exactly, you have to be very careful as to how the software can be protected. Secure hardware makes it easier (non-executable stack and separate I and D spaces) but that isn't always possible (however Linux can ron on an x86 with non-exeutable stack).

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.

[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 ad

Re:The problem with virtual machines.

[cyt0plas]

By accessable, I am referring to the outside (host) environment. It may work as a nice way of controlling external connections; however, it will not work when the entire environment is accessable (in other words, it makes a nice server, but a bad palladium replacement).

article text

[Anonymous Coward]

The CoVirt Project
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?

[timeOday]

If I understand this correctly, this virtual machine provides logging so you can "rewind" to any previous state. That would be invaluable in debugging during software development! Sure it would be good for finding security flaws, but equally good for squashing many other kinds of bugs. Perfect for anybody who ever loaded up a core file and though "how did THAT value get in there?"

Doing this for software security / anti-hacking

[jonathanclark]

A slightly different idea for using VMs to enhance security....

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

[Anonymous Coward]

US Patent 6,067,410
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

[jrum]

Actually there is a difference. The patent is very specific to viruses. It is essentialy about simulating downloaded file operation not about an entire virtual machine. SYMC protects the machine from viruses not hacks. Similar concept, different focus.