no, bromium will not kill all malware forever

over the weekend a discussion broke out on twitter (as discussions are want to do) about a somewhat overly optimistic article concerning the new anti-malware apple of the security community's eye: bromium.

the primary tactic that bromium uses (or at least the primary one that people focus on) is isolation/sandboxing. bromium's vsentry product uses virtualization on a per-process basis to isolate every process from the system and from each other. that level of granularity for isolation is a lot higher than most sandboxing efforts can give you. while there are certainly benefits to that granularity, there are also drawbacks.

perfect isolation is actually not desirable, we want and even need to be able to use the results of one process inside another one. the more sandboxes you have, he harder this is to manage. the folks at bromium have opted to address this issue using rule-based systems to decide what something in a sandbox can access as well as what to do with any changes that are left when the sandboxed process is finished. rules which, in all likelihood, the administrator can modify to suit their needs.

now, while the article in question is reasonably good at explaining what bromium's vsentry does, the author (jason perlow) takes the arguably naive view that this sandboxing technique can stop all possible malware (as evidenced by the article's headline: "Bromium: A virtualization technology to kill all malware, forever"). the reality, however, is that there are limits to what sandboxing can do, and as clever as the folks at bromium are, they aren't clever enough to deliver on the promise that headline makes.

that's a problem, because people are going to read that headline, see nothing in the article to actually contradict it, and believe that it's actually true. have we seen claims like that before? sure we have - saying it can kill all malware forever is not intrinsically different from claiming 100% protection. it's classic snake oil, only in this case it's not the vendor that's spreading it (as far as we know - we don't know exactly what the folks at bromium may have said to mr. perlow, only that they say the headline is his words, not theirs).

i suppose that should mean there's no problem, right? the vendor's hands are clean, after all. the snake oil is being spread by a third party. the vendor isn't doing anything about it in this case or previous cases that have arisen because, let's face it, they benefit from it. it's good for bromium's business if people think vsentry is better than it actually is, at least in the short term. in the long term, the kinds of mismatched expectations that creates are the same kind that the AV industry struggles with daily.

it is bromium's responsibility to control how their products are perceived, and by failing to take action they are giving tacit approval to the snake oil being spread on their behalf. their hands are not actually clean, they are dirty through negligence. however, i didn't really expect any better of them (though i did give them an opportunity to surprise me) and you probably shouldn't either. tread carefully - caveat emptor.

short thought on sandboxing

jeremiah grossman recently penned a guest post for zdnet extolling the virtues of sandboxing. i've made no secret about the fact that i'm also a fan of sandboxing (though i'm not entirely on board with jeremiah's depiction of it with regards restricting things - that verges too close to behaviour blocking for liking) but the sandboxing jeremiah was referring too was the kind that is built into applications as a feature.

not too long ago posted about sandboxes being added to all sorts of apps and wondered (well, suggested) that such sandbox sprawl might not be the best way to go about things. jeremiah's observation that adding sandboxes to apps changes the game from a one exploit show to a two exploit show made me realize another reason why relying on the application's own sandbox is less than ideal - the attacker knows exactly which sandbox they have to escape from.

by contrast, with a separate stand alone sandbox, an attacker wouldn't necessarily know which sandbox is involved and would then need to develop escape exploits for multiple sandboxes and try the shotgun approach, firing them all at once and hoping for the best.

i do believe i'll be sticking with the stand alone sandbox. it seems to have the tactical advantage.

sandboxes, sandboxes everywhere

