I’ve written about Shell Extension without ASLR support before.
Not only do they open up explorer.exe to ROP attacks, but other applications too, like Adobe Reader and Microsoft Office.
You could use EMET to force ASLR on these DLLs, assuming you know which applications load shell extensions. Because shell extensions are not only loaded into explorer.exe, but other programs too, I wrote a tool to force Shell Extension DLLs to load at another address than their base address, effectively simulating ASLR.
When my tool, SE_ASLR.dll, is loaded into a process, it will check for the presence of comdlg32.dll inside the list of loaded modules. When comdlg32.dll is used by an application, the likelihood of shell extensions being loaded into the process by user interaction with the file dialogs is significant.
Hence SE_ASLR will patch the IAT to intercept calls to LdrLoadDll. Each time the application loads a DLL (all DLLs, not only shell extension), SE_ASLR will check if the DLL supports ASLR. If it doesn’t, SE_ASLR will pre-allocate a memory page at the base address of the DLL, thereby forcing the loader to load the DLL at another address.
Although SE_ASLR’s primary goal is to relocate shell extensions, it will effectively relocate all DLLs without ASLR support once SE_ASLR is loaded into the process.
You need to load my tool into all applications that could use shell extension, for example via the AppInit_DLLs registry key. But before you do, be sure to test this out on a test machine. Not all shell extensions support relocation.
SE_ASLR_V0_0_0_1.zip (https)
MD5: 9D6AE1A96D554AEE527EB802FE59FB20
SHA256: 8A6C1406A757CD9788A2630D76A497E2C058333EE4D44CA0B85B2A05A39F257E
Didier Stevens 
Straightforward and clever – that is how I like approaches! I’ll try it out, thanks for the DLL 😀
Comment by Daniel Bilar — Wednesday 10 August 2011 @ 14:11
@Daniel Yes, but real ASLR is probably better. More details in an upcoming blogpost.
Comment by Didier Stevens — Wednesday 10 August 2011 @ 16:11
Does it relocate the DLL to a predictable address?
Comment by Anonymous — Thursday 11 August 2011 @ 22:35
@Anonymous It’s not always the same address, I’m writing a blogpost about this.
Comment by Didier Stevens — Friday 12 August 2011 @ 7:36
[…] is what EMET and my tool SE_ASLR enforce. When a DLL does not support ASLR, memory at the base address of this DLL is allocated […]
Pingback by So How Good is Pseudo-ASLR? « Didier Stevens — Tuesday 16 August 2011 @ 0:31
According to http://msdn.microsoft.com/en-us/library/dd744762(v=vs.85).aspx, in Vista and later, value of LoadAppInit_DLLs must be set to 1 to enable AppInit_DLLs and Windows 7 supports loading only digitally signed DLLs so maybe you should sign SE_ASLR.dll.
Comment by xpclient — Friday 27 January 2012 @ 7:08
Okay sorry I found the newer blog post with the signed DLL. 🙂
Comment by xpclient — Friday 27 January 2012 @ 7:30
[…] I added Bottom Up Randomization to my SE_ASLR tool. […]
Pingback by Update: SE_ASLR Version 0.0.0.2 « Didier Stevens — Thursday 29 March 2012 @ 9:15