Application Sandboxes: A pen-tester’s perspective

The problem with EMET is it loves to break things up in my computer. The only way to fix it is to find what mitigation technique(s) which caused the problems by disabling them one by one. It's just not worth the effort in my personal opinion.

 

So if everyone starts using Chrome under EMET, malware writers will never be able to come up with exploits? That's unreasonable, imo. But that's not the point.

My point is that is more likely the appearance in the wild of malware that simply targets Chrome (that have a large user base), than the appearance in the wild of malware that targets Chrome and also is able to bypass a well configured Sandboxie (why bother? why the extra time and money invested for such a small percentage of computers? Like i said, is possible but highly unlikely). And the same is applicable to the use of EMET.

I think that the larger attack surface factor have more importance in the circumstance where someone is under a targeted attack. For the majority, that's not under that circumstance, the use of Sandboxie, or EMET, or some other layer (instead of the use of Chrome alone), will almost always be a distinctive advantage, and therefore the better option, imo.

 

I have the same problem, I still don't know why EMET doesn't like my computer.

 

I found using it to mitigate Chrome was a problem, but for a short time now, out of interest sake and experimentation because there are some who want to continue using the O/S (I'm migrating away form XP for good), I'm using all mitigations for Firefox with EMET 3.0 on XP Pro SP3 and so far no breakages, even with Firefox SBIE'd.

The point is imho to understand the threat landscape and I truly believe script control in the browser is so very important, particularly for XP users. Drive-by downloads don't require social engineering, except for the ones deliverd via email. If one can tame EMET to afford even some mitigation of the browser and other Internet-facing apps, then that is huge as well. You don't want malicious shellcode getting a foothold in the browser's memory heap.

 

Hear, hear!

 

The main problem with these reasonings is that in SBIE4 it can be configured to block all of the exploits and all of the vunlerabilities (both user mode/user-level and kernel-mode/kernel-level exploits) if you know what to configure and what to block in the first place, so even though, by default SBIE is vulnerable is not vulnerable anymore once you block access to those bugs/holes-and there is nothing that can bypass this.
Also, like Peter said these are only POCs and that's about it-they are not real, one thing is to hypothesize it/theorize it and one thing is something that is 100% real and in everyday practice.

 

That's a good challenge to check it out. Isn't it?

 

That wasn't the point.. they were examples.

 

Say, you have a beef. But you're not allowed to:
- fry it
- boil it
- grill it
- put it on fire
- put it between two layers of breads
- eat it raw
- give it to someone or something else

If you do one or more of the above, a secret government agent will shoot you down with a handgun until you're dead. Of course, you can think of any new method of how to cook the beef that is not forbidden. But you'll have to be very creative. It doesn't matter if such restrictions are only applied to your town or to the whole country. You still will have to come up with something new, which isn't easy. And that new method might be forbidden as well within an update to the laws. Not to mention you have to cook the beef ASAP or it will get rotten.

And vulnerabilities in Chrome and other popular browsers will get patched quickly. The advantage of popular software being targeted is the developers usually know how to deal with attacks which might compromise their products.

Or may weaken the security features of the programs and OSes themselves.
hxxp://support.emsisoft.com/topic/12668-oa-blocks-acrobat-reader-in-runsafer-mode/
hxxp://support.emsisoft.com/topic/11574-online-armor-run-safer-help/

Anything you've added to your computer will increase security risks, even applicable to non security software. For example, if you don't install Java, then you're practically immune to Java-based exploits. What matters most is if the increased security risks are worth to take.

 

I wonder if this will really work against drive-by-attacks and exploits, they don't use the normal download method and Public Fox seems more aimed at stopping other users from messing with FF and downloading all kinds of stuff.

 

The problem is that Malware writers have the advantage here, because it's typical "cat and rat" game. Vulnerabilities may be patched quickly, as long as they are known to the developers.

Check this link about Chrome hacking contest: http://arstechnica.com/business/2012/03/googles-chrome-browser-on-friday/

For sure Google was fast patching the vulnerabilities. But the hackers who discovered those, could have sold them instead of participate in the contest and that way make them known to the developers.

I agree, what matters most is if the increased security risks are worth to take. So, once again, but slightly modified to answer your reasoning, what is more likely to emerge in the wild?

- A exploit that affects Chrome?

- A exploit that affects Chrome through security software like Sandboxie or Defensewall?


Is the security increase brought by Sandboxie worth against the risk of the appearance in the wild of malware that target's Chrome through Sandboxie?

Or is more likely that a properly configured Sandboxie is able to stop an exploit that targets Chrome (huge user base), or Java (huge user base), or some other widely used browser plugin?

IMO, the first is highly unlikely, and the second is much more likely. That's why i think that using Sandboxie together with Chrome is still the better option.

 

It's always like that. Otherwise we won't need to update everything. But big players have many ways to make their products as secure as possible, like bug bounty programs as an example. Chrome/Chromium's security is well documented and actively developed. At least it's much better than using a web browser that most people have never heard of it and last updated in 2007.

Well, your decision is yours, so is mine. I don't consider using another kind of sandbox on top of Chrome is worth the risks and efforts.

 

Mandatory: https://www.cr0.org/paper/to-jt-party-at-ring0.pdf Local kernel exploits are pretty common, on Windows and other platforms.

But I'd also point out that application sandboxes don't matter much if we're talking about browser based attacks and data theft. Files accessible in the browser sandbox can be grabbed, input can be monitored, etc.

Ideally you want an attack to not succeed in the first place. EMET helps, as does Javascript and plugin whitelisting, and just staying up to date with patches; but when you think about it, pretty much every desktop OS is sadly weak on this front.

 

Agreed!

Yes, the O/S itself is weak in this area, but there are some options available in some browsers and there are some nice browser plugins/extensions for this purpose too.

 

There's some interesting stuff with how the system will cache API responses. I don't know the details of it on Windows, unfortunately, but it seems relevant to that attack.

@GJ,

Classic paper. One of my favorites.

 

Some people seems to have already forgotten the redundancy of using Chrome and Sandboxie together, since they implement the same sandbox (with Google's being superiorly configured without need for compatibility) under Vista+.

Sandboxie hardening is nothing special and can be implemented through other means. It has been discussed before, but the real life difference is virtually non-existent.

I prefer tools like EMET, HMP.A, MBAE, and WSA to protect Chrome, because they're much more usable and stronger for it and probably IE imo. Also, some of them have compatibility problems with Sandboxie, so obviously I choose the different kind of layer.

 

Same sandbox? I thought they were different (type A and type B)?

Since I have my eyes on AppGuard, based on your point of view, would you say that it's a good tool to protect Chrome or any other high risk apps, or redundant instead? Thanks.

 

Sandboxie 4+ uses lower integrity levels just like Chrome, unlike the kernel hooks it uses in previous versions (which works better on XP). You can search this thread for a lot of posts on this subject.

Probably a good tool for the system including Chrome, but I have no experience with that software.

 

Oh... you were talking about that one. Back in the days when I was still using Sandboxie I read some discussions which said version 4 will be a massive change. I didn't really keep up with the discussions. So that's what was being discussed.

From what I've known so far, it doesn't seem like a sandboxing tool. Not even partial virtualization. It blocks guarded programs from doing certain things based on policies. No idea if it's comparable with IL restrictions.

 

AppGuard implements
1. Memory protection of guarded aps
2. UAC/LUA like protection of windows & programs file and HKLM
3. Privacy limitations (reading updating folders marked as private) to guarded aps
4. Deny execute in user folders for all processes (anything outside Windows & Program Files).

Pretty hard to bypass since this are typical starting points of most intrusions. When you test it with Comodo tools it does not look strong, but AppGuard has a simple but effective strategy: intercepting the first steps in the chain of events of all (known) intrusion by exploits. Nice side effect it is very quiet, so it is obe of the few HIPS which could be used by larger audience.

 

I'm just afraid that AppGuard will be redundant if used with Chrome's security features.

I agree, although silent security feels pretty boring sometimes.

 

What is redundant? Which security features? Most of the things he listed can't be implemented by chrome alone.

 

If you are gonna talk about Sandboxie and integrity levels, perhaps you should read what Tzuk has to say about it.
http://www.sandboxie.com/phpbb/viewtopic.php?t=16967&highlight

Bo