Showing posts with label virtualization. Show all posts
Showing posts with label virtualization. Show all posts

Monday, May 20, 2013

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.

Saturday, March 31, 2007

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

Thursday, December 14, 2006

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

Saturday, September 23, 2006

blue pill 2.0

have you heard the news about a new version of the blue pill?

there have been a number of nails in the coffin of the blue pill that i never bothered commenting on, mostly because i felt i'd already said enough... the final nail in the coffin, i think, should be the fact that joanna rutkowska herself is now working on the next version which is supposed to be even stealthier (stealthier than 100% undetectable?)... clearly then, the blue pill was not 100% undetectable and all those people who said so were proven right...

but this is not an i told you so...

see, version 2.0 is supposed to be truely 100% undetectable (at least that's the goal)... 1.0 fell victim to certain technical issues that joanna hopes to address in the next version...

what she won't be addressing (because it can't be addressed) are the theoretical issues that make 100% undetectable malware impossible... stealth is a protective measure and 100% effective stealth implies that perfect protection is possible when in fact we know this is axiomatically false... blue pill 2.0 won't meet the 100% undetectable snake oil goal joanna has set for it anymore than v1.0 did, nor will version 3 or 4 or 65...

see, this isn't an i told you so, it's an i'm telling you so again because somebody wasn't listening the first time...

Thursday, June 29, 2006

the blue pill is NOT 100% undetectable

that's right, the blue pill is not 100% undetectable...

i was amazed at the number of writers swallowing the "100% undetectable" bit hook, line, and sinker... clearly people aren't really thinking things through...

and i'm not even referring to my previous post on the blue pill, that was really just conjecture... i don't know it will work, nobody knows what will work against the blue pill because nobody's seen the blue pill yet except the researchers involved... i suspect that a pre-emptive tactical move to secure privileged virtualization resources can be used to foil next-gen vm-based stealth but it's all just guesses right now...

no, now i'm going to go back to first principles... let's start with some background - there is no perfect protection... this is a truism, an axiom, and something that the bad guys will tell you ad nauseam* in trying to show you that your security mechanisms, no matter how good, are flawed... and you know what they're absolutely right, there is no perfect protection - but watch out if you try to turn that attitude around on them 'cause you will get flamed... you see there are true believers out there, pro-malware zealots who in one breath will gleefully expound on how your security efforts are vulnerable to this or that in an attempt to feel superior for being on the supposed winning side in the malware/anti-malware battle and then in the next breath go ballistic when you suggest that the same principle applies to the tricks and techniques that malware writers use to protect their malware from security apps...

yes, that's right, stealth is nothing more than a protection mechanism (one of many as a matter of fact) that facilitate malware persistence and if there can be no perfect protection then there can be no perfect stealth, no 100% undetectability... nada, zilch... if the blue pill were to turn out to be the exception then we would study it and learn from it and build more perfect protection techniques - the same fundamental principles that apply to good software must apply to bad software too and vice versa, it's all just software after all...

what's more, i can't believe nobody is catching the scent of snake oil... i mean come on, 100% undetectable should sound as impossible as 100% detection...

no, the blue pill is not 100% undetectable, it cannot be, it would violate one of the most fundamental principles in security... it may very well be undetectable by current products but that's just not the same thing... by that logic new viruses are 100% undetectable --- until they're not...

[edit * thanks for the spelling correction, edgewalker]

Wednesday, June 28, 2006

the blue pill is hard to swallow

i've blogged before about virtual machine based stealthkits and i was pretty dismissive of the idea so you might think there was nothing more for me to say about the subject now that another one has been proposed (except maybe to say "not another one!")...

well here's my mea culpa... while the method of booting clean to get a baseline snapshot of the system to compare to when trying to generically detect the presence of active stealth techniques (outside-the-box cross-view difference detection) is still quite effective against conventional stealth malware, joanna rutkowska presents an idea for stealth where that just won't work... in memory only malware won't be found on the disk after a clean boot so the outside-the-box method won't work... also, stealth born out of moving the entire operating system into a virtualization layer (vm-based stealth) has the potential to make the malware invisible in memory - so it would seem like it's the perfect stealth...

and indeed it's getting called completely undetectable, but for me that's a little hard to swallow so i got to thinking - how would you attack something like this?.. the best way to attack malware is to find some scenario where it's not in control... clean booting doesn't get us there in this case because the malware will be entirely gone so there won't be anything to find... in-situ cross-view analysis won't work either because everything's within the malware's virtualization layer...

but what if something wasn't inside the malware's virtualization layer? in fact, what if the malware itself got executed inside of a virtualized system? a sandbox using virualization technology as advanced as that which the malware uses, designed not to do bad things but rather to look for the tell-tale signs of active stealth (especially vm-based stealth)...

if undetectable virtualization technology can be used to hide the presence of malware, then equally undetectable virtualization technology pre-emptively deployed on the system should be able to detect the undetectable vm-based stealth malware if/when it is encountered...