Is it safe to use non-ASLR DLL in an enabled ASLR EXE

Question

Is it safe to use non-ASLR DLL in an enabled ASLR EXE? Would the DLL be loaded to and will use random addressed, or should all the dependencies enable ASLR?

In addition, what about other security mechanisms such as DEP and SHE?

Answer 1

On Windows, an executable that is ASLR aware (compiled with /DYNAMICBASE) can load a library (DLL) that is not compatible with ASLR.

In this situation the DLL will not typically use ASLR, though newer versions of Windows are becoming stricter and enforcing ASLR even on some images that don’t opt-in, unless relocations have been stripped (for example by linking with /FIXED).

Doing this can weaken the protection provided by randomised memory, because there will now be an image at a predictable address. However, there must first be some form of vulnerability in the program. Simply loading a DLL is not a vulnerability alone.

For example: a common way for malicious RTF documents to bypass ASLR in Microsoft Word after initial exploitation was to craft a document that ensures otkloadr.dll is loaded into memory, read more here.

There’s also a useful blog from Raymond Chen about the difference between relocation and ASLR and some facts about ASLR from FireEye.

Regarding DEP, or NX, there’s a useful quote from a different Raymond Chen blog on enabling NX and ASLR:

The NX setting is process-wide, and the process takes its NX state from the /NX­ENABLED state of the executable, not from any DLLs. It’s yet another one of the module flags that are meaningless for DLLs. So mix it up in the DLLs all you want. Nobody will care, because the flag is ignored for DLLs anyway.

Answer 2

You're only as secure as your weakest link. If there is a memory corruption vulnerability in your program, an attacker will look for any way possible to achieve code execution. If any imports are missing exploit mitigations, the attacker's job may be much easier, since they may easily find known memory addresses or find a place for executable code.

So, while missing exploit mitigations on some components is not necessarily an instant security issue (i.e. it doesn't create a vulnerability, but rather makes existing vulnerabilities worse), it really can be an all-or-nothing protection.

Answer 3

To put it bluntly, if you load a non-/DYNAMICBASE binary (DLL or similar) into any process, and you haven't configured the OS to force ASLR anyhow (this is possible but not enabled for third-party apps by default, as of the latest Windows Insider build) you just about may as well not have ASLR at all. This is because any non-toy library contains enough ROP gadgets to execute an arbitrary payload, and the attacker will know where to find them.

Now, ASLR is an exploit mitigation, not a vulnerability prevention; if you don't have any memory corruption vulns then ASLR being present or not is irrelevant. However, I certainly wouldn't say it's safe to load a non-/DYNAMICBASE library (where did you even find that relic?) unless you have the entire OS - or at least the relevant process - configured to force ASLR. To do this, you either can use EMET on pre-Win10 systems, or use the "Exploit Protection" feature built into Win10 (you can search for it in Start, or go to Windows Security -> App & browser control -> Exploit protection settings).