This blog details some of my thoughts and aspirations relating to application packaging, compatibility and the ongoing management of applications on desktop, server and cloud platforms. I have a strong focus on the Windows desktop space, but as we progress into more and more cloud based application management, we will definitely see more posts on getting applications working
in the cloud.

Wednesday, 15 December 2010

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.

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;

The application is started from a local folder, such as C:\Program Files

The application is started from a remote folder, such as \\remote\shareremote\share)

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.

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.