CWD should be the next DEP

Ok, we are going to go a little deep techy here today.

I was trying to resolve an application compatibility issue for a client a little while ago  - this of course is an occupational hazard ...

The problem was legacy (and poorly written) applications were trying to load DLL's using the "Current Working Directory" or CWD. This meant that core DLL's such as MSVCRT.DLL and MFC40.DLL were loaded from the application directory - rather than a protected and managed directory like SYSTEM32.

Normally, my approach would be to simply remove the files - thus solving the compatibility issue by forcing the application to use the later versions of these core DLL's contained in the SYSTEM32 directory.

Unfortunately, both Side-by-Side (SxS) isolation and my standard approaches (delete first, cover your tracks later) did not work.

So, I went hunting for ways to stop applications from loading DLL's from the current directory. And, funnily enough, it looks like enough people have been experiencing the same issue as Microsoft has included the CWDIllegalInDllSearch feature in Windows 7.

You can read more about this approach to control the Load Search order of DLL's in the references included at the bottom of this post, but here is a brief description of the update and registry setting;

This update introduces a new registry entry CWDIllegalInDllSearch that allows users to control the DLL search path algorithm. The DLL search path algorithm is used by the LoadLibrary API and the LoadLibraryEx API when DLLs are loaded without specifying a fully qualified path.  

The update allows the administrator to define the following on a system-wide or a per-application basis: 

• Remove the current working directory from the library search path. 

• Prevent an application from loading a library from a WebDAV location. 

• Prevent an application from loading a library from both a WebDAV, as well as a remote UNC location. 

How cool is this?

There are a number of scenarios supported by this new feature including;

1. The application is started from a local folder, such as C:\Program Files
2. The application is started from a remote folder, such as \\remote\shareremote\share)
3. The application is started from a WebDav folder, such as http://remote/share)

Through a combination of registry settings you can control how applications search for their DLL's and supporting files. That said, I noticed that you cannot prevent loading libraries from USB sticks and other like devices.

So, by updating the following registry settings for;

A single workstation, set the following registry keys

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager

A  specific application on a computer:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\

With the following settings, you have pretty good control over how your application will look for DLL's on the machine, with the added bonus that you can configure this settings for particular applications.

Here are some suggested settings;

0xFFFFFFFF:  Removes the current working directory from the default DLL search order 

0 : Uses the default DLL search path that was mentioned earlier 

1 : Blocks a DLL Load from the current working directory if the current working directory is set to a WebDAV folder 

2 : Blocks a DLL Load from the current working directory if the current working directory is set to a remote folder (such as a WebDAV or UNC location) 

Note: No key or other values Uses the default DLL search path that was mentioned earlier

So, following my instincts (an owing to a slight personality disorder) I set my application specific settings to 0xFFFFFFFF. And, the application behaved much better. Unfortunately, we hit another compatibility issue, but that will be dealt with in another post.

Ohh, and why the title?

If you look at how CWD really works, we should be implementing CWD lock-downs as a matter of security for each workstation. This should operate in the same manner that the security mechanism Data Execution Prevention (DEP) was implemented in Vista and Windows 7.

Maybe we will see CWD in Windows 8? I can't wait.

For more information, see the following links and references.

A new CWDIllegalInDllSearch registry entry is available to control the DLL search path algorithm
http://support.microsoft.com/kb/2264107

And some information on the LoadLibrary function here:
http://msdn.microsoft.com/library/ms684179(v=VS.85).aspx

A detailed description of the Data Execution Prevention (DEP) feature in Windows XP Service Pack 2, Windows XP Tablet PC Edition 2005, and Windows Server 2003
http://support.microsoft.com/kb/875352