Running a web browser under EMET + Sandboxie protection

How many of you run your web browser (or other apps) under the protection of both Sandboxie as well as the multiple mitigation methods of Microsoft EMET?

I am having a hard time finding solid information on if Sandboxie is truly, fully compatible with EMET, without risk of either of the two interfering/degrading each other's protection. I know they added some sort of compatibility settings in Sandboxie, but I am still not so sure.

Please take note that I am NOT talking about adding Sandboxie's exes to EMET's list; rather, I am talking about running a web browser (or other app) under EMET plus Sandboxie.

Thanks!

 

Hopefully this answers your query; it comes from Sandboxie developer himself:

Source:
Sandboxie Forum - Topic: Emet

 

Thank you!

I am not sure what he means by "IPC access", and I sort of getting what Tzuk is saying, but it is inconclusive.

What I want to know more is:

A) Are there a lot of people here that use EMET + Sandboxie?
B) Is the compatibility thing Sandboxie applies for EMET meant to fully cover the bases?

Furthermore, the conclusions I want to be able to draw from this are:

Is EMET's protection...

A) Best applied for apps you are NOT going to sandbox
B) Able to safely be applied to apps you will sandbox

I hope enough info existed to be able to draw those conclusions with decent certainty, but I am having trouble finding such data.

 

EMET + Sandboxie for me is a situation when less is more

 

"A lot" I doubt, but I do and dont have any problems. See my sig.
I am nonsavvy, I do try to protect my system, but I dont understand in depth.

Best Regards

 

I think you're having trouble finding data because there's not much out there. It doesn't appear that EMET has been tested in depth to see if it can be exploited/bypassed. We don't know to what (if any) extent EMET itself presents an attack surface. I'm not knowledgeable enough to have an opinion (well, not an intelligent opinion ). I do use EMET. I don't use SandboxIE, but not because I fear they are incompatible.

 

IPC = Inter Process Communication and there's a whole lot more to it.

a) I used to. All of my Sandboxie programs had EMET.
b) Yes.

Basically, if you think something is worth sandboxing it's probably worth using EMET on it as well.

 

I dont agree with you. EMET + Sandboxie is just adding more ways to have your defense broken ( IPC acess).

And remember if something bypass Sandboxie protection , it will probably dooms EMET anyway .

What is the point in adding more complexity in security setups? I see a lot of this in Wilders members , keep it simple folks.

( Sorry for my bad english , it is difficulty to a non native depict some things ).

 

I agree that keeping it simple is important.

IPC is not so simple - it's not a single thing. There are many types of IPC and ways that processes interact. Tzuk mentions this so I won't elaborate and I'll just refer to that post.

There are "dangerous" applications on computers: the browser, its plugins, maybe some other internet facing programs. These applications are dangerous because they can be exploited remotely and used to drop payloads or infect the computer through other means.

EMET is a means to break exploits, Sandboxie is a means to protect the computer after exploitation. There's no overlap here, they work very well together. There is a potential danger in allowing access to EMET but it's not clear what that danger is or how severe it is.

Unrelated, would installing EMET to a sandbox (in this case the browser sandbox) eliminate the need to allow access? I would think so.

 

IPC like you said isnt simple . If you have Sandboxie a exploit probably wont affect you , so you dont need EMET in sandboxed applications in first place.

So my recommendation is to use EMET in softwares that you wont sandbox , because of the IPC acess risks.

 

Like I said, both EMET and Sandboxie are "made" for at-risk applications. Saying to use EMET on applications that you won't use Sandboxie on really means you won't be using EMET for anything it's supposed to be used on.

The risks of IPC are that EMET could be exploited through the access. This is not a big deal because we haven't ever seen EMET exploited in the wild.

What's a much bigger deal is that Java absolutely can be exploited in a browser sandbox. This is something EMET is meant to prevent.

It's all about the complexity of the exploit. I mean - what if Sandboxie gets exploited? You're definitely adding a hefty amount of attack surface with Sandboxie - it's absolutely complicates the security model of Windows.

But we weigh the risks of having multiple processes and dlls injected into our programs with the fact that Sandboxie really isnt targeted and it's a simple decision most of the time.

EDIT: And if installing EMET to each sandbox negates the need to allow access to EMET the point is moot.

 

I use EMET + Sandboxie combination on all of my browsers. I think both applications complement each other and can be used together. There are no known ITW exploits that would break out of sandbox because sandboxed apps are under EMET's protection.

If/when that happens, I will remove EMET's protection from those apps.

 

I don't have access to a Windows computer right now - if someone would test whether you can install EMET to a sandbox and avoid this problem entirely I think it would basically put an end to the conversation, right? No IPC to worry about.

 

My habits: 98% browsing with Sandboxie. The other 2% + Outlook(not SBed) and other possibly internet facing apps or plugins will will have to do with the rest of my protection including EMET. How can I benefit from installing EMET Sandboxed - if that can be done?

Best Regards

 

If you have a sandbox for your browsing you could install EMET to that sandbox. This way you get the benefits of EMET but without worrying about IPC to an unsandboxed process.

