Application Sandboxes: A pen-tester’s perspective

I see you have got PRO versions, why not invest some time in Group Policy and Software Restriction Policies (plus EMET), combined with low rights Chrome sandbox you are save and secure with policy sandboxes (using default mechanisms of the OS only).

 

I have EMET 3.0 installed as I have not gone to latest full version of NetFramework (Client only). I'll check out Policies and my settings for Chrome .... Tnx for the advise.

 

Yeah, I feel the same way. It's like sandboxing a sandbox. No point doing so from my perspective anyway.

 

Is not the sandboxie more than protection, but also can be use to delete or try new softwares and to easily get rid of it and start over? Think of maybe something integrating to browser (on purpose) and then to remove is easy by delte the sandboxie?

Disregard any security but the sandboxie it can be used as more than the security.

 

You're talking about a different thing than sandboxing Chrome, and I've already covered those scenarios. You can easily run any downloads in Sandboxie, what does the browser have to do with that?

If you're talking about monitoring, there are better security software for that. If you're talking about keeping Chrome clean, use Incognito Mode (there's even a "--incognito" flag for startup).

 

Don't know about that (if you speak to me). From security aspect, putting chrome in sandboxie may not do much, but also incognito only cleans what tracks are there, but only to chrome. I think more like a good use for putting chrome in a sandboxie is maybe if you install some software, good example but not relevant is flash. It is used by the chrome (or chromium or other variant) but incognito will not flush the tracks of it, while Sandboxie would flush.

Maybe not need to have chrome sandboxie in that examples, but point is only that if chrome not needing a sandboxie to be good, and the problem is not great of putting it in a sandboxie, then there are features of using the sandboxie that chrome don't have all by itself.

All that of course, if you speaking of me

 

Sounds good, but that basically means testing your installation of Chrome with plugins and whatnot. Personally, I don't do that (definitely not regularly), because it's my everyday browser. That makes it less convenient, which is one of the main reasons I chose it.

If I need to test something with Chrome, then it's sandoxed PortableApps or virtual machine to the rescue. If exact settings are needed, I sync my account.

From your message, I assumed you meant the usual sandboxing Chrome by default. It appears I was mistaken, sorry if it offended you.

 

No offense. Only meant to say, that perspective of no point "sandboxing a sandbox" one can also forget, that might be the idea. Because chrome offers process segregate, even though parent is high, it still works in sandboxie. But sandboxie offers ways not available without imaging like returnit or shadow defender to clean up mess or not like HIP, where control what runs. Of course, system should be in the clean state but even then, the sandboxie has many things it could do that make it more than "one tricked poney!"

I use it in many ways and also part of security, but not all your eggs have to be on one basket they said.

Aslo, you say "testing your installation of Chrome with plugins" but you mean what? I find that chrome is on the system, to use in the sandboxie and out. But when used in the sandboxie, cleaning up of it is easy. Test a plugin yes, you can do so in the sandboxie. But also if plugin is in system, it shows up in the sandboxie, if it has been cleaned. Some tricks to know how the sandboxie works, but understand how the why does, and it is a busty program, but not maybe best for only one trick

 

Due to holiday completely missed the outcome of this (with a lot of trumpet noise) announced US black hat scoop, http://blogs.bromium.com/2013/07/27/the-final-sandbox-fail/

Anyone?

Asking because of partial pass, see pic. In 2010 was AppLocker passed (hole designed by Microsoft, so no breach, now patch available) and ACL saved the day, now it was the other way around (Chrome's open download in Chrome seemed to bypass ACL, SRP stopped invoked processes from user space).

 

Agreed,that's why the likes of SBIE are a more practical solution than HIPS for most folks.

 

Well, if the same user allows direct access to anything and everything then Sandboxie would be next to useless as well. Such users are better off with products which don't have much customization options.

 

https://www.youtube.com/watch?v=SA0SbGaEFx0

You all might enjoy what's going on around 36:00-37:00ish.

None of this is new. At all. But these guys demonstrate it, which is nice.

 

Yeah, as you said, nothing really new. This isn't really something to be worried about IMO since you can just sterilize the sandbox before doing any important activities, so the loggers can be wiped out along with everything that is being trapped inside the sandbox.

Instead, I'm worried about if the hackers exploit the sandbox itself to bypass it so they can gain access to the host OS. I've never heard about such thing, and I'm not even sure if it's really doable. But if it is, then we can bypass it while the users are still fall asleep in their invincible sandbox fantasy.

 

Sterilizing the sandbox won't matter. He demonstrates that you can easily and generically bypass sandboxes, because sandboxing on Windows is, for the most part, a joke. The only people who manage to *not* suck at sandboxing, Google, can only do it because they have hundreds of millions poured into Chrome security.

As you say, users have this "invincible sandbox fantasy", which is very true. People think "Oh, I'm sandboxed, my program is isolated from the system" when, in reality, programs are not nearly as isolated as they typically think.

I did like that he gave credit to Chrome's Linux sandbox though, as it's probably the single most powerful sandbox in use publicly.

 

@Hungry Man

You know, that reminds me about something. A few months ago I argued with someone in another forum about web browsers security. I said that the modern IE is more secure than the previous versions, especially since it has a sandbox too. But then he said it doesn't matter much because Windows integrity level is not really good, and suggested that Firefox and Chrome are better. Also, he said Firefox and Chrome work even stronger in Linux since Linux has a better security model than Windows has.

I didn't continue the discussion since my knowledge about this is way too limited. But this makes me think: no matter what you do, if you're using Windows, you're screwed. What would you say about it?

 

Chrome has the best sandbox on Windows. IE11 is next up. Both are fairly secure, definitely for the average user.

Linux sandboxing is far far better than Windows. All of the talk of kernel exploits stops mattering on Linux, because the kernel attack surface from an attackers place in the Chrome renderer is tiny by comparison to Windows (you can't make any system calls or interact at all with the kernel, plus 0 read/write access). Suddenly the path of least resistance isn't the kernel (at all, if you harden it) and it's back to having to exploit the broker, which, as the speaker states, is very difficult (tiny attack surface, very well vetted.)

On top of that you can sandbox the broker process, which means an attacker needs a kernel exploit *and* a broker attack, as opposed to windows where something like Sandboxie actually provides little as the path of least resistance (kernel exploitation) bypasses both generically.

 

But that's the complete wrong thinking for sandboxie-like sandboxes. They aren't build to isolate programs in the sandbox from the system, they are build to isolate the system from programs in sandbox (or clearlier said to restrict programs in the sandbox)

Knowing that, many of the discussed things here are nothing new. If you have a keylogger on system, yes i can even log things in sandboxie. If system kernel is exploited - nothing that runs on windows is secure from that.

Main point: such attacks need access to real system first. Otherwise it are only POCs.

 

That is exactly what is being said - Sandboxie and other sandboxes are not restrictive, and therefor your applications within the sandbox are given significant rights to content outside of the sandbox, making post-exploitation easier, and making general exploitation easier. In other words, they do not perform the test of restricting programs to the extent that is necessary for any significant security.

This is a poor main point because everyone (like the guy demonstrating exploits against all of these sandboxes) already knows that these attacks work, real systems are irrelevant.

 

Do you mean as explained here:

-http://blog.chromium.org/2012/11/a-safer-playground-for-your-linux-and.html

..and here...

-http://dev.chromium.org/developers/design-documents/sandbox -> (Linux Sandboxing)

Linux is providing my simple needs more than adequately, and this mint xfce 15 release has been running incredibly stable as well I don't know what more I would need to do for browsing security with this setup hardened with AppArmor and UFW outbound port restrictions, and javascript domain restrictions. I'm content with it.

 

Yes, though the Chromium documentation is not super detailed/ updated for seccomp, but it is the seccomp-bpf filters that make the most significant difference for Linux (though absolutely not the only difference). Seccomp addresses the most critical issue that faces sandboxes.

You may want to look into adding the flags:
--enable-strict-site-isolation
--site-per-process

Site isolation is not feature complete, and a few sites may break (I personally only had one site break, but I decided to disable it), but if you set up a chrome banking profile it may be something to look into.

 

Very good, thanks!

 

I think I wasn't clear enough. Yes the bromium study is very interessting but at all nothing really new and nothing to damn sandboxes at all. (Thats what i wanted to say)

The bypass (via exploit) issues:
...are at the end mostly design issues of windows. Especially in kernel mode: no application that runs on windows will ever be able to really protect the system if kernel was accessed via exploit, most not even the kernel exploit can be blocked.

The Leakage issues:
Keylogging, Data Reading, Data Sending...
That that is even possible with sandboxes (and can controlled a little bit through extra settings) is also not really new, though many seem to ignore it. But if the Sandbox is cleared regulary, this mostly happens while runtime and not permanently. And yes, the poor thing is that damage while runtime is often enough.

But after all: Yes Sandboxes are far away from bullet proof, but nevertheless they provide some extra protection and you are better with than without.

 

From my pov, the report brings to light two significant facts which Hungry Man already mentioned:

1. The Linux kernel's interface functionality reduces its attack surface far better than the Windows kernel.
   
2. Chromium's sanboxing technology, although specific to its browser application, is superior to others, and it's further enhanced when used on a Linux platform that supports the sandboxing filtering (v =>3.5 & backported to Ubuntu 12.04)

 

True, it really is nothing new. It is somewhat damning, in that sandboxes in their current state are not providing much, but, if implemented properly the paper does show that they can be of use.

 

Does all this mean that Shadow Defender is more secure than Sandboxie? Just wondering because Shadow Defender is not an application sandbox.