Secure loading of libraries to prevent DLL preloading attacks

LoadLibrary-based attacks

When an application dynamically loads a DLL without specifying a fully qualified path, Windows tries to locate this DLL by linearly searching through a well-defined set of directories, known as DLL Search Order. If Windows locates the DLL within the DLL Search Order, it will load that DLL. However, if Windows does not find the DLL in any of the directories in the DLL Search Order, it will return a failure to the DLL load operation. The following is the DLL Search Order for the LoadLibraryand LoadLibraryExfunctions, which are used to dynamically load DLLs:

1. The directory from which the application loaded

2. The system directory

3. The 16-bit system directory

4. The Windows directory

5. The current working directory (CWD)

6. The directories that are listed in the PATH environment variable

Consider the following scenario:

• An application loads a DLL without specifying a fully qualified path that it expects to find in the CWD of the application.

• The application is fully prepared to handle the case when it does not find the DLL.

• The attacker knows this information about the application and controls the CWD.

• The attacker copies their own specially crafted version of the DLL in the CWD. This assumes that the attacker has permission to do this.

• Windows searches through the directories in the DLL Search Order and finds the DLL in the CWD of the application.

In this scenario, the specially crafted DLL runs within the application and gains the privileges of the current user.

Recommendation

To prevent this attack, applications can remove the current working directory (CWD) from the DLL search path by calling the SetDllDirectory API by using an empty string (“”). If an application depends on loading a DLL from the current directory, please obtain the current working directory and use that to pass in a fully qualified path of LoadLibrary.



We are also aware that some developers use LoadLibrary to validate whether a specific DLL is present in order to determine which version of Windows is being run by the user. You should be aware that this could make the application vulnerable. If the affected library indeed does not exist on the Windows release that the application is executed on, an attacker could introduce a library with that same name into CWD. We strongly recommend against using this technique. Instead, use the recommended techniques that are described in MSDN article, "Getting the System Version."

An application that loads third-party plugins and that cannot force the plugins to use a qualified path for its LoadLibrary calls should call SetDllDirectory(“”) to remove CWD and then call SetDllDirectory(“plugin install location”) to add the plugin install directory to the DLL search path.

SearchPath-based attacks

A similar attack exists when an application uses the SearchPath API to locate a DLL and dynamically load the path that is returned by SearchPath. The following is the default search order for the SearchPath API:

• The directory from which the application loaded

• The current working directory (CWD)

• The system directory

• The 16-bit system directory

• The Windows directory

• The directories that are listed in the PATH environment variable

We do not recommend this pattern because it is not secure. We do not recommend the SearchPath function as a method of locating a .dll file if the intended use of the output is in a call to the LoadLibrary function. This can result in locating the wrong .dll file because the search order of the SearchPath function differs from the search order used by the LoadLibrary function. If you have to locate and load a .dll file, use the LoadLibrary function.

ShellExecute and CreateProcess

Variations of these issues can also exist when developers call similar functions such as ShellExecuteand CreateProcessto load external executables. We recommend that developers be careful when they are loading binaries and specify the fully qualified path. This should pose less complexity when you load a binary instead of a library.

Guidance on identifying nonsecure library loads

In source code, the following are examples of nonsecure library loads:

• In the following code example, the application searches for “schannel.dll” by using the least secure search path. If an attacker can place schannel.dll in CWD, it will load even before the application searches the Windows directories for the appropriate library.

  DWORD retval = SearchPath(NULL, "schannel", ".dll", err, result, NULL); 
  HMODULE handle = LoadLibrary(result);

• In the following code example, the application tries to load the library from the various application and operating system locations described in the beginning of this document for the LoadLibrary() call. If there is any risk that the file is not present, the application may try to load the file from the current working directory. This scenario is slightly less dangerous than the previous example. However, it still exposes the application user to risk if the environment is not completely predictable.

  HMODULE handle = LoadLibrary("schannel.dll");

The following are examples of better, more secure library loads:

• In the following code example, the library is loaded directly by using a fully qualified path. There is no risk of the attacker introducing malicious code unless he already has write permissions to the application’s target directory.
  
  

  HMODULE handle = LoadLibrary("c:\\windows\\system32\\schannel.dll");

  
  
  Note For information about how to determine the system directory, see the following resources:
  
  GetSystemDirectory

  http://msdn.microsoft.com/en-us/library/ms724373%28VS.85%29.aspxSHGetKnownFolderPath

  http://msdn.microsoft.com/en-us/library/bb762188%28v=VS.85%29.aspx

• In the following code example, the current working directory is removed from the search path before calling LoadLibrary. This reduces the risk significantly, as the attacker would have to control either the application directory, the Windows directory, or any directories that are specified in the user’s path in order to use a DLL preloading attack.

  SetDllDirectory ("");
  HMODULE handle = LoadLibrary("schannel.dll");

• On all systems that have installed security update 963027 (described in MS09-014), the following code would permanently move CWD to the very last spot in the search order. Any later calls to the SetSearchPathMode function from inside that process that try to change the search mode will fail.

  SetDllDirectory ("");
  HMODULE handle = LoadLibrary("schannel.dll");
  

• In the following code example, the current working directory is removed from the search path before calling LoadLibrary. This reduces the risk significantly, as the attacker would have to control either the application directory, the windows directory, or any directories that are specified in the user’s path in order to use a DLL preloading attack.

  SetSearchPathMode (BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE | BASE_SEARCH_PATH_PERMANENT );
  HMODULE handle = LoadLibrary("schannel.dll");