DEP Tools/Permanent DEP: strengthen your DEP

I'm posting in this forum as part of "other ... system protection technology." If a mod thinks other software & services or something is better, please move of course.

I finally got my "DEP Tools" ready a few days ago. I guess not too far off my planned release on the 12th (I need to update that thread with what I found), considering the problems I found with Process Explorer, Windows 8 (especially!), adding a Safe Mode check (then removing it after testing), and finally adding extra manifest stuff to SetDEP for Win 8's silly Program Compatibility Assistant (which still seems to be doing something anyway).


Anyway, people should have system DEP configured as OptOut, at least. The Permanent DEP DLL can (should) be used on any version of Windows with OptOut (none of the Tools do anything with AlwaysOn/AlwaysOff). You basically get all the benefits of AlwaysOn with the compatibility and convenience of OptOut. Also on Windows XP with OptIn. If you don't know your configuration, running SetDEP will tell you (just double click).

I'd appreciate any feedback or comments! Especially any problems or complaints.

Page with all info: voidmain.realplain.com

 

According to Process Explorer, a bunch of DEP changed to DEP (permanent), but the same number of n/a remains. I guess it's working properly, since they're excluded (implicitely). Wish there's a way to force them to DEP, and exclude the ones that are definitely incompatible.

Anyways, I'm liking this tool, no issues so far with the added security. DEPTest did indeed pass without any failure.

 

Thanks for trying it out. Looks like there's been a handful of downloads so far...

Which OS are you using? You have to run Process Explorer with Administrator privileges to remove those n/a's in the DEP column. Then there should only be n/a on like the Idle Process and Interrupts (expected since they aren't really "processes").

Everything should be getting DEP (like before, just permanent) unless it's excluded for incompatibility.



Everyone: I forgot to mention in the first post (or on the page) that I was going to make a simple automated script or something to easily "install" the DLL -- it's a little tricky, but I should be able to include that in the next update... I figured it might be better to leave it as a "manual setup" initially where you have to edit the registry before shooting yourself in the foot (just in case, though I don't think there should be issues ).

 

Yes, admin privileges showed everything under DEP (even Idle), except for Interrupts. Running Windows 7 64-bit Home Premium.

Strangely, Process Explorer 15.12 showed some under DEP and others DEP (permanent), but 15.3 showed all of those as DEP (permanent). Is that what you mean by newer versions being broken?

Make sure the script supports multiple AppInit_DLLs values, NVIDIA edited mine.

 

Subscribed; as I can't download or install on a NMCI machine.

 

If I could make a recommendation, I'd suggest adding a small paragraph at the top explaining what it is, its purpose/why use it, and a screenshot. Right now I feel like I spent entirely too long reading the page with no understanding of what you're offering or why I might want it.

 

Thanks for the tip! Had no idea that running Process Explorer as Admin would get rid of those n/a's!

 

Sweet! Congrats on completing this project... can't wait to give it a look. Although Open EMET is really the one I'm eagerly awaiting, and has the potential to become a permanent part of my setup (and my sig), I'm looking forward to playing around with this as well and getting a sample of your work.

Well done : )

 

Nice program Larry. Does exactly what it is supposed to do... with no frills. Which is exactly the type of app I like. I admit I expected it to be quite rough around the edges... it being from a 1 man team and all and banged out so quickly. I'm really impressed with how polished it is. I expected to have a ton of things to nitpick about, but I just don't. You obviously did your homework first, and know what you're doing. Though I may find a few things eventually, or at least suggestions.

This really gets my hopes up for Open EMET now. I can just see it being the final piece of my XP Pro puzzle... and sig. The idea of an open source EMET, where everyone can contribute feedback and ideas to improve it. That doesn't rely on running on a bloated, glitchy, known to be vulnerable (in the past) framework to function, thereby eliminating pretty much all attack surface. Well... just makes me feel warm & fuzzy inside. I was hoping for something like this ever since first discovering EMET and realizing it required .NET FW. And now it looks like that dream can become a reality. Based on this DEP tool you created, I believe you can make it happen.

Major props to you! And I wish you God speed in completing this next project. It has the potential to be the best thing to happen to XP since Sandboxie. And could help extend it's useful life even past it's EOL, along with some good people at places like MSFN that will keep prodding and patching XP accordingly. Heck, some of them even still keep patching 98SE and keep it usable, in concert with the right 3'rd party software, hardening and usage. And now that XP's EOL is looming many are switching their efforts to that. It has a large fan(boy) base, and many won't let it die easily.

 

