Recently, a new security vulnerability affecting Microsoft Windows has been reported that potentially provides a new vector for remote attacks. The vulnerability has to do with how Windows searches for and loads Dynamic Link Libraries [DLLs], which are used by virtually all Windows applications. (DLLs are similar to shared libraries in Unix/Linux.) The SANS Internet Storm Center has a good diary entry reviewing the issue, and Microsoft has issued a Security Advisory (2269637), which contains suggested mitigation steps and work-arounds.
The nature of this vulnerability is a little out of the ordinary, although it has aspects in common with the LNK vulnerability we saw earlier this summer, which Microsoft patched at the beginning of August. It is a result of the way a basic mechanism of Windows works, so it is hard to say exactly which applications might be vulnerable. The key really is how careful the application’s developers were when building their distribution package.
To explain why this is so, I’ll have to discuss briefly what DLLs are, and how Windows uses them. Like Unix, Linux, OS/2, and other relatively modern systems, Windows contains a large number of program libraries, which supply software modules that can be shared among applications. For example, a routine that displays a dialog box to the user would be a logical candidate for inclusion in a library. In these systems, furthermore, the libraries are dynamic, meaning that the routines that they contain can be loaded and linked at run time, rather than in a separate, static linking step. Also, especially in virtual memory systems, this facilitates having only one copy of the routine resident in memory, even if it is being used by multiple applications.
So, essentially, DLLs provide pieces of code that can be loaded and executed at run time, as part of an application. That description should suffice to make any security-minded person fairly nervous. Obviously, this is a mechanism that has to be controlled, so that arbitrary code cannot be so inserted — and this is the kernel of the problem. Some “known DLLs”, typically for core system functions, are specified in a Windows registry key, and the system knows where they are. There are two problems with the way Windows searches for any other specified DLL at run time.
The first place Windows looks for a DLL is always the directory from which the application was loaded. This is done so that applications can override a “standard” DLL for their own use. Beyond that, though, there are two cases. Since Windows XP/SP2, the search order has been:
- 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.
The first matching DLL found is used. (Microsoft has a good article on MSDN explaining all this in more detail.)
However, previous versions of Windows used a different order, in which the current directory was searched immediately after the application directory (that is, it was number 2 on the list). Newer versions of Windows can be made to revert to the old behavior, according to the setting of the SafeDllSearchMode registry key. If the current directory is searched before the system directories, anyone who can write to the current directory can substitute a malicious DLL for the standard one. (Ask any Unix or Linux sysadmin why root should never have ‘.’ in its PATH.)
The second problem is more subtle, and harder to detect. Because applications can specify alternative paths to be checked for DLLs, and because the directories in the PATH are searched, an attacker might be able to put a malicious version of an application’s DLL in the PATH, or on a Windows share.
The existence and severity of this vulnerability depends on the application, and a general Windows patch is not really possible. Microsoft has, however, released a tool that allows you, via a registry key setting, to selectively disable parts of the DLL search process, either for specific applications, or on a system-wide basis.
So far, there have been sample exploits published for Windows Mail and Microsoft Office applications. It is hard to predict what the ultimate impact of this will be. For now, if you run Windows systems, I recommend getting a copy of the new tool from Microsoft, and testing its installation on a non-critical system. In theory, installing the tool just enables the new registry settings; it shouldn’t actually change any behavior without further action. But I think it’s a good idea to verify this on your own system, since if you find you need this tool, you will probably need it in a hurry.
Update Wednesday, 1 September, 12:08 EDT
Brian Krebs has a good overview of this vulnerability at his Krebs on Security blog. As he points out, Microsoft has updated the support article [2264107] on the tool I mentioned above to include more information, and also to provide a “one-click” FixIt tool that will make a mitigating registry change for you. It is important to realize that the FixIt tool requires the original tool / patch to be installed first — that is what enables the relevant registry entry in the first place. So if you want to install the “FixIt”, two steps are necessary:
- Scroll down the page in the support article [2264107] to the section called “Update Information”. Download the patch for your version of Windows, and install it. You will most likely have to reboot your machine.
- Go back to the support article, or the security blog article mentioned below, click the “FixIt for Me” link, and follow the instructions.
Microsoft also has a new article on its Security Research and Defense blog giving more information about how the exploit would work, from a user’s perspective. The article also has a link to the FixIt tool.
Update Thursday, 2 September, 20:20 EDT
The US-CERT [Computer Emergency Readiness Team] Web site has an updated Vulnerability Note (# 707943), which contains their summary of this issue. It also contains, in the section “Vendor Information”, a list of vendors who have acknowledged that their software may be affected; this may be useful if you have concerns about a specific application.