You would have install EMET to every sandbox you wanted to use it in.

 

That would be a bit inconvenient for me and probably many others, considering I am usually willing to go to great lengths for security.

It seems the two currently viable implementations to this right now (until Tzuk releases more information) are:

1. Safe rather than sorry
Ultra-risk programs like web browsers get forced to run in Sandboxie. Sandboxie, even now on 64-bit machines, can offer almost 100% isolation from the real system and therefore is much, much stronger than what EMET tries to do. The different isn't even comparable. You theoretically don't need EMET for Sandboxie'd applications.

For high-risk programs, such as instant messengers and Microsoft Office type of stuff, that may be akward to sandbox every time and is probably not necessary. Using EMET on those would be a great way to use the tool.

2. Going all out and taking a risk
All high and ultra-risk programs are added to sandboxie and EMET's protection as well. At this time, it seems that no one, not even Tzuk, can say with any level of certainty what the possible risk(s) are in doing this, which is why I will chose at this time NOT to do it. I am not advising anyone on what they should do; but I have just reviewed the evidence (thanks everyone) and made a personal decision and made it available for all to read.

Additionally, except in rare, (probably long yet to exist) situations, applying EMET mitigations for apps always run in a sandbox is like building a solid metal iron wall with a force-field (sandboxie), but then inside that putting a wooden fence...you decide.

I will say that if you do not use forced programs or do not use discipline and ALWAYS run ultra-risk stuff sandboxed, then obviously you'd want EMET and/or other protections running when your browser is not protected.

By sandboxing ultra-risk applications including the browser, java, and adobe, you should be safe. Then use EMET on things like Skype, OpenOffice, etc.

EDIT: I thought of another analogy...

It's like having a high-quality air purifier that uses a True High Efficiency Particulate Arrestor filter (99.97% efficiency at .03 microns,) and then after that filter, putting an as-seen-on-TV David Oreck electrostatic plate behind it and expecting that to help with dust.

 

What would be inconvenient about it?

As for (1) there are weaknesses in Sandboxie. You can lock it down, which solves most of them though but if there's a kernel exploit that may or may not be enough - it depends on the exploit and what it does.

Skype and Office are two things I'd want EMET'd and Sandboxie'd.

But to each their own - I personally don't mind having the IPC to EMET. If there is ever a time in which EMET is exploited I will simply put it into the sandbox with the program I wanted EMET'd.

In fact you can probably just copy/paste the EMET.dll into the root of the program and it might load it up on its own.

 

For me, the choice is based on which of these tools comes 1st in your priority. If Sandboxie comes 1st, then most likely you wouldn't use EMET in junction with your sandboxed programs. If EMET comes 1st, then naturally you wouldn't mind using the combo together. If both plays an equal role, then you wouldn't even need to think...

 

Fully agree with you , good analogy

 

Meh, I guess to each his own for sure. HungryMan is wise - he knows what he's doing.

@HungryMan: So it seems you take the extra mile secure approach of sandboxing+applying EMET to not just internet apps, but frequently exploited apps?

- - - - - - - - - -

On a different note, has anyone tested/tried using EMET's application configuration to bypass the system-wide configuration?

For example, SEHOP and DEP are causing an issue with program X. So add program X and uncheck it. Will that turn those off even if DEP and SEHOP are set to Opt Out?

In the past, when I've had issues with DEP and a program, doing the above did not work. I still had to go into the Windows DEP in Control Panel/System/... and add an exception there.

 

I EMET anything that connects to the internet at any time, even if just for and update.

When I was using Sandboxie I used it for most of my programs.

EDIT: And no. If you uncheck the DEP box in EMET for a program but DEP is set to "Always On" or "Opt Out" the program will still use DEP (unless it is built not to.)

 

To me, that is something that needs to be definitely reconsidered for a change.

What is the point of being able to uncheck it if it's not going to disable it? Why do they make us keep a separate list of DEP exclusions in the Windows system settings instead of being able to have all our application mitigation configurations in one handy list in EMET!?

Afterall, that is kind of what the application configuration is for...turning on/off the separate mitigations.

Obviously, if you have DEP set to "Always On", that will override the ability to make exclusions, so in that case it would make sense. But for "Opt Out", as the name implies, applications should be allowed to be manually opted out.

What about for the other mitigations? I am assuming that unchecking SEHOP and the other ones will disable them for the selected program?

 

No.

The system settings are entirely separate from the forced settings.

 

Well then, they need to reconsider that. You should be able to toggle the system settings for applications individually using EMET, unless of course you set it to "Always On" or "Always Off", which in that case to be intuitive, it should gray the checkbox out. Very disappointed they have not implemented that.

To me it seems completely buttonine to go through the trouble of making a wonderful GUI like EMET to configure all mitigations at once, but then have only certain ones be toggle-able.

 

In terms of application settings you can either:
1) Force the application
2) Not force the application

in the case of (2) the application defaults to the System Wide settings.

There's already a way to disable DEP per program.