So, any further word about your Open EMET? I'm sooo looking forward to it, and even more-so after seeing how polished your DEP Tools was. I believe it would fill out my setup perfectly, even more-so than the now Malwarebytes Anti-Exploit, formerly known as Exploit Shield. I feel that yours would be lighter and with less potential for conflict. And have exactly what I want/need with no frills. Basically an open source EMET, lighter, with no vulnerable, extra attack surface required for it to run on. It would be the perfect thing to round out my setup, and sig.

I have it favorited and stop by from time to time to look for more info. But thought maybe you had something you didn't post about there to discuss.

I truly feel that whether it's your Open EMET, or MBAM's Anti-Exploit (new ES), it will be the best new security measure to come about since Sandboxie. And that it could increase XP's useful life beyond it's EOL, along with unofficial patches. Or better yet, have the EOL pushed back like a year as it draws near. I consider that a distinct possibility, with so many still on it (especially corporate).

 

Just noticed there's an "EMET Enhanced" version of the DLL, what is the difference? Is it for OpenEMET only?

 

Sorry I've been MIA for a while, but thanks for the comments. I have an idea about making that written-up-quickly information a bit better/clearer, and maybe a Process Explorer screenshot, etc., but haven't really touched the page again yet!

lucid, nothing about OpenEMET yet, sorry! Did you see the OpenEMET page? I'll update that when there's any update. I didn't get to start on it when I was thinking (but I've had WinAPIOverride open for over a month, while I wait to emulate EMET's AppCompat database stuff), so I still haven't touched a single character of code yet! And as I've been saying, I've never made a "full" GUI thing before, but I think I have a better idea now of how creation is simplified (with "Dialog" windows! ), so I hope that part won't take much time.



Yes, the "EMET Enhanced" Permanent DEP DLL update! I did update that before I wiped out the newer compiler on my other system... I also recompiled the Logging DLL just to make it 1K smaller (no functionality changed, just /GS-).

It doesn't have anything to do with OpenEMET (which doesn't exist anyway )... It's just another version I made to enable "full" DEP (e.g. disabling "ATL thunk emulation" like AlwaysOn System DEP or NX_COMPAT flag programs) in conjunction with EMET.

Simply, if "DEP" is checked in EMET, the DLL will treat the program like it has NX_COMPAT, even if it doesn't. That's all. From what I read, EMET itself used to do this in an old version (2.0 or before), until they decided to relax that (just plain, forced, permanent DEP), since a lot of [older] programs need that "ATL thunk emulation" part of DEP (e.g. stuff that doesn't work with AlwaysOn).

If something doesn't work with it, just uncheck "DEP" in EMET, since the DLL will then still do what EMET would have done anyway. I had to do that for WMP 6.4 on XP and the old MSN Messenger. Also with PowerArchiver (2011), which itself worked fine with "full" DEP; but then I tried to run WinSpy++ from its ZIP file, which triggered DEP! (Hmm, just noticed the same happens, extracted, from Explorer directly.) WinSpy++ is completely excluded from DEP (implicitly by Windows loader), but I'm not sure why the DEP state of the parent process is causing this... Oh well, I'll uncheck "DEP" for Explorer in EMET as well then.


"EMET Enhanced" is just a trivial thing I was playing with, but it's what I'm using and would use on any version of Windows. It works by checking the EMET_Settings environment variable for "DEP:1" This works because EMET has loaded and created the environment variable before the AppInit DLL, but EMET hasn't yet set DEP at that point (when testing logging, EMET seems to set DEP immediately after the AppInit DLL initializes). I think I only tested this with EMET 4 Beta, but I'm assuming it works the same with other versions (the EMET/DEP-setting order).

I think I've seen maybe 5 views of the source (which is why I haven't put up a full source package, with build/resource/icon files), but you can see in the Permanent DEP source where EMET_DEP_Enabled() is defined/called. If I knew it was that simple, I'd have included that version right away.

 

Kinda having trouble getting all this, but how is the "EMET Enhanced" DLL different from EMET Always On? I thought the point was to offer a good compromise between Opt Out and Always On, so how does the new "EMET Enhanced" DLL play into this?

 

XP Home 32 bit, loading PermanentDEP.dll and using "SetDEP.exe -a csrss.exe" as admin.

Process Ex shows all processes as DEP(permanent) except smss.exe and system at the very top - these two just show plain DEP.

