Sandboxie 4.02/4.04 not fully compatible with EMET 4.0

[dismaze]

OS:Windows 7 32 bit

Sandboxie Version:4.02/4.04

Problem:When use Sandboxie's right click button to start any program, even the program is under EMET list, EMET.dll still won't be loaded, but if let Sandboxie open Windows Explorer first, than open the program, EMET.dll will be loaded properly. The problem is the same as http://www.sandboxie.com/phpbb/viewtopic.php?t=15260

Also even add SandboxieDcomLaunch.exe, SandboxieRpcSs.exe to EMET list, EMET.dll won't be loaded, they will not be protected by EMET; but SbieCtrl.exe, SbieSvc.exe is ok, will show they are protected by EMET, that make me confuse.

Please take a look of this problem, thank you.

[tzuk]

In that topic that you linked I did fix (at the time) the same problem that you are describing here.
But I can check again specifically on 32-bit Windows 7.
Can you quote a specific version number for EMET ?

[dismaze]

OK, EMET version number is 4.0.4913.26122.

[nsb]

regarding google chrome, sandboxie prevents the injection of emet.dll within the memory space of the parent process.
The injection of the dll is instead allowed correctly for its child processes.



EMET 4.0.4913.26122
Sbxie 4.04
OS: 8x64

[nsb]

Hi, tzuk:
i observ the same behaviour even in the case of IE 10 where infact the dll is injected only within the slave (child) process..

[DR_LaRRY_PEpPeR]

Of course the child processes get it OK. Start.exe is not involved in starting them, which seems to be the problem!

Hasn't this been the case each time there's an issue...?

[tzuk]

I looked into this and I can see the problem, but I don't know if I am going to fix it.

The thing is that I want to prevent the "application compatibility layer" DLL (AppHelp.dll) from loading into Sandboxie programs like Start.exe because if one mistakenly sets the option "run this program in compatibility mode for another versions of Windows" then it introduces strange problems in Sandboxie. This has happened in the past.

On the other hand, EMET is relying on that DLL to inject itself into programs, and therein lies the problem, because Start.exe does not load the AppHelp.dll.

Now one kind of fix is to run your browser as a forced program and then Start.exe is not involved and EMET DLLs are injected correctly, but I understand not everyone uses the forced program feature.

So a possible workaround is to create a special shortcut that uses an intermediate program. Right-click New > Shortcut on the desktop, then paste:

Code: Select all

"C:\Program Files\Sandboxie\Start.exe" explorer "C:\Program Files\Internet Explorer\iexplore.exe"

So you're getting Explorer.exe to launch Internet Explorer (or whatever browser) and Explorer.exe will load AppHelp.dll and will inject EMET into the new process it is starting.

Hope this helps.

[blasev]

thx for the fix, confirmed to be working on chrome + emet 4.0

[nsb]

Following your hint, everything works as expected.

I was wondering though if it is an expected behaviour that explorer.exe is terminated automatically after a short time frame...

[tzuk]

Yes, sandboxed Explorer.exe will do that.

[nsb]

txs a lot, Tzuk!

Although applying the workaround it fixes the problem related to the browser, the problem remains in the case of downloading a pdf file.
Even if the player is emetized, Sandboxie prevents the loading of the dll inside the memory space of the reader...

[ssj100]

I looked into this and I can see the problem, but I don't know if I am going to fix it.

The thing is that I want to prevent the "application compatibility layer" DLL (AppHelp.dll) from loading into Sandboxie programs like Start.exe because if one mistakenly sets the option "run this program in compatibility mode for another versions of Windows" then it introduces strange problems in Sandboxie. This has happened in the past.

On the other hand, EMET is relying on that DLL to inject itself into programs, and therein lies the problem, because Start.exe does not load the AppHelp.dll.

Now one kind of fix is to run your browser as a forced program and then Start.exe is not involved and EMET DLLs are injected correctly, but I understand not everyone uses the forced program feature.

So a possible workaround is to create a special shortcut that uses an intermediate program. Right-click New > Shortcut on the desktop, then paste:

Code: Select all

"C:\Program Files\Sandboxie\Start.exe" explorer "C:\Program Files\Internet Explorer\iexplore.exe"

So you're getting Explorer.exe to launch Internet Explorer (or whatever browser) and Explorer.exe will load AppHelp.dll and will inject EMET into the new process it is starting.

Hope this helps.

Sorry for potentially hijacking this thread, but I was wondering whether this workaround would also fix this issue?:
http://www.sandboxie.com/phpbb/viewtopic.php?t=15797

[tzuk]

No, you're talking about injecting using Win32 hooks, EMET is injecting using the Windows compatibility layer.

[dismaze]

Thanks for the workaround. But, I know it is difficult, I still hope one day there is a normal way to use EMET 4 with Sandboxie 4 without using other workaround.

Also can you please take a look of Malwarebytes Anti-Exploit？It has a similar problem, too.

The three products both have ability to protect user from zero day exploit, if user can combine these together, I think it will very effective to defend bad things from web.

[dismaze]

Run a browser under Sandboxie directly(without open Windows Explorer), HitmanPro.Alert can inject it's hmpalert.dll to the browser or any other process, that's really a surprise.