there seems to be some mismatched expectations about the protective capabilities of keeping untrusted behaviours/applications/etc confined to a virtual machine... essentially what we're talking about here is a sandbox for untrusted things like web browsing and email... the general idea is that if you can keep the bad stuff from the internet away from your physical system and confidential information then you should be fine... unfortunately it's not that simple...
the idea of the sandbox is to create a barrier separating 2 environments, one environment (the host system) containing important data and one (the sandbox) containing only things you can easily replace... while it is true that malware that gets onto the virtual machine probably won't be able to get to your physical machine (unless you move it to the physical machine yourself or in the unlikely event that it exploits a vulnerability in the virtual machine that allows it to escape), what isn't true is the assumption that you don't have to worry about malware and other security threats anymore because you're protected...
consider, for example, the scenario where adware gets installed on the virtual machine - will the separation stop the ads from reaching your eyeballs? no... and if a worm gets onto your virtual machine, will the barrier that protects your physical machine stop the worm from spewing back to the rest of the internet? no... and if you get a keylogger or password stealer or some other sort of spyware in your virtual machine, does the fact that it's in a sandbox stop you from entering or accessing sensitive information like your bank account credentials or your credit card number? no... does a virtual machine stop you from visiting a phishing site? no...
virtual machine based sandboxes are great for testing malware as well as other sorts of software because in a testing context you can enforce the separation of the virtual environment from any sensitive data and because a virtual machine is easy to restore to a previous state (simply by restoring a copy of the virtual machine made when it was in that state)... operating in a sandbox, on the other hand, makes it quite improbable that you can keep sensitive data separate from the sandbox (because malware and sensitive data travel over many of the same channels) and restoring the VM to a previous state does get rid of the malware but does not undo the damage done by any sensitive data that may have been leaked by the malware (you can't put the genie back in the bottle)...
in an operating environment you can't simply treat malware and related threats as a system recovery problem - flattening and rebuilding (whether done to the physical machine or the VM) may get rid of the malware but it won't undo the malware's consequences... recovering from the consequences of malware is a much more complicated problem which is one of the reasons it's preferable to prevent them in the first place... since sandboxes don't prevent malware, only the passage of malware from the sandbox to the host system, sandboxes won't protect the user from the consequences of malware... that means in an operating environment that includes a sandbox, the sandbox will require protective software just the same as if there were no sandbox at all - and virtual machines are notorious for being noticeably slower than their physical counterparts so that anti-malware software that slows down your physical machine is going to make your virtual machine even slower...
for all the things it can't do, however, a virtual machine based sandbox is easier to recover than the host system, but is it significantly easier than restoring a physical system from a previous image? my guess would be no, but that's really for the computer operator/administrator to decide...
22 comments:
First of all- sandboxing doesn't mean virtualization, virtualization doesn't mean sandboxing. Thay are different.
As about other staff- well, some malware can not be prevented by sandboxes, that is true. But the true is that there are a lot of malware that can be prevented by sandboxes. With lowing down anti-virus detection capabilities this gives us a simple matter- anti-virus + sandbox + firewall + backup drive gives a reasonable security nowdays. Without sandbox, your security setup is incomplete.
"First of all- sandboxing doesn't mean virtualization, virtualization doesn't mean sandboxing. Thay are different."
the way that sandboxing is being used today, i would agree they are not the same thing in general...
however in the context of malware protection, using a virtual machine to provide an environment in which to run untrusted applications is an implementation of the sandbox concept... that's different from a sandbox product which generally is a much simpler/lighter implementation of the sandbox concept...
"But the true is that there are a lot of malware that can be prevented by sandboxes."
sandboxing doesn't really prevent malware, it misdirects the malware... it presents an environment in which the malware can run, but it's an environment you can easily squash... that's not prevention, that's simplified recovery (assuming no extrusion has occurred)...
"anti-virus + sandbox + firewall + backup drive gives a reasonable security nowdays."
to which i would suggest adding application whitelisting (blacklists, whitelists, and sandboxes oh my!)... the version of kerio personal firewall i use has a form of application whitelisting built in (it was once called application launch control, but i don't know what it's called now)...
"Without sandbox, your security setup is incomplete."
that is really up to the user/administrator/whoever makes the decisions about what kind of security trade-offs to make... there are a lot of technologies you can bring to bear on the malware problem, the more you add the more malware you can prevent but the more you have to maintain and the more resources you have to give up... you have to decide where the point of diminishing returns is for your particular situation and stop there...
"however in the context of malware protection, using a virtual machine to provide an environment in which to run untrusted applications is an implementation of the sandbox concept" - not at all. Sandboxing means policy-based rights cut-off for untrusted processes. Do you see there any "virtualization" word? I don't...
"sandboxing doesn't really prevent malware, it misdirects the malware". Sandboxing restricts potentially dangerous actions from untrusted processes side, thus,this prevent malware from correct installation and penetration into your system. It just keeps malware within.
"whoever makes the decisions". The truth is that only early adopters may do such the decision. All the other people doesn't do it- they just follow. How many people really understand why they need firewall, for instance?
"Sandboxing means policy-based rights cut-off for untrusted processes. Do you see there any "virtualization" word? I don't..."
what you also don't appear to see is the difference between the concept and a particular implementation... your choice of words betrays that fact - "policy-based" means you're still talking about how it's implemented, not what it is in the most general sense... the concept of a sandbox transcends computer security and even computers themselves - a sandbox is just a test environment (sometimes that environment is a computer environment, sometimes it's something else), nothing more and nothing less...
"Sandboxing restricts potentially dangerous actions from untrusted processes side, thus,this prevent malware from correct installation and penetration into your system. It just keeps malware within."
sandboxing does not restrict dangerous actions, that's the job of behaviour blockers... sandboxing allows the actions to continue unimpeded because it's happening in a fake environment...
"The truth is that only early adopters may do such the decision. All the other people doesn't do it- they just follow. How many people really understand why they need firewall, for instance?"
it really doesn't matter if they understand the decisions they're making, it's still their decision to make... it would be the height of arrogance to pretend that i know what their needs are better than they do...
"what you also don't appear to see is the difference between the concept and a particular implementation".
Nobody need conception. It could not be eaten. You can using conception for real computer protection. People need concrete implementation. That is why, those implementation dictates the concept itself. Concept is nothing, concrete implementation is everything.
"andboxing does not restrict dangerous actions, that's the job of behaviour blockers... sandboxing allows the actions to continue unimpeded because it's happening in a fake environment...".
Then could you explain how sandboxes allow drivers execution in face ring0 environment?
"it would be the height of arrogance to pretend that i know what their needs are better than they do".
Have you ever made any software for end-user market? I guess- not, otherwise you would never say that.
"Nobody need conception. It could not be eaten. You can using conception for real computer protection. People need concrete implementation."
concepts are needed for understanding... what most people need is to understand what the technique is supposed to be accomplishing... most people don't need to know how it does it so in reality the implementation details are actually not as important as you seem to think...
"That is why, those implementation dictates the concept itself."
i'm sorry but that almost sounds egocentric... the implementation does not dictate the concept... a particular implementation is just one of many possible ways to achieve a particular high level goal...
"Then could you explain how sandboxes allow drivers execution in face ring0 environment? "
once again, how is an implementation detail... one possible (and obvious) answer to the how question is by making the fake environment a virtualized environment - but of course you refuse to consider virtual machines as a type of sandbox...
"Have you ever made any software for end-user market? I guess- not, otherwise you would never say that."
well, all i can say is you guessed wrong...
OK, one last argument that you are wrong. The sandbox HIPS I produce. There is no "fake environment" there (almost, there is only limited registry-based virtualization). Does it a sandbox or not?
"The sandbox HIPS I produce. There is no "fake environment" there"
no fake environment? we're talking about defensewall, right? perhaps you should read your own product page - untrusted applications run in a virtual zone according to the product page... virtual = not real = pretend = fake, zone = area ~= environment... a virtual zone is more or less one kind of fake environment...
are we on the same page yet?
In this context, "virtual" means "separated from trusted ones". This zone is virtual because, from the point of view of OS, trusted and untrusted processes are the same, that is me who adds difference and separate untrusted from trusted ones.
Well, the fact is that "sandboxing" means "restrictions", not "virtualization". All the sandbox HIPS have some kind of virtualization (file system and/or registry), but its main weapon are restrictions. Know, why I asked you about "fake ring0" execution of the drivers? Because all the sandbox HIPS do not do that! They just block out new driver's installation, and that is all!
As about virtualization- there are hardware, file system and registry ones. And we have three main streems of it:
1. VMWare, VirtualPC- harfdware virtualization tool, no sandboxing, supports registry and file system virtualization.
2. SandboxIE, GreenBorder, BufferZone- no hardware virtualization, policy-based restrictions (sandboxing), file system and registry virtualization.
3. DefenseWall HIPS, GeSWall- no hardware virtualization, policy-based restrictions (sandboxing), no file system virtualization, limited registry virtualization.
The point is that virtualization do not protect if it is not full hardware one. It is really important to understand that the main aim of all the sandbox HIPS is protection from malware installation into the system and breaking its intergity. There are two ways to to that - sandboxing (policy-based restrictions) and virtualization. It is possible to make a pure policy-based defense system without virtualization (some programs won't works, but anyway), but it is impossible to base it on virtualization only unless it is hardware virtualization as OS virtualization is possible, but it will takes a huge number of resources and time to build it- block driver's installation is much simplier! That is why, in the wild, all the sandbox HIPS's are both sandboxing and virtualization based.
ok, maybe i can approach this a different way...
the basic prerequisites for a sandbox is that there is an inside, there is an outside, and there is a boundary separating the two... the boundary defines the other two, it makes it possible for there to be a meaningful distinction between them, and really it is the boundary that makes the sandbox...
how you go about implementing that boundary is entirely up to you, there are multiple ways to do it... you can, as you say, do it with policies or other behaviour inhibiting techniques that limit what that which is within the sandbox can do... the thing is that virtualization inherently has this same kind of boundary - there is an inside (where the machine or resource virtualization takes place), an outside (where no virtualization takes place), and a boundary to keep the two separate...
now you obviously didn't like my description of a sandbox as being like a fake environment, i realize it wasn't very good, i was fishing around for a word other than virtual since that was too close to virtualization which you were already disagreeing with... maybe i should have called it a virtual space, or an artificial construct, or whatever - the effect is the same... whether the boundary is policy based or an inherent part of a virtualization technique, it still forms a contained area that (to varying degrees) seems to behave like it's just part of a normal system even though it's not (it's separate from the normal system and access to the normal system is restricted by the boundary between the two)...
as for protection with virtualization, there are varying degrees of protection and they correspond roughly to the degree of completeness of the separation between the virtual environment and the host environment... sure filesystem and registry virtualization don't offer a perfect barrier, but the reality is that a full blown virtual machine isn't quite perfect either - it's not entirely beyond the realm of possibility for something to escape a virtual machine... nor is it always necessary for malware to escape the virtual environment or sandbox (if you insist on continuing to regard them as completely different) in order for it to do it's bad deed...
Yup! Right now that is a 100% correct definition for various sandbox HIPS solution!
As about virtualization- I agree with you too. In fact, full file system and registry virtualization generates problems with usability and security. As I have planned DefenseWall as a simpliest in use HIPS, there is only limited registry virtualization, other sensitive places are protected with using policies. Defense itself is nothing, balance between protection strength and every day usability is everything!
Now, back to pointing out to users what they need. In fact, all the software (but not only!) companies do that! They try to say user "Hey, you need it!!!". It calls ads. And then it is user ho make a decision- use it or not, is it meets their requirenments or not. MOst of the users can't make any decision, especially, in security field. That is why, they just follow the magazine articles...
"Now, back to pointing out to users what they need. In fact, all the software (but not only!) companies do that! They try to say user "Hey, you need it!!!". It calls ads."
yes, advertising and marketing... and i'm not the least bit satisfied with the way that part of business works... they make no attempt to educate the user even though it's a perfect opportunity to do so... the better the user understands the problem that the product is trying to help them solve, the more likely they'll be able to make an informed decision...
there are only 2 reasons why advertising/marketing wouldn't want to develop informed consumers: they're too lazy or they don't really believe their product does the best job...
"And then it is user ho make a decision- use it or not, is it meets their requirenments or not. MOst of the users can't make any decision, especially, in security field. That is why, they just follow the magazine articles..."
well, one of the things i'm concerned with is helping people understand so that they're better able to make good decisions on their own... that's one of the reasons i point out the limitations of various techniques, since that's information that is never presented in a marketing campaign or by product/technology evangelists...
"there are only 2 reasons why advertising/marketing wouldn't want to develop informed consumers: they're too lazy or they don't really believe their product does the best job..."
Well, not exactly. There are two reasons for that:
1. I always trying to explain users how DefenseWall works, how sandbox HIPS itself works, that there are sandbox HIPS in the world end their effectiveness is much higher that anti-viruse's ones. But (can you believe in it?) only some of them may understand what am I talking about (its too technical and hard to understand), they prefer to rely on their feelings (security product-defense strength-feelings! WOW!), comparative tests and brend ("it is Symantec, men, it is cool staff!").
2. Ads works! You put $1M to input and get $20M on output (for example). So, why bother?
"well, one of the things i'm concerned with is helping people understand so that they're better able to make good decisions on their own"
So and I am. That is why I've tried to explain you the difference between sandboxing and virtualization. If even computer scientist do not clear understand that- what to talk about simple users?
"1. I always trying to explain users how DefenseWall works"
then you're not included in the set of people who "wouldn't want to develop informed consumers"...
"2. Ads works! You put $1M to input and get $20M on output (for example). So, why bother?"
this is the laziness i alluded to earlier...
"So and I am. That is why I've tried to explain you the difference between sandboxing and virtualization. If even computer scientist do not clear understand that- what to talk about simple users?"
i still maintain that virtualization is inherently a type of sandbox...
much of my original article actually applies equally well to sandboxes that don't use virtualization, but i was focusing on those that do precisely because there is a false belief out there that all you need to do is use a virtual machine for untrusted apps and you'll be safe... they may prevent intrusion into the host system, but they don't prevent intrusion into the virtual environment and when we freely enter confidential information (like passwords and credit card numbers and the like) into the virtual environment they most certainly aren't going to prevent extrusion of that confidential information... the same holds for sandboxes that don't use virtualization of course...
I think there is nothing essentially wrong with Kurt's post ,except maybe Ilya might be a bit sensitive about making clear the distinction between sandbox and virtualization because he hawks a product that does not have (much) virtualization.
while the few sandboxes - BufferZone, GreenBorder and not to mention the various VMs that are getting any air time do have that.
One question, is CORE FORCE Sandboxing HIPS too?
@luke:
"One question, is CORE FORCE Sandboxing HIPS too?"
from what i read on wikipedia about it i would say no, it does not implement a sandbox (even though the wikipedia entry calls that part of it's functionality a sandbox)...
since the software is preventing behaviour rather than just redirecting it to a safe place then it's not a sandbox... instead it is a secondary (due to the fact that the OS has something similar built in as the primary one) access control mechanism... specifically, it seems to implement a process-centric access control system (the OS' is user-centric, obviously) where individual processes are granted/denied permission to do various things....
maybe the description on wikipedia is incomplete/wrong (it is wikipedia after all) but i don't believe you can create a sandbox solely out of permissions...
Wikipedia's description of the functions is just about right.
>since the software is preventing behaviour rather than just redirecting it to a safe place then it's not a sandbox...
But as Ilya points out the main weapons in sandboxes are policy restrictions, which is preventing behavior really.
In that sense something like Ilya's Defensewall is basically just a very well chosen set of policy restrictions already setup for people who don't want to mess with them and figure out what restrictions are secure.
So with Coreforce you can sandbox a certain process so it can only write in a certain folder (plus other process centric restrictions), creating a kind of boundary between it an the rest of the system.
The fact it is process centric isn't a critical point really, since with most of the HIPS, it's also process centric , you sandbox processes (whose child processes inherent the same restrictions).
But all this is a moot point, i think all parties agree basically on what and how they work, the rest is just semantics.
@luke:
"But as Ilya points out the main weapons in sandboxes are policy restrictions, which is preventing behavior really."
which i would have taken to mean that those were things one uses with a sandbox, not the way the sandbox is implemented...
setting up policies/permissions is a form of behavioural whitelisting, not sandboxing... it defines what behaviours are good/allowed from various applications just as behaviour blockers define what behaviours are bad/disallowed... one of the key aspects of a sandbox is that it knows nothing about what's good or bad, it's just a container in which things think they're running in a normal system with normal access to the system objects and resources but in reality aren't...
"The fact it is process centric isn't a critical point really, since with most of the HIPS, it's also process centric , you sandbox processes (whose child processes inherent the same restrictions)."
it's process centricity is significant if you recognize it as the access control system it really is... traditionally access control is centered around the user/principal, not the process... it's only relatively recently that the idea that applications should be granted/denied permission to do various things has really taken hold...
"But all this is a moot point, i think all parties agree basically on what and how they work, the rest is just semantics."
semantics are more important that most people give them credit for...
Oh well, seems like this whole thread is dancing around the definitions of sandbox and virtualization.
These days everything is virtualization it seems.
Take the recently released
Returnil Virtual System Personal Edition and Windows SteadyState.
Are they Sandbox, virtualization (however defined) or just rollback/imaging software?
What's the difference? Maybe you can do a post on that.
@luke:
"These days everything is virtualization it seems."
funny, i was thinking the same thing about sandboxing...
"Returnil Virtual System Personal Edition and Windows SteadyState.
Are they Sandbox, virtualization (however defined) or just rollback/imaging software?"
returnil sounds like conventional virtualization with the added feature that the virtual machine has an image of the host system written into it...
i can't find anything about steadystate that would suggest it uses virtualization... a change control/rollback system seems to be a more apt description... maybe the description i found on the download page wasn't accurate enough but it sounded like applications write to the live system rather than into a virtual environment or sandbox...
"What's the difference? Maybe you can do a post on that."
well, i have been thinking of doing a post on the 3 preventative paradigms (blacklist, whitelist, sandbox), perhaps that will make some things more clear...
the key detail here, i think, is that when you're talking about something operating in a vm or sandbox, when it makes a modification it's made in the vm/sandbox, not the live/host system... being able to recover from unwanted changes to the host system is fine, but it's recovery... sandboxing is prevention by redirection, not prevention by undo or prevention by active blocking...
I'm begining to believe that hackers should be discovered and executed with extreme prejudice. The ending of the movie Braveheart comes to mind... but much slower.
@anonymous:
i think that's a bit extreme...
Post a Comment