Article ID: 2389418 - View products that this article applies to.
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.
Description of DLL preloading attacks
LoadLibrary-based attacksWhen 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 LoadLibrary
(http://msdn.microsoft.com/en-us/library/ms684175(VS.85).aspx)functions, which are used to dynamically load DLLs:
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 attacksA similar attack exists when an application uses the SearchPath API to locate a DLL and dynamically load the path that is returned by SearchPath
(http://msdn.microsoft.com/en-us/library/aa365527(VS.85).aspx). The following is the default search order for the SearchPath API:
ShellExecute and CreateProcessVariations of these issues can also exist when developers call similar functions such as ShellExecute
(http://msdn.microsoft.com/en-us/library/ms682425(VS.85).aspx)to 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 developersWe recommend that developers do the following:
Guidance on identifying nonsecure library loadsIn source code, the following are examples of nonsecure library loads:
Using Process Monitor to dynamically detect nonsecure loadsMicrosoft 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.
For more information, visit the following Microsoft webpages:
Dynamic Link Library Search Order
http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspxMSDN documentation on the SearchPath function
http://msdn.microsoft.com/en-us/library/aa365527(VS.85).aspxMSDN documentation on the LoadLibrary function
http://msdn.microsoft.com/en-us/library/ms684175(VS.85).aspxMSDN documentation on the SetDllDirectory function
http://msdn.microsoft.com/en-us/library/ms686203(VS.85).aspxMSDN documentation on the SetSearchPathMode function
http://msdn.microsoft.com/en-us/library/dd266735(VS.85).aspxBlog post by David Leblanc, Principal Security Engineer with Microsoft Office
http://blogs.msdn.com/b/david_leblanc/archive/2008/02/20/dll-preloading-attacks.aspxBlog post by Andrew Roths, MSRC Engineering team on DLL preloading attacks
Article ID: 2389418 - Last Review: June 10, 2011 - Revision: 1.1
Contact us for more help
Connect with Answer Desk for expert help.