[.07] EMET 4 compatibility

[DR_LaRRY_PEpPeR]

With the beta release of EMET 4 (and final May 14), the EMET template needs a small update in order for the EMET Agent (notifier) to receive notifications if EMET is triggered in a sandboxed program. EMET 4 uses a Mailslot instead of window messages. The Mailslot is named EMET_Agent_SessionID, so add the following:

OpenPipePath=\Device\Mailslot\EMET_Agent_*


BTW, in the EMET DLL, I see the string ...\EMET_Recipient_%u%u and in the sent Mailslot message, a Reply XML attribute, etc. So it's possible another Mailslot could be used for some other communication, although nothing I did showed evidence of that. But anyway, not sure if there could be a need for:

OpenPipePath=\Device\Mailslot\EMET_Recipient_*

As well. Or even simply \EMET_* *shrug*



AND... There seems to be another bug with 4.01 vs 3.76 (although it seems weird too), after I noticed it mentioned in this Wilders EMET thread about EMET not showing stuff as protected. Shouldn't be any problems with that (the current template's IPC is fine still), however...

I noticed that when using Run Sandboxed with IE (XP and 7 64-bit), the EMET DLL doesn't even get loaded! On Win 7 (IE 8 I guess?), the child iexplore.exe does get it, so again it seems like Start.exe is messing something up? This should NOT be specific to EMET, but perhaps any AppCompat mechanism is being interfered with...?

What's REALLY weird is that another program I was checking for the EMET Notifier (crashes with DEP), DOES get EMET loaded if I use "Run From Start Menu," but not Run Sandboxed -- aren't they almost the same?! With IE, nothing involving Start.exe lets EMET load.

Even weirder, in 3.76 (only checked on XP), EMET loads in IE 6 no matter what, but the other DEP-crash-testing program won't load EMET no matter how I do it -- from sandboxed Explorer, nothing...

So different random things seem to be happening with the AppCompat layer and Sandboxie...

Just found it. EMET seems to load from Run Sandboxed before 4.01.04, so I'm assuming it's related to the .04 change: Sandboxie ignores __COMPAT_LAYER setting (since it's AppCompat related). I was also going to ask about that __COMPAT_LAYER fix, since I'm not sure you preserved some manifest-related behavior I noticed (not sure it's important), but haven't gone back to check on Win 7 yet... (I had just been poking around with RunAsInvoker tricks, etc. a couple months ago before you updated the thread.)

[EMET_User]

Bump! This needs to be taken care of.

[EMET USER 2]

I'm still on 3.76

could you where i need to add "OpenPipePath=\Device\Mailslot\EMET_Agent_*" to emet 4 work correctly?

thanks

[DR_LaRRY_PEpPeR]

EMET 4 will still work correctly, it's just that if something triggers its protection in a sandbox, you won't see any notification about it without this additional new setting.

But anyway, that line is for manually editing your Sandboxie.ini file, and for tzuk to add to the Templates.ini file in a future release. To add the setting from the GUI, go to Sandbox Settings for whichever sandbox(es), and then Resource Access > File Access > Full Access. Then click Edit/Add and paste: \Device\Mailslot\EMET_Agent_*

Hope that helps, and sorry I forgot to include the GUI instructions in my first post.

[Sampei Nihira]

We must add the line:

\Device\Mailslot\EMET_Agent_*

new ver 4.01.06 ?

[Sampei Nihira]

Not present in template.ini file ver 4.01.06 sez EMET.

[Emet_lover]

No. Emet will not work properly. Emet.dll is not loaded if the browser is run through shortcuts or right click run sandboxed.

[EMET USER 2]

No. Emet will not work properly. Emet.dll is not loaded if the browser is run through shortcuts or right click run sandboxed.

What doyou mean, it looks like it load the .dll correctly

http://www.wilderssecurity.com/attachme ... 1366610409

[DR_LaRRY_PEpPeR]

Sampei Nihira, yes, still need to add the setting in 4.01.06, since tzuk has not updated the EMET Template yet. Again, this is only for notifications, which people probably do want to see, but should rarely, if ever, happen.

And the EMET DLL is loading correctly in that screenshot because it's with Sandboxie 3.76. The problem is only (generally) with Run Sandboxed/Start.exe shortcuts since 4.01.04, and is in no way related to EMET 4. It's a Sandboxie/AppCompat bug that probably affects any "Shim DLL" that should be loaded! My complete findings are in the second half of my original post...

[Sampei Nihira]

@ DR_LaRRY_PEpPeR

Ok, the same results for me.
Just changing the "start default....." with the name browser.
See at the image:


http://s24.postimg.org/hektqlnk5/Immagine.jpg

P.s.

DR_LaRRY_PEpPeR there's a solution for it:


http://www.sandboxie.com/phpbb/viewtopi ... c7539c82ab

[Guest10]

http://s24.postimg.org/hektqlnk5/Immagine.jpg

The .jpg file shows:
C:\Programmi\Sandboxie\Start.exe Opera.exe
but this cannot be correct.

Assuming that the "C:\Programmi" part is correct, then it should probably be something like:
C:\Programmi\Sandboxie\Start.exe C:\Programmi\Opera\Opera.exe
although I don't know the exact path to the opera.exe file.

You should allow Sandboxie to make a shortcut for you:
Sandboxie Control tray icon window > Configure > Windows Shell Integration
"Add shortcut icons" button.

[DR_LaRRY_PEpPeR]

Guest10, that shortcut is fine, IF Opera.exe is in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths or its folder is in the PATH env var, of course (I guess!).

Sampei Nihira, I tried that with iexplore.exe (it's in App Paths), modifying the Sandboxed Browser shortcut, as well as one created from Shell Integration > Add Shortcut Icons. While neither unmodified allows EMET to load, your modification DOES WORK! Nice find , and yet more weirdness...


BTW, I thought maybe it was an issue, running shortcuts through Start.exe, but no, as it still fails if I go to the Program Files folder and Run Sandboxed directly on iexplore.exe.

[Sampei Nihira]

Great news !!!
Alerts you of Wilders ?
My English is very bad.

[tzuk]

I looked into this today. EMET.DLL injects into forced programs, or programs that are not started directly through Start.exe.
For example run cmd.exe then use that to run iexplore.exe, and iexplore.exe will have EMET.DLL injected.
Or run Internet Explorer as a forced program, iexplore.exe will have EMET.DLL injected.

EMET is injected by the shim engine component, instructed by data below this registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags

From what I can tell the problem has to do with Start.exe itself not loading the shim engine component,
which might affect the program it starts. I have not researched this at depth.

[DR_LaRRY_PEpPeR]

Right. Again, this seems to go back again to what I was saying about Start.exe in 3.76 not allowing SRP to work (I never updated that thread, I found no evidence at all of problems you talked about 32<->64 bit loading)...

Simply, if Start.exe was started as a NORMAL program inside the sandbox (e.g. like cmd.exe example), OR another copy, with the program to start as an argument, it should all work absolutely fine. I cannot figure out why Start.exe does this weird-acting stuff when it seems to already start running in the sandbox...



Sampei Nihira, sorry, what about Wilders...? Yeah, I saw your posts there, and I check there when I check here usually.