SpyShelter 5.02

I am not sure. Wouldn't this apply to every security software, including Sandboxie?

Best regards,

KOR!

 

The ASLR issue with SpyShelter was one reason for this post, but there are several other shell extensions without ASLR. Just to name a few: 7-zip, DropBox, ...

If you want to check on your own system: start Process Explorer, select explorer.exe, set the lower pane to DLLs, add column ASLR and sort on column ASLR. Every empty entry for the ASLR field is a DLL without ASLR.

 

Would implementing EMET to overcome this problem cause a conflict with SS?

 

I don't have a Sandboxie shell extension on my system, but the Sandboxie control process is running with DEP but without ASLR.

 

You would have to implement EMET on explorer.exe and every application that potentially loads this shell extension.

It's easier to add the ASLR flag yourself, for example with my setdllcharacteristics tool http://blog.didierstevens.com/2010/10/17/setdllcharacteristics/
Or you can also configure the SS to disable explorer shell integration.

Anyways, I've informed the folks at SS, fixing this is trivial, unless they do something funky that doesn't support ASLR.

 

Thanks from all of us SS users for the trouble you took to report it to SS

 

Thanks for your blog Didier. I just checked a few systems with process explorer and noticed that Kaspersky IS 2011 loads 3 dll's without ASLR and SuperAntiSpyware also 1. It's a pity that so many security companies ignore these defenses, even when they are already built into Windows.

 

Did a test and this doesn't work. Apparently, when you disable this setting, they don't deregister their shell extension, they just don't show it in the context menu.

If you want to check yourself, here's an howto.

 

They acknowledged they received my report.

 

Then would we have to unregister the .dll they are using for the shell extension?

 

your blog is an eye opener
the question is should I uninstall spyhelter before they fix the issues?
and any other additional security software that have the same issues?

sry for the noob question

 

If you don't need it, you can do that. One easy way is to change the name of the dll in the registry. Then if you want to temporarily reactivate it, you just have to change the name again.

But if you need this shell extension, you can set the ASLR flag on the dll yourself. See above for a link to my tool to do this.

 

That is a question I can't answer for you. You have to ask yourself why do you use these security tools?
Is it to protect your machine against common malware? Then no, you can keep these tools, AFAIK, there is no common malware in-the-wild that uses these non-ASLR shell extensions for ROP gadgets.
But if you use these tools to protect your machine against all attacks malicious hackers can throw at you (highly targeted attacks), then yes, you are better to disable these shell extensions.

And another option you have is to add the ASLR flag yourself, with my tool I posted a link to above.

 

thx for the advice
I did try that tools of yours, but I can't barely understand on how to use it . I'm still a novice. hmm i must learn a lot more

 

No problem.

It probably failed because you tried to change the flag while the DLL is in use (loaded in explorer.exe).

Do the following:

1. start regedit.exe in elevated mode
2. Search for SpyShelterShellExt.dll
3. Rename it to SpyShelterShellExt.dll.disabled, for example
4. logoff / logon
5. start cmd.exe in elevated mode
6. Use my tool like this: setdllcharacteristics.exe +d C:\Windows\System32\SpyShelterShellExt.dll
   Output shoud be:
   Original DLLCHARACTERISTICS = 0x0000
   DYNAMIC_BASE = 0
   NX_COMPAT = 0
   FORCE_INTEGRITY = 0
   Updated DLLCHARACTERISTICS = 0x0040
   DYNAMIC_BASE = 1
   NX_COMPAT = 0
   FORCE_INTEGRITY = 0
7. start regedit.exe in elevated mode
8. Search for SpyShelterShellExt.dll.disabled
9. Rename SpyShelterShellExt.dll.disabled to SpyShelterShellExt.dll

Now when you check with Process Explorer, you should see ASLR next to SpyShelterShellExt.dll

 

@Didier Stevens

Didier, you are such a wonderful person to have participating in a Forum.
Your knowledge is impeccable and we are so privileged to have you.

I am sure everybody on Wilders joins me in thanking you so very much in trying to help us all. Please maintain your interest in our threads.

John

 

Yes, please please frequent our forums and thanks again

 

thanks buddy

 

And what about a tool from MS called: EMET ?

 

wow , thx for the help . really appreciate it

 

I answered that before: https://www.wilderssecurity.com/showpost.php?p=1814351&postcount=130

 

Update: I exchanged e-mails with SS, they might add DEP and ASLR in one of their future versions.

They can't do it for the next version, because their compiler/linker doesn't support setting flags for DEP and ASLR. Which is a lame excuse, cfr. setdllcharacteristics.

 

Dear Didier,

Why just harp on SS only. The test you posted above regrading ASLR, shows almost every program in my computer lacking ASLR. The only process which has ASLR is svchost.exe!

Kind regards,

KOR!

 

You have to run process explorer as Admin to correctly show ASLR/DEP status for quite a lot of processes.

 

Because this is a SS thread. On my blog, you'll see that I didn't mention SS, and that I kept it generic.

But the problem we are discussing here is not that a process lacks ASLR, but that a process that is protecting itself with ASLR (like explorer.exe and Adobe Reader) has its protection weakened by a shell extension without ASLR support. ASLR is an all-or-nothing thing; if you do it half, it won't help.
This is not a theoretical risk. There is PDF malware in the wild that uses this to bypass DEP and ASLR.
http://www.infoworld.com/t/malware/dangerous-new-adobe-reader-zero-day-raises-the-bar-883

That's not normal. Like BoerenkoolMetWorst wrote, you probably forgot to elevate Process Explorer. And you are testing this on Windows Vista or later, right?