SafeDllSearchMode

Remember the summer and fall of 2001? The world was changing, significantly. There were attacks from everywhere. On the Internet we had Code Red. When you finally had cleared that off all your systems, your boss came running into the office screaming that there was another worm on the loose. No worries, you responded; IIS was already patched. There was only one problem: This one spread other ways, too. The next thing you knew you had Nimda on your hands, and it spread through file shares.

Nimda searched all available file shares it could find for Microsoft Word documents. The reason was that one of those "security researchers" who believe the world is safer if he tells all the script kiddies how to exploit something without giving the vendor a chance to fix it first had posted a treatise on how to load and execute code when users double-clicked Word documents. The issue stems from how the operating system searches for dynamic link libraries (DLLs). DLLs are used to allow programs to share common functionality. Programs load them by calling LoadLibrary or LoadLibraryEx. When a program calls this function specifying just the name of the DLL, as opposed to a full path, the OS will search to find the right version in the following way:

• Memory If the program is already running and has the DLL loaded, it will not load it again.
• Application directory To allow programs to keep their own copies of DLLs so they can load specific versions, those have very high priority.
• Current working directory This allows programs to use SetCurrentDirectory to load a particular DLL.
• System directories These are the %systemroot%, %systemroot%\system, and %systemroot%\system32 directories.
• Path Some DLLs are found along the path.

This list can be modified by various technologies such as manifests and .local files. This has been the way Windows has worked since the very first versions of the OS. What the "researcher" figured out was that Word will load certain DLLs at startup. If you dropped a copy of one of those, the one he used was riched20.dll, into a directory with documents, it would be loaded by Word when the user double-clicked one of the documents. Nimda used this exact issue as one of the ways to spread.

Several interesting observations can be made here. First, neither the person who discovered how to use this for malicious purposes nor the writers of Nimda (we are not aware of any connections between the two) understood nearly as much about the OS as they have been given credit for. Riched20.dll is the "rich text editor" DLL. It is used to provide bolds, italics, and so on. It is actually loaded by the OS automatically for an awful lot of programs. In other words, they could have looked for almost any file they wanted and dropped it there. At one point, we swear we saw WinZip load this DLL. Second, this is core operating system functionality. It has worked this way for years. The fact that no bad guys had made use of it until 2001 was astounding. Third, the basic functionality is really broken. If you go tell any decent UNIX administrator to put a period (.) as the first thing in his path, he will claim you are smoking some funny tobacco. They all know not to do that. Yet, that is how Windows was always designed to work.

This all changed with Windows XP Service Pack 1. Starting with that release, the SafeDllSearchMode setting switched items 3 and 4 in the load order, protecting system DLLs from spoofing. To understand how important this switch is, consider that it would have stopped Nimda in many cases!

The SafeDllSearchMode functionality is available and turned on by default in Windows XP Service Pack 1 and higher, and in Windows Server 2003. It is available but turned off by default in Windows XP RTM and Windows 2000 Service Pack 3 and higher. We highly recommend turning on SafeDllSearchMode in Windows 2000 as well. (Windows XP RTM should be upgraded to Service Pack 2 or higher.) To turn it on, set a REG_DWORD called SafeDllSearchMode to 1 under HKLM\System\CurrentControlSet\Control\Session Manager. On Windows Server 2003, this value does not exist, but if it is absent the default value is 1.

When you make a fundamental change to how the operating system works, like this, there is always some breakage. In this particular case, surprisingly, the number of breaks was low. SQL 2000 includes a component known as the Starfighter Foundation Classes in SFC.DLL. Unfortunately, SQL Server instead loaded SFC.DLLthe system file checkerfrom the system directory. That was fixed in SQL Server 2000 Service Pack 3. The only other breakage we are aware of was with Outlook 2000 loading add-ins.

This setting protects against an extremely common scenario whereby an internal attacker drops binaries in file shares. The breakage caused by turning it on is minimal. For these reasons, we believe SafeDllSearchMode is one of the most important settings to turn on to protect clients.