You often read about people who use many different security applications to protect their systems. Not only anti-virus, anti-spyware, firewall, HIPS, …, but also some other tools like anti-keyloggers, … And sometimes, when they argue about the additional protection such tools bring, you can read the following: “it does no harm…”.
Well, this time, I’ve a clear example where using a supplemental security tool does harm, even when it adds real protection.
When installed, this tool (which I’m not going to name here because of SEO reasons), installs a Windows explorer shell extension (we’ve discussed the risks of these shells before). The problem with this tool’s shell extension (a DLL), is that it is compiled without the dynamic base flag set. In other words, it doesn’t support ASLR.
On a default Windows Vista or Windows 7 install, all the DLLs of explorer.exe support ASLR. Even if a vulnerability is found in explorer.exe, it won’t be possible to bypass DEP and ASLR by borrowing code from a DLL to build an exploit with ROP gadgets. Unless you’ve installed this security tool, which adds a DLL with a fixed address to explorer.exe’s code space. Then an attacker can find ROP gadgets in this shell extension’s DLL.
This security tool harms the security of your system by opening it up to ROP exploits.
And shell extensions are not only loaded into explorer.exe. They find their way into many applications. For example, when you work with the common dialog control (like using the file open dialog) in an application, shell extensions also get loaded into these applications. So this extension can get loaded into Adobe Reader, Microsoft Office applications, …
The risk this security tool brings to your system is not theoretical. There are malicious PDFs in the wild that use ROP gadgets.
Didier Stevens 
Hi,I am using this tool which you are referring to and want to know if the ASLR problem is specific to x86 7/Vista or it also affects x64 and if it does, would installing EMET to overcome this,could cause a conflict with this tool?
Thanks.
Comment by Manab Choudhury — Monday 17 January 2011 @ 17:48
@Manab Choudhury You could use EMET but then you need to protect each application into which the dll gets loaded, starting with explorer.exe.
Another way is to set the flag yourself, for example with my setdllcharacteristics tool https://blog.didierstevens.com/2010/10/17/setdllcharacteristics/
Or you can also configure the tool to disable explorer shell integration.
Comment by Didier Stevens — Monday 17 January 2011 @ 17:58
[…] people asked me for a simple way to check shell extensions for their ASLR support. You can do this with Process […]
Pingback by Quickpost: Checking ASLR « Didier Stevens — Tuesday 18 January 2011 @ 11:14
[…] reporting it. Too bad quite a number of other apps also has this leak….7-Zip, etc etc See here: https://blog.didierstevens.com/2011/0…rm-or-does-it/ They call me the mysterious one… my motto is…when it's hot, chill baby Reply With […]
Pingback by SpyShelter 5.03 — Tuesday 25 January 2011 @ 20:50
[…] written about Shell Extension without ASLR support […]
Pingback by Force “ASLR” on Shell Extensions « Didier Stevens — Wednesday 10 August 2011 @ 0:50