Windows service dll search path

I have developed a windows service using .net . My service makes some calls to unmanaged code like follows —

I have placed cmxConnect.dll within the same folder as the service executable. The service starts fine if I set the logon user to be my domain account. But if I start the service using the local system account I get DLL not found exceptions. I am guessing there is something in my environment settings thats enables windows to find cmxConnect.dll. Can someone point out what exactly this is?

4 Answers 4

The Local System account is pretty powerful. It’s possible that the DLL search order is disabled for this account for security. (If it goes searching just by name, and somebody manages to put a malicious DLL somewhere in the search order, then you’ve got an escalation of privilege vulnerability.) If it’s a .NET service, you probably want to add your DLL to your manifest and get your DLL installed in the GAC. (I’m not a .NET guy. I’ve just heard these terms before.)

Try process monitor from msft. This tool will show you where the service is looking for your dll. It may even be looking for a dependant dll. This would also show up in process monitor.

I’m guessing here, but have you checked the Environment Variables. Does your local system a/c have the same set of Env. Vars?

As I understand things the DllImport attribute simply wraps a call to LoadLibrary, so the standard Dynamic Link Library Search Order should apply.

Services will run in a far more restricted environment that user code — I can see that it would be undesirable to load dlls from any location other than the exe’s folder and System32 — everywhere else opens one up to a pre-loading attack, and that would be pretty serious with a service.

It could be that simple: Services can only search for dlls from System32?

The trusted locations to find dlls are:

1. When passed an explicit path its clear to LoadLibrary that the app knows which dll it wants. Can you pass a fully qualified path to DllImport?
2. The most trusted non-fully qualified place to search for dlls is in WinSxS — if you build the dll yourself, perhaps deploying it as a native Side by side assembly is an option.
3. The exe’s own folder. Usually. I can’t imagine that because the service is a .net app that this wouldn’t apply. But clearly there is an issue here.
4. System32 — you might need to install it here.

Loading Debugger Extension DLLs

There are several methods of loading debugger extension DLLs, as well as controlling the default debugger extension DLL and the default debugger extension path:

(Before starting the debugger) Use the _NT_DEBUGGER_EXTENSION_PATH environment variable to set the default path for extension DLLs. This can be a number of directory paths, separated by semicolons.

(Before starting the debugger; CDB only) Use the tools.ini file to set the default extension DLL.

(Before starting the debugger) Use the -a command-line option to set the default extension DLL.

Use the .extpath (Set Extension Path) command to set the extension DLL search path.

Use the .setdll (Set Default Extension DLL) command to set the default extension DLL.

Use the .chain (List Debugger Extensions) command to display all loaded debugger extension modules, in their default search order.

You can also load an extension DLL simply by using the full !module.extension syntax the first time you issue a command from that module. See Using Debugger Extension Commands for details.

The extension DLLs that you are using must match the operating system of the target computer. The extension DLLs that ship with the Debugging Tools for Windows package are each placed in a different subdirectory of the installation directory:

The winxp directory contains extensions that can be used with Windows XP and later versions of Windows.

The winext directory contains extensions that can be used with any version of Windows. The dbghelp.dll module, located in the base directory of Debugging Tools for Windows, also contains extensions of this type.

If you write your own debugger extensions, you can place them in any directory. However, it is advised that you place them in a new directory and add that directory to the debugger extension path.

There can be as many as 32 extension DLLs loaded.

Secure loading of libraries to prevent DLL preloading attacks

Support for Windows Vista Service Pack 1 (SP1) ends on July 12, 2011. To continue receiving security updates for Windows, make sure you’re running Windows Vista with Service Pack 2 (SP2). For more information, refer to this Microsoft web page: Support is ending for some versions of Windows.

When an application dynamically loads a dynamic link library (DLL) without specifying a fully qualified path, Windows tries to locate the DLL by searching a well-defined set of directories. If an attacker gains control of one of the directories, they can force the application to load a malicious copy of the DLL instead of the DLL that it was expecting. These attacks are known as “DLL preloading attacks” and are common to all operating systems that support dynamically loading shared DLL libraries. The effect of such attacks could be that an attacker can execute code in the context of the user who is running the application. When the application is being run as Administrator, this could lead to a local elevation of privilege. We know about renewed interest in these attacks. To limit the effect that this issue has on our mutual customers, we are releasing this document to the developer community to make sure that they know about this issue and have the necessary tools to address the issue in their applications.

Summary

Description of 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:

The directory from which the application loaded

The system directory

The 16-bit system directory

The Windows directory

The current working directory (CWD)

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.

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.

Recommended steps for software developers

We recommend that developers do the following:

Validate their applications for instances of nonsecure library loads (examples of each are given later in this article). These include the following:

The use of SearchPath to identify the location of a library or component.

The use of LoadLibrary to identify the version of the operating system.

Use fully qualified paths for all calls to LoadLibrary, CreateProcess, and ShellExecute where you can.

Implement calls to SetDllDirectory with an empty string (“”) to remove the current working directory from the default DLL search order where it is required. Be aware that SetDllDirectory affects the whole process. Therefore, you should do this one time early in process initialization, not before and after calls to LoadLibrary. Because SetDllDirectory affects the whole process, multiple threads calling SetDllDirectory with different values could cause undefined behavior. Additionally, if the process is designed to load third-party DLLs, testing will be needed to determine whether making a process-wide setting will cause incompatibilities. A known issue is that when an application depends on Visual Basic for Applications, a process-wide setting may cause incompatibilities.

Use the SetSearchPathModefunction to enable safe process search mode for the process. This moves the current working directory to the last place in the SearchPath search list for the lifetime of the process.

Avoid using SearchPath to check for the existence of a DLL without specifying a fully qualified path, even if safe search mode is enabled, because this can still lead to DLL Preloading attacks.

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.

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.

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.

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

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.

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.

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.

Using Process Monitor to dynamically detect nonsecure loads

Microsoft publishes a tool that is named Process Monitor. This tool enables developers and administrators to closely track the behavior of a running process. Process Monitor can be used to dynamically detect whether one of your applications may be vulnerable to this kind of issue.

To download Process Monitor, visit the following Microsoft webpage:

Try to start your application by using CWD set to a specific directory. For example, double-click a file that has an extension whose file handler is assigned to your application.

Set up Process Monitor with the following filters:

If a vulnerable path is being hit, you will see something that is similar to the following:

The call to the remote file share to load a DLL indicates that this is a vulnerable program.

More Information

For more information, visit the following Microsoft webpages: