Hello,

Recently I've been looking into Microsoft EMET 2.1 and it seems a rather interesting way to hardening software or enable permanent DEP/SEHO/ASLR on apps that can work with this. I know not every file/program is compatible with forced DEP or ASLR and such, but its a bit of trial and error to find out which app work correctly with EMET.
EMET 2.1 does support 32-bit and 64-bit of windows. And I believe only windows vista and up do support SEHO / ASLR.

I'm using windows 7 64-bit myself (fully updated).

more info about Microsoft EMET 2.1 at :
http://www.microsoft.com/download/en/details.aspx?id=1677#overview
http://rationallyparanoid.com/articles/microsoft-emet-2.html

Anyway I was wondering if the processes from sandboxie, SandboxieRpcSs.exe and SandboxieDcomLaunch.exe, would benefit or be 'hardened' by enforcing EMET on those sandboxie processes.

Does anyone have some experience with Microsoft EMET 2.1 and using EMET on Sandboxie processes or on the service (sbiesvc) ?

Anyway, if anyone has any comment about this, it would be very much appreciated. thanks

Please see this topic and what Tzuk has to say about it in the end

Thanks Digit@l for the link.
As I understand it, it would be more beneficial for programs running inside sandboxie, for example firefox.exe or maybe older versions of IExplorer and other legacy programs and such.

Thanks for the pointer. As I also see it, if doesn't really help in this case, would it then hurt to use EMET anyway ? if anything runs stable with the enforced settings that is.

Anyway, comment is much appreciated and I just looking for as much security as humanly possible.
And I didn't mean that SBIE would be needing this at all, it is a great app on its own, I agree.

^^ my last sentence here above contradict itself it seems, just call me paranoïd.
I've read the entire two pages and read Tzuk's comments about flipping a bit to enable ASLR would work in 32-bit but not as much in 64-bit due to memory allocation and it requires some work to make it work.
Also I understand that this wouldn't really needed to be enabled at all.
Anyway, I just enable EMET settings on apps facing the internet and see if it keeps running stable. But I leave SBIE as is.

I use EMET as a shortcut interface to enable/disable DEP, but not really much else. I found ASLR to be problematic with some programs I use, bringing the system to freeze completely with no solution but a hard reset - everytime. Enabling it for some while not for others completely defeats the purpose of using it in the first place, so I don't really bother.

ASLR is also no panacea against buffer overflows since it doesn't magically improve a pile of shitty code into a stable secure program - so it always recommended to use actively updated software that has a low number of security advisories. Microsoft's implementation of ASLR so far is half assed (something they intend to improve in Win8) in the sense that its not random enough especially for 32 bit versions of the OS.

If everything runs stable then ok go ahead and enable it, although it must be noted that there is a difference between having native ASLR support and between forcing a DLL to just comply.

Microsoft's ASLR is not half assed. It's actually better than both Ubuntu and BSD. That said, there's no way to fix 32bit ASLR it's like asking you to pick a random number between 1 and 3 and complaining that 2 comes up a lot, with 64bit its' more like asking for a number between 1 and 1000, the prng doesn't need to be good with so many choices. (oversimplification.) ASLR on 64bit is very effective. On 32bit it is decent, but it is lacking. EMET actually increases randomization with (a) mandatory ASLR (b) BUR

ASLR isn't a panacea... nothign is. It's incredibly effective. I'd much prefer ASLR over patches (this is reinforced by most obvservations in Linux servers that use admin-compiled PAX kernels and stand up when side-by-side the same systems running patched but non-pax kernels are compromised.)


If I enable ASLR for (example) Firefox but not a binary java plugin it defeats the Firefox ASLR. If I enable ASLR for Firefox but not my IM client, it's irrelevant, ASLR in Firefox will remain intact and effective.

TC, if you force Firefox to use Mandatory ASLR via EMET, when you inject Sandboxie into Firefox it should also be randomized. Therefor Sandboxie doesn't actually need to be forced itself as long as Firefox is. I would highly recommend you force any internet application, whether sandboxed or not, to use EMET.

Maybe I should have qualified my previous statement. I understand that the address space of a 32 bit system leaves much less room to maneuver when randomizing DLL locations, but what makes the problem worse on Windows is Microsoft's insistance on leaving large contiguous blocks of free memory for program use. This is also the case currently on x64 systems which limits the potential randomness that they could take advantage of. Its a trade off in secuirty for performance and stability gains, which is understandble but leaves more to be desired. In windows 8 they'll have the: High Entropy ASLR which is supposed to take care of this though.



Ok so it might be worth it after all I guess. Its always the damn plugins that bring down the security of the system.

Usually, yes.

Java was a bit of a poor example actually, Norton toolbar is a much better example. Java has to be called/ loaded whereas toolbars are loaded on program-startup. Java also has a separate address space so I really don't know why I picked it for an example lol

I think ASLR is always worth it. The reason being that (using the Norton example) even if Norton toolbar is coded perfectly without buffer overflows it won't matter. Firefox could have a buffer overflow and then (instead of injecting code straight into address space and executing, defeated by DEP) the Norton code could be used to construct ROP. This is only defeated (currently) by ASLR, though there are compiler options to create what are known as gadgetless binaries, which aren't currently adopted by any program that I know of.

Essentially, regardless of coding, there is the potential for ROP. The implications of that vary on what's made available and what the program does etc.

Thanks D1G1T@L and Hungryman for the elaborate discussion and/or difference of opinion, if any.
I appreciate this extra insight into the working of ASLR and other 'hardening' enforcement techniques.

I think I'll stick with Hungryman about only using emet enforcement on apps facing the internet (firefox.exe, plugin-container.exe) and/or java (if any). I mean being sensible about which executables or services would actually benefit and not just randomly enable emet enforcements of DEP/SEHOP/ASLR on everything.
I think both of you are saying, more or less: "Use it but don't overdo it or think hard about enforcing dep/sehop/aslr on anything as it might even disrupt the system or crash it."

Thanks guys . appreciate the comments.

I made these screencaps for another forum awhile ago to show what is running with EMET on my computer.

I've had no problems...fyi

Thanks BoredNow for your list in EMET.
Indeed quite a list. I have added lsass.exe and firefox and plugin-container, iexplorer.
Also I've set the DEP on opt out instead of always on.
Again I'm not sure if it is okay to set DEP at "always on". It's just my own thought about it, maybe unjustified, because you have no problems with it.
I might be a bit too much pre-cautious or reserved about running the maximum security settings in EMET.

I appreciate your input and perhaps I just have to try it, its just me that is reluctant towards trying it
Thank you !

I would suggest Always On.

Pretty much no programs break from DEP always on. Only old ones designed for XP that haven't updated in ages.

If you leave DEP to anything other than Always On you open yourself up to attack. Using "SetDEPPolicy()" an attacker can disable DEP in an exploited program.