So what can you do? Follow Microsoft's guidance on DLL security. In particular, it's a bad idea to rely on the system PATH environment variable for your application to find its DLLs. The PATH lies behind the current directory in DLL loading priority:
- The directory from which the application loaded.
- The system directory.
- The 16-bit system directory.
- The Windows directory.
- The current directory.
- The directories that are listed in the PATH environment variable.
Microsoft docs refer to this order as "Safe Search Order" or "SafeDllSearchMode" and it is enabled with a registry key. This setting has been default-on since Windows XP SP2 and supported since Windows XP SP1. If you are working with clients older than that, then DLL search order may be the least of your problems, as even XP SP2 is no longer supported.
Of course, if you specify a fully-qualified path in your call to LoadLibrary, LoadLibraryEx, CreateProcess, or ShellExecute, no search is necessary. So that's always the best way, if you can. You can also make sure your app runs the correct DLL by using DLL Redirection or a Manifest. You can specify a particular search order for the app with the SetDllDirectory function.
You may have already noticed a steady stream of application security updates related to this issue, including some from Mozilla. A recent security update of Safari from Apple fixes a nasty variation on the same bug, that of the EXE load search order. When you load executables you have to be aware of the same problem. Mitja Kolsek of ACROS says that "the search path for executables is actually much worse, even worse than it used to be for DLLs before Microsoft introduced the 'safe search order.'" Unless you specify the full location of executable, Windows will first look in the current directory.
Once you understand the problem it seems rather obvious, and remarkable that it hasn't been noticed before. This also represents a gap in the guidelines of the Microsoft Security Development Lifecycle (SDL), the secure development practices created by Microsoft for its own use and available to anyone through the Creative Commons License. I asked Microsoft who admitted as much:
Given the newly-found Internet attack vector, we are currently updating the SDL to include guidance and tooling for developers and testers so they can prevent or find, triage and fix potential DLL preloading vulnerabilities in their products. Once we have finished the SDL guidance, we will make a version of the guidance and tooling documentation publicly available as soon as possible."
You might think that the answer would be to remove the current directory from the search order, and we asked Microsoft about just that. It seems this possibility is not in the cards, as it would break a substantial number of customer installations, and this is the clearest evidence you could ask for that this is a serious problem. It proves that the number of apps which rely on the current directory for DLL loading is large.
For the long term, Microsoft has released an update which enables a new registry key called CWDIllegalInDllSearch that lets users and administrators control the loading of DLLs in their own systems. You can't rely on this being loaded and Microsoft won't be turning it on by default. With no systemic solution coming from Microsoft it's up to you, the developer and publisher of the application, to make sure it's done right and get any fixes to your users.