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.
4 comments:
Hi Kurt,
While I respect your right to write whatever you like on your blog, I would like to note that what I *do* care about, and spend time correcting, are technical inaccuracies, rather than choices of words. In every way, the article you reference was the most technically accurate description of our technology by a journalist. Usually people make a lot of mistakes in describing how we do what we do, and I care about that more than someone's opionions of the implications of our technology to the future of malware.
For example, your basic error is misunderstanding the very foundation of our technology. Rather than learn more about us and dig deeper than the article, you have decided that our technology virtualizes processes because you read the word "tasks" and assumed they meant "processes". In fact, when we refer to user tasks, we are talking about user activities.
You are correct that isolating processes would obviously create problems, but if you'd grok the underlying technologies behind our product, mainly the notions of copy-on-write micro-VMs and least privilege separation kernels, you'd understand that we isolate user activities, not simply system processes.
I'd suggest reading our whitepaper, learning more about us, and then engaging us in meaningful discussion, which I would welcome, rather than an arbitrary flame war over a journalist's choice of words.
tal, if you want to correct technical inaccuracies then i suggest you talk to jason perlow about the use of process versus task, as that is the word he used.
i continued the usage in part because of his article but also because of the ambiguity surrounding the term task - in at least some quarters it is synonymous with process. in others it is frankly rather vague.
and where would i have even heard of vsentry focusing on tasks, when mr. perlow used the word process, if i hadn't already looked into the technology? further, where would i have gotten the idea to mention what happens to changes made after the process, or rather task, is finished when mr. perlow does not appear to have referenced your persistence rules in his article?
do i not grok the concept of copy-on-write? sandboxie performs copy-on-write. i wouldn't be surprised if other application virtualization products do as well. it's not a complicated concept, nor is least privilege.
micro-VMs is something that perhaps deserves to be revisited, if your concerned about technical inaccuracies, since they aren't actually virtual machines (by every description i've read you aren't spinning up new virtual machines for each task). i know it's an easy shortcut to use the term VM whenever you're talking about virtualization, but that doesn't make it so.
and that brings us back to choice of words. you cannot communicate technically accurate information without using the right words, so the choice of words matters, even if you find it convenient to ignore it.
i'll take your correction under advisement, of course. you virtualize on a task-by-task basis and so are even MORE granular.
i don't think that changes much in the context of this discussion, though. you think that so long as the technical details are right (which apparently they weren't by your own metric) that the conclusions of articles like mr. perlow's don't matter. i've been observing the security domain for over 20 years, i've seen how things like that can corrupt a message, and how that corruption can lead people to think and act in ways that are detrimental to their security. those choices of words do matter - except maybe they don't matter to you, since, after all, your interests are not necessarily the same as those of the pool of your potential customers.
Kurt,
You're being pretty hostile, so I'm going to make one final attempt to explain the difference between, say, sandboxie and micro-virtualization.
I understand the desire to put what we do into the same hat as sandboxie. But we actually do spin up VMs, but they are copy-on-write VMs. Among our innovations is the use of a hypervisor that creates copy-on-write VMs which we call micro-VMs on a user task by user task basis. These VMs don't contain anything until the user begins to be active inside of them. They are hardware isolated - we use VT - to ensure that each micro-virtualized task does not share any priveledged resources or data with any other task, but has everything it needs in order to reach its logical conclusion.
As primers, I suggest reading this blog:
http://blogs.bromium.com/2013/04/24/micro-virtualization-for-the-security-architect-2-of-2-isolation-%e2%89%a0-protection/
As well as my responses here:
http://security.stackexchange.com/a/23747
Best,
Tal
oh for crying out loud. i'm not comparing bromium to sandboxie. i'm simply pointing out that i've seen copy-on-write before in other types of products.
you folks may have been the first to apply copy-on-write to the particular kind of virtualization you're doing, but the general concept predates you.
as for VMs, i think we're going to have to agree to disagree on what constitutes a 'virtual' machine.
and thanks for the links. i will get to them in good time.
Post a Comment