lysa myers drew my attention to some interesting developments in the sandboxing arena last week. at first i thought she might be referring to security companies adding sandboxing to their arsenal (which i'd really like to see more security vendors do), but that's not it at all. it's actually sandboxing being added to individual applications. not only will adobe reader now come with it's own sandbox, but dell is coming up with a sandboxed version of firefox too.

i have mixed feelings about this sort of development. on the one hand it's nice to see sandboxing getting more attention and use, and these efforts will surely bring the technique to the masses. but on the other hand i worry about the effects of baking sandboxing into applications - especially applications that might call each other.

if something is running inside a sandbox and it executes an external program, that program should also run inside the same sandbox (otherwise the sandbox is rather simple to escape from). what happens, then, when the dell kace secure browser (which runs in it's own sandbox) launches adobe reader (as it would generally be expected to do when you click on a pdf link)? would we have adobe's sandbox nested within the browser's sandbox? how would that work - specifically how well (or poorly) would it work? you may recall that google's chrome had it's own sandboxing right from day 1 but that there were problems coexisting with other sandboxing technology (that i discussed here). the conflict between chrome and sandboxie seems to have been resolved but, as more and more applications come with sandboxing baked in, further inter-sandbox incompatibilities seem like a pretty likely outcome.

not only is cross compatibility between sandboxes a problem, but the question of implementation efficacy is an issue too. chrome's baked in sandbox was easy to escape because chrome's sandbox wasn't complete. it was only able to sandbox a narrowly defined set of processes specific to the browser itself - it couldn't even sandbox the plugins that it ran in order to render rich content like flash. it stands to reason that any baked in sandboxing technology is only going to be good enough to sandbox the application it's baked into. if the sandboxing technology was good enough to handle all the secondary processes that an application might launch then the technology might as well be made into a general purpose sandboxing product instead of being baked into an application. some may be better than others and people may be lulled into a false sense of security by thinking that the sandbox baked into application X is as good at protecting them as the sandbox baked into application Y.

i'm a big proponent of sandboxing, but i don't think sandbox sprawl is a good thing. it would eventually replace a few discrete sandboxes with known properties and known shortcomings with a ridiculous number of sandboxes with unknowable properties and shortcomings and cross compatibility issues. i'd prefer to see users using one or two general purpose sandboxes than dozens of  custom sandboxes.

returnil give-away at ghacks

i don't normally do posts like this, but in the interests of raising awareness of alternative anti-malware techniques there's a give-away going on at ghacks.net today and they're giving away the premium version of returnil...

returnil is (as far as i know, i haven't tried it yet myself) an instant system recovery sort of sandbox... the free version at least will revert any changes that were made (good or bad) the next time you reboot...

i know that sandboxie was mentioned on the network security podcast and i've mentioned it a time or 2 as well... i think sandboxes are an invaluable security measure and i encourage people to try them out and this returnil give-away is a chance for people to try out the premium version of a sandboxing approach that has a lot of proponents over at wilderssecurity.com...

chrome follow-up

i mentioned in the previous post that there was a big gapping hole in chrome's sandboxing in that it doesn't sandbox plugins and that i was unable to obviate this problem by running chrome in a 3rd party sandbox... thanks to user Franklin on the wilders security forums i was pointed towards this sandboxie support forum thread that suggests you can make chrome work in sandboxie if you allow sandboxed apps to load kernel drivers outside of the sandbox... sandboxie itself strongly recommends against doing so, as do a few of the participants in the thread... lowering the security of sandboxie in order to make chrome work sort of defeats the purpose of using sandboxie to shore up the gapping hole in chrome's sandboxing...

in addition to that problem, however, it seems that even after you uninstall chrome it leaves a scheduled task behind to run the googleupdate program and the googleupdate.exe itself is also left behind... i've seen data files left behind after an uninstall before but i don't think i've ever seen binaries left behind (or if i have it's rare enough that i don't recall it) - that's a pretty crappy uninstall...

chrome plated security

seems like everyone is talking about google's new browser called chrome... google even made a comic book about the product...

the comic describes a lot of what went into chrome and it sounds like google made some very interesting design decisions, like making it a multi-process application instead of simply multi-threaded, or their new javascript engine... it also captures the google aesthetic quite well...

those aren't enough to make me switch browsers however... i enjoy a certain level of security with my current setup and would like at least an equivalent level from any alternative browser but it doesn't seem like i'd be able to get that from chrome...

chrome implements two of the three preventative paradigms i've written about before... specifically it implements blacklisting of sites (both sites known to host malware and sites known to be phishing pages) and it implements sandboxing... what it doesn't seem to implement (at least the comic made no mention of it and i saw no sign when i tested it out) is whitelisting...

there are a couple of reasons why whitelisting may have been left out of the mix... the most simplistic of which being they simply weren't familiar with the concept - indeed, website blacklists are in most modern browsers now so they're well known, and there was a mini boom of browser sandboxing tools (enough that google actually acquired one called greenborder last year) so they should be on google's radar too... as far as whitelisting active web content goes, however, there aren't a lot of players - noscript stands out as the only one i can think of (other than IE's trusted zone which almost no one uses because it's not user friendly)...

if we assume google was familiar with whitelisting active web content in general and noscript in particular then another possible reason for it's exclusion emerges - when you look at the frequency of noscript updates (updates that are more than just a new list as you'd get with a blacklist update, updates to the codebase itself) you come away with the impression that technology like noscript is far better off as a plugin than built into the browser... i don't think anyone wants to update their entire browser that often...

finally, a thought that formed while commenting on michael farnum's blog - there seems to be a fundamental philosophical conflict between the default-deny paradigm that whitelists represent and organic growth of application ecosystems... the way web content is developed can be considered to be the very embodiment of organic growth and google makes it pretty clear that they want to help that along, not get in it's way, so it could very well be that whitelisting simply doesn't fit in their security vision...

it's a rather important part of mine, however, so at the very least i won't be switching to chrome until someone makes a noscript-like plugin for it... things won't be all sunshine and lollipops when that happens, though... as i mentioned earlier, the browser is supposed to have sandboxing built in and on the surface that sounds great... unfortunately they haven't figured out how to sandbox plugins... this seems like a pretty big deal to me because flash is a plugin and shockwave is a plugin and quicktime is a plugin, etc... the very active content that isn't being controlled by way of a whitelist is apparently not being contained by their sandboxing technique either... this seems a little backwards because i'm fairly sure that back in the days when greenborder was still around if you ran your browser in that sandbox the plugins stayed in the sandbox too... no worries, we'll just run chrome inside another sandbox like sandboxie - right? try it and you too may be greeted with the "sad tab"...

i've no idea why (i'm no sandboxie power-user) but all pages lead to sad inside a second sandbox and the helpful reload advice sometimes leads to the frozen tab (and boy does he look cold)...
from the looks of things in process explorer, each tab process runs in a sandboxed process with the unsandboxed browser process as the parent but when the browser process is sandboxed it doesn't appear to be able to create it's own sandboxed children (even though a sandboxed firefox can launch vlc in the sandbox without trouble)...

so there's no whitelist and not only is the built in sandboxing insufficient, it appears to kill the option of using a 3rd party sandbox to make up for it's deficiencies... it's pretty, don't get me wrong, i like the look of it - i also like the idea of faster javascript, but i get more security with my current browser setup and when legitimate sites like yahoo mail or cnn are sometimes found to be serving malicious content that security becomes pretty important...

microsoft patents sandboxed behavioural profiling?

so microsoft is trying to patent running suspect samples in a virtual environment and using behavioural analysis to determine if the sample is malware...

can we say prior art? isn't this what norman's sandbox technology has been doing since (i think) the previous millennium?

what is a sandbox?

in the anti-malware sense a sandbox is a (generally) simulated computer environment in which untrusted software (ie. potential malware) can be run while still keeping the trusted host environment isolated from it...

a sandbox can be implemented in more than one way, the most well known is probably the virtual machine... a virtual machine based sandbox is one where the computer hardware itself is simulated and an OS and other software run on top of that simulated hardware...

another type of sandbox is one that simulates access to resources (such as files or the registry) of an existing system by trapping attempts by programs running in the sandbox to access those resources and redirecting those access attempts to copies residing within the sandbox environment... this uses less resources than a traditional virtual machine and can be used in a more transparent way by end users because it doesn't set up a completely separate system which may or may not be similar to the host system they're likely familiar with (nor do they have to try to wrap their heads around the idea of a computer within a computer)...

a third (but much more primitive) technique which could arguably be considered a kind of sandbox is the use of different drive images to separate the main computing environment from other environments used for running untrusted code... this has the problem that the environment for trusted programs and the one for untrusted programs can't be in operation on the same computer at the same time, which makes it a little inconvenient if you only have one physical system...

ultimately these technologies are all meant to try to replace the original practice of using a physically separate computer dedicated to testing... a second physical computer for untrusted programs is probably the least convenient way to isolate a trusted environment from untrusted code but it is also probably the most secure...

back to index

the three preventative paradigms

something i've had circling around in my head for a while now is a fundamental division between malware prevention techniques... i'm moderately certain i've missed something (because three just comes up way too often in security) but it seems to me that everything falls into one (or more) of three broad categories: blacklisting, whitelisting, and sandboxing...

i know, right now you're probably saying "kurt! you missed a whole bunch of stuff - what about heuristics? what about behavioural techniques?"... well, lets look at that - what does behaviour-based malware detection do anyways? it monitors behaviours, sure, but how does it decide something is bad? what's going on is that it's actually comparing the behaviours (or combinations thereof) to a list of known bad behaviours (or behaviour combinations) which means it's a type of behavioural blacklist... likewise, heuristics compares properties (like the presence of certain familiar routines) of the program being scanned to a list of properties known to be used in bad programs and so also represents a type of blacklist... the blacklist technique is not the exclusive domain of signature scanning... anything that tries to identify something as bad (basically anything that tries to algorithmically answer the question "is this bad?") must do so by comparing it or some aspect of it to a list of known bad things of a similar type - and that makes it a blacklist...

"but kurt," you say, "that's not the only kind of behavioural technique out there. what about ones where you define what behaviour different programs are allowed to perform such as provided by various HIPS products?"... well, you'd be right, that behavioural technique is not a blacklist... besides being a process-centric access control system, it is more generally a behavioural whitelist... just as the blacklist technique is not exclusive to signature-based virus scanning, the whitelist technique is not so narrowly defined as to only specify application launch whitelists and/or the preferred paradigm for deploying firewalls... if it tries to block everything that isn't good/allowed/authorized (rather than everything that is bad/not allowed/unauthorized) then it must first be able to answer the question "is this good/allowed/authorized?" and to do that it must have a list of known good/allowed/authorized things - and that is a whitelist...

so if it answers the "is it bad?" question it's a blacklist and if it answers the "is it good?" question it's a whitelist - what's left? you might think it's some combination of the two but in fact it's not answering any question at all... the truth is our ability to answer either of those questions is limited so we need to take care of the case where we can't answer either of them and that's what a sandbox does... rather than blocking things outright based on knowledge of what's good or what's bad, sandboxing prevents malware intrusion to the host system by misdirection... the software which may or may not be malware is given a sandboxed environment to work in rather than the host environment and barring any ability to escape sandboxes, what happens in the sandbox (good or bad) stays in the sandbox... it doesn't necessarily prevent extrusion (leaking) of sensitive data you enter into applications running in the sandbox, mind you, and in that sense is a lesser form of prevention - but preventing malware from affecting the host system without any knowledge of or ability to decide on what's good or bad is no small feat...

if we could just assume everything that a blacklist doesn't alert on was good then life would be simple, but unfortunately that's not the case... likewise, assuming everything that isn't on a whitelist must be bad isn't very useful either (at least not unless you're dealing with very restrictive environments and even then there are complications)... once again, these three approaches are complementary and are best used together...

snake oil based lubricants should not be used with your browser condom

thanks to alex and paperghost for bringing my attention to the hilariously named browser condom...

browser condom is basically application virtualization/sandbox technology like sandboxie, bufferzone, and green border but something struck me about some of the quotes i was seeing, something distasteful...

right at the top of vappware's product page we have:

It's and advanced technology that allow you to run any kind of software in your computer without a risk of be infected with any kindof virus, spyware, trojan and any kind of malware. (VTD) , Virtually Transmitted Diseases.

are you thinking what i'm thinking? yes, apparently the folks at vappware are unfamiliar with the halting problem and it's implications with regards to any technology being able to stop all viruses (let alone all malware), hence i'm calling it snake oil...

now to be fair (who me?) it occurred to me that maybe i should take a look at some of the competitors to compare them to vappware with respect to snake oil and was disappointed to find that similar claims are made about both bufferzone (which boasts "complete safety") and green border (which "frees you from ever worrying about clicking the wrong link")... sandboxie was the only one i looked at that didn't seem to have such outrageous claims (or at least if they do have one it's not as easy to find)... sandboxie also seemed to be less flashy and more informative right off the bat, almost like they were hoping people would choose their free product based on it's actual merits (how refreshing)...

what virtualization can and cannot do in an anti-malware context

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