Windows DLL Loading Sec Hole

In August, 2010, the Slovenian security research firm ACROS Security issued an advisory for a vulnerability in Apple's iTunes. The details in the advisory accidentally exposed a much larger story that ACROS was working on quietly: Many Windows applications -- including many famous ones and possibly your own -- are vulnerable to the same attack. Luckily you can fix the problems and I'll show you how.

"Remote Binary Planting" is a new variation on an old attack, first identified 10 years ago by Georgi Guninski. He showed how an attacker could load a malicious DLL by including it in the same directory as a data file opened by the user through the Windows shell. At the time, the problem was that when Windows searched for a DLL to load, the current directory was high in the search order. When you load a data file in the shell, Windows sets the file's directory as the current directory when loading the file, so all you had to do was to name your DLL and the calls exported from it the same as the one expected by the application.

Here's how it works: The attacker places an enticing data file in a folder on a network share or web folder. Probably through a social networking attack ("Open mlb.xls to see pennant race analysis") he induces a user to open the file. In the same directory as the file is a DLL with the same name as one needed by the application to open the file, and exporting a function expected by the application. With a vulnerable application, Windows will look for the DLL in the current directory -- the one containing the data file -- before finding the real one, and therefore will load it and run the malicious code.

In response to this issue, Microsoft changed the DLL search order, created the SetDllDirectory function and issued guidance about proper loading of DLLs. It turns out that this advice is widely ignored, even within Microsoft.

ACROS's innovation in this attack was to show how to exploit it on a network share or remotely over the Internet on a WebDAV share. This raises the credibility of the attack scenario a great deal. Indeed, if an attacker gains access to a network, getting users to load data files from a network share within it should be relatively easy. This would be a great tool for an attacker perpetrating a targeted attack against your organization, where they have some knowledge of you already. All they need is the credentials of a relatively unprivileged user.

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:

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 directory.
6. 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.

Microsoft's Dynamic-Link Library Security page also has instructions for how to use the Process Monitor tool to observe exactly what DLLs your apps are loading and from where.

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:

Quote:

---

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.

Nobody wants to discuss about this? Thought it would of sparked interest from at least a few people here??