Making sure that a DLL loads only from your application directory

You can ask for it as an option, but think about what you're actually protecting against. The post Making sure that a DLL loads only from your application directory appeared first on The Old New Thing.

Mar 14, 2025 - 17:10

Making sure that a DLL loads only from your application directory

A customer distributed a program and included its supporting DLLs in the same directory, because the application directory is the application bundle.

They worried about the case that the user deletes one of the supporting DLLs, and then when the program tries to load that DLL, a rogue copy somewhere else on the PATH gets loaded instead. They want to reject loading the DLL from anywhere other than the application directory.

You can accomplish this by explicitly calling LoadLibraryEx with the LOAD_LIBRARY_SEARCH_APPLICATION_DIR flag, which says that the function should look only in the application directory for the DLL. If it’s not there, it gives up without searching any other directories. After you load the library, you can use GetProcAddress to get the functions.

Unfortunately, this is rather cumbersome since you have to switch from implicit loading to explicit loading, so you don’t get the convenience of import libraries.

You might think that you can get the convenience back by using the /DEPENDENTLOADFLAG linker option with the value 0x200 (the numeric value of LOAD_LIBRARY_SEARCH_APPLICATION_DIR), but the problem is that the dependent load flag applies to all DLLs loaded via import tables, and that includes kernel32 and other DLLs you probably wanted to load from the system32 directory.

Now, the system32 directory is writable only by administrators, so we could consider that a “safe” directory, because if somebody attacks that directory, they have already taken over the system. Therefore, you could use the /DEPENDENTLOADFLAG linker option with the value 0xA00, which is the numeric value of LOAD_LIBRARY_SEARCH_APPLICATION_DIR | LOAD_LIBRARY_SEARCH_SYSTEM32. Alternatively, you could use the value 0x1000, which is the numeric value of LOAD_LIBRARY_SEARCH_DEFAULT_DIRS, which includes the application directory, the system32 directory, and any directories added by AddDllDirectory and SetDllDirectory.

But wait, what is the issue we are trying to defend against? The stated scenario is “The user deletes a DLL from the application directory.” In that case, the user already has write permission into the application directory, so instead of deleting the DLL, they can just replace it with a malicious DLL. Restricting the load to the application directory does not prevent a malicious DLL from being loaded.

But maybe your goal is not to create a security boundary but just to contain the scope of an error. If the user accidentally deletes the DLL from the application directory, at least prevent somebody else from injecting a DLL into the process by planting a DLL on the path.

Now, the directories on the path fall into two categories. You have the directories on the global path, and the directories that are specific to a single user. If an attacker can plant a DLL into a directory on the global path, then that means that they have gained write permission onto the global path. To do this without administrator privileges requires that the global path contain a directory writable by non-administrators, which is an insecure configuration, so we are in the case of creating an insecure system and then being surprised that it is insecure. Instead of planting a rogue DLL on the path, the attacker could just plant, say, a rogue notepad.exe, and steal all your attempts to run notepad.

The other case is that the directory under attack is a directory on the per-user path. The user chose to add that directory, and if they added a directory that is writable by non-administrators other than the current user, they have once again created an insecure system because they have granted non-administrators the ability to inject things into their path.

The only attacks against rogue DLLs on the path assume that the system has already been compromised. So this issue is not about protecting a secure system but rather trying to protect from an already-compromised system.

The post Making sure that a DLL loads only from your application directory appeared first on The Old New Thing.