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.

By the way, does anyone know if allowing direct IPC access can theoretically reduce protection in any way in the real world?

Click to expand...

tzuk said:

Theoretically, it depends... And in practice, it depends even more. Smile

What I mean is it primarily depends on the type of resources allowed by this pattern emet_pid_* and secondarily if EMET can be abused.

Suppose all of these resources are just event/synchronization/signal resources, which can only be signalled, causing the EMET program to wake up and notice something has occurred. Not much potential for abuse.

Suppose some of these resources are shared memory resources, then the program in the sandbox might corrupt the memory section and abuse EMET to some extent, but that also requires that EMET has vulnerabilities in parsing the data in the shared memory, for instance buffer overflow exploits.

So the bottom line is that it is really difficult to answer your question without extensive study of the resources and programs involved. But it is easy to say that anything is possible in theory.

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.

Click to expand...

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

Click to expand...

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.

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.

Click to expand...

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?

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.

Click to expand...

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.

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

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.

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

Click to expand...

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?

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.