We have been discussing the issue of unsafe DLL loading in the lab since the release of the Microsoft advisory about a potential attack vector that uses the default Windows DLL Search Order to load a malicious DLL into the process space of an application designated for opening a specific file type (e.g. .MP3 or .DOC or .XXX).
To summarize it, when an application dynamically loads a DLL without specifying a full path, Windows tries to locate the DLL by searching through a set of directories, known as DLL Search Order, which consists of
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
Now, if the attacker discovers a vulnerable application they can place a malicious DLL and a file to be opened by the vulnerable application (to set the current working directory) on a remote or WebDAV share so that the malicious DLL gets dynamically loaded to handle the designated file type.
Usually, when a new vulnerability is disclosed we publish a SophosLabs vulnerability analysis and write detection for our products to detect attempts to exploit the issue in the wild. However, this time, the cause of the vulnerability could not be classified as one of the usual suspects for remote code execution – buffer overflow, integer underflow or double free, so we decided that we will not write our own advisory knowing that Microsoft decided to put the emphasis for addressing the problem on the developers of the growing number of affected applications.
Microsoft has released guidance and tools for mitigating the issue both for the end users and for developers. Unfortunately, there must be hundreds of applications affected by the issue and it will take some time for their developers to fix them. In the mean time, it is important to follow the Microsoft’s guidance to mitigate the threat.
Our colleague Chet also commented the issue on his blog.