Trying "SetDEP.exe -a smss.exe" as admin fails (was it meant to perdep anything you throw at it?).

The only thing that impresses DepTest.exe is to set boot.ini to /NoExecute=AlwaysOn (which incidentally now perdeps smss.exe but not system; the best I can ever get for System is plain DEP, whatever I do). In every case except "boot.ini ... AlwaysOn" DepTest.exe always reports unprotected.

I wonder about the usefulness of DepTest.exe, which seems to need to unpack itself afresh each time it runs, and run another prog OVERFLOW.EXE. On my system OVERFLOW.EXE only runs when boot.ini is set AlwaysOn, otherwise it doesn't really test.

My impression is that DepTest.exe just checks the value of "/NoExecute=" and automatically fails everything, unless it's set to AlwaysOn - which is a cheek frankly, if that's all it's doing!

Anyway, thanks for an interesting tool. Apart from the problem with smss.exe (maybe this is just an XP Home thing) if what Process Ex reports can be accepted at face value it appears to be doing what you promise.

Is there any other way to test it?

 

this is a great dll.

Only started looking into DEP more today.

So basically the default DEP config is not that effective, 64bit apps are always on for DEP, the config is for 32bit apps. 32bit apps by default if not set as alwayson are vulnerable to DEP been turned off by a flag?

But alwayson disables compatability settings as well as the ability to exclude apps that dont work with DEP.

Your dll sets permanent DEP status on 32bit apps so the optout setting becomes much more secure than it is otherwise, and also keeps the compatability settings in place.

to J_L as I understand it the EMET version of the dll stops the compatability overides from working when DEP is ticked for an app inside EMET gui. Which according to the dev makes EMET behave like EMET 2.x. I am using the non EMET version.

to buggy no that deptest seems to be genuine tests, they are taking advantage of that 32bit apps dont have the permanent dep status without alwayson or the permanent dll, when I run it with always on or this dll, some processes crash whilst running the test and it reports the system as secure against the test. So with this dll it reports the system secure in optout mode and would also likely work in optin mode if add the exe to the optin list.

 

Thanks for getting into this thread. It seems to have gone rather quiet.

What OS are you using? Does smss.exe show DEP(permanent) in Process Explorer? What does System show? I can only ever get just DEP for those two, no matter what.

I'm still not convinced DepTest is running tests properly on XP Home; maybe it does on other systems. DepTest reports no protection on my system even when Process Explorer says it's there. I can't square this with what luciddream, who runs XP Pro, is saying.

 

if process explorer says just dep, then it wont pass the test, as dep can be disabled on a running process. (32bit processes)

it needs to say dep(permanent).

the unbuggy version of process explorer (as mentioned by dev) 15.12 reports all 64bit processes as dep enabled, I believe all 64bit processes are always permanent dep status and dont have the exploit possible on them (even with alwaysoff on my system dep is on 64bit processes),

on 32bit processes, their status is determined by the option configured for dep (alwaysoff, optout, optin, alwayson) and if the dll is used.

without the dll they are vulnerable unless alwayson is used. process explorer will report dep but it wont report dep(permanent), it needs the permanent flag.

with the dll you should see (permanent) on every 32bit dep enabled process.

I had to exclude ftprush as that crashes with dep so this dll has helped me a lot. I deliberatly didnt use the emet dll as I wanted the compatability overides in place on emet enabled processes.

attached pics, and had to shrink/reduce quality dep1 pic to fit forum size limits.

My OS is win7 64bit SP1.

the dev also mentioned in his page if some processes dont show permanent then need to use the setdep program eg. for csrss he shows he has to use it on windows xp.

 

Yes, you seem to be getting good results.

On my system Process Explorer shows DEP(permanent) just fine on all but the top two processes ("System" and "smss.exe").

But when I run DepTest it says everything is unprotected. This why I question whether it's really bothering to apply the tests (or just jumping out because it sees a particular setting in boot.ini).

Is there any other way to test the DEP?

 

Hi Y'all,

This is Andreas from Sys-Manage.

Just to clarify things a lil bit. DepTest.Exe is a GUI that launches overflow.exe multiple times to test the possibility of executing code in different memory locations (stack, heap, ...) that are not flagged for code execution.

Before Overflow.exe attempts to execute the code it tries to disable NX for the current process, which is possible unless you used the AlwaysOn option. The API being used by Overflow.Exe to disable NX is ZwSetInformationProcess with the NT:rocessNxClass option. A smart shell code could potentially use the same method to disable NX for example by using a return to libc style of attack. ASLR might prevent this for example. There might be other possibilities.

DepTest.Exe & Overflow.Exe do not read anything from boot.ini or the windows settings.

If AlwaysOn is enabled you might see an error message saying "Overflow.Exe has stopped working" asking you if you want to debug it or close the program. This means that Windows has successfully stopped overflow.exe's attempt to execute code throwing an exception that in turn terminates the program. Please click on close and the next test will start.

You can launch DepTest.Exe and then navigate to the corresponding sub folder in your TEMP directory to get access to the overflow.exe file.

It has the following command line options that are working:
/A -> Dynamic Application Heap (HeapAlloc)
/E -> Dynamic Application Heap (HeapAlloc on an additionally created heap)
/C -> C Runtime Heap (malloc)
/X -> Static memory
/S -> Stack
/V -> Application memory (VirtualAlloc)
/R -> ASLR Test (Tests if addresses are randomized)

With /R I always get the error message that the stack is not randomized, maybe this can be enforced by the "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\MoveImages" registry setting or in some other way. I think this test passed on Windows 2003 + BufferShield + BufferShield ASLR enabled.

Unfortunately we stopped the development of BufferShield and the BufferShield ASLR feature is only available on Windows 2003, not even on XP. It was an early version of ASLR (one of the first for Windows) and only used 5 Bits. One of the reasons we had to stop the development was Microsoft’s marketing strategy to announce that they had a software version of NX for XP which they didn't. This has created the false impression that Buffershield is not needed on a PC that does not have NX hardware support. In reality Microsoft's software DEP did nothing but prevent one single specific exploit and not buffer overflows in general as Hardware DEP does. There is more info about that available on the web but at first even Microsoft engineers believed it. It took a long long time until the public realized what was going on there. You can read about for example on wikipedia (http://en.wikipedia.org/wiki/Buffer_overflow#Buffer_overflow_protection).

“Microsoft's Data Execution Prevention mode explicitly protects the pointer to the SEH Exception Handler from being overwritten”

But anyways, they have destroyed our market with it. We still don't know why they pretended to have software DEP, whether they did it because they were unable to do it, or whether someone (you all know who I mean) influenced them or maybe both reasons.

Hopefully overflow.exe can still be useful for something

Andreas

PS: Happy Halloween

 

If I get it correctly (from looking at the screenshot) you have successfully found a way with your DLL to have the possibility of excluding executables from DEP while preventing apps from turning of NX themselves. Congratulations!!

Stupid question: How can I use it? I have my OS in AlwaysOn mode but have one old app that won't run anymore.

 

Change DEP to OptOut. Then follow these instructions:

 

Larry seems to be using Home too via his signature, so I doubt it. I followed the same routine "J_L" posted directly above me, with success.

The likely scenario is the age old one... that all setups are different and what works on one will not necessarily on the next. The possibilities are nearly infinite. But it does indeed work and work well. I hope you can get it working too.

 

Thanks!!

Will try it right now....

By the way, how good is ASLR theese days. The last time I did read about it, ASLR was providing not enough entropy to be a serious protection (like 200-300 different addresses after running the same program 500.000 times). If entropy is so low and the attacked network has more than 300 PCs you can easily succeed if running the attack against many PCs. OK you will be discovered because a lot of them will crash but it is still possible. If on a 32-bit system 16-bit would be used for randomization it should result in 65535 different possible addresses.

Andreas

 

http://s8.postimg.org/lybd690id/Yeah_Yeah_Yeah.jpg <--- Windows7 x64 SP1

Looks good. Thanks a lot. Nice improvement! I don't like the idea that a process can turn off its own protection so easily and without a reboot, if I remember correctly some rational behind the possibility to let processes turn it off was compatibility they said.

The reason why I am asking about ASLR is that without proper ASLR it might still be possible to disable the security for example by libc returning to CreateFile overwriting the DLL or by libc returning into RegSetValueEx to make some registry changes or launching bcdedit to turn DEP off theoretically. There is limits on 32-bit systems so additional protection features are required like delaying attempts to start executables that recently crashed to slow down the process of brute forcing it.

Andreas

 

I codesigned it by the way so I don't have to set the RequireSignedAppInit_DLLs.

Here is a little tip (it was working in january don't know if it still does):
http://forums.realsoftware.com/viewtopic.php?f=21&t=42937