Sneaking Cards Into the Middle of the Deck   Leave a comment

Reading Dave (not coworker Dave, but actually a different guy) LeBlanc’s blog recently led me to this post, which points out some interesting security problems that aren’t quite problems with an operating system, or problems with an application, but instead a problem specific to the interface between an application and the operating system.

A difference between UNIX-ish systems and systems based on DOS is that the current directory “.” is not on the search path for UNIX-ish systems, and it is for DOS systems, which didn’t have different users, so there was no need to worry about some of these things. Originally, a Windows system would look for DLLs using the same ordering that you’d look for an executable – as documented in the SearchPath API:

The directory from which the application loaded.
The current directory.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit system directory. There is no function that retrieves the path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The directories that are listed in the PATH environment variable.

    The attack is that you find some DLL an app needs, make an evil twin, and put it in the same directory as a document, then lure someone who you’d like to have running your code to open the document. This is obviously a problem, and the advice we gave in Writing Secure Code (1&2) was to fully path the library you wanted to access with LoadLibrary. This advice isn’t always the best, since if you weren’t sure where you were installed, you might use SearchPath to go find it, which looks in the current directory, and now you have a problem again.

    What we did to fix it correctly was to make a setting that moved the current directory into the search order immediately before the path is searched, and after everything else. This took effect by default in XP SP2, Win2k3 and later, and was available in Win2k SP4. For the most part, this did get rid of the problem – if it was a DLL in the operating system, that got searched well before the current directory and all was good.

    The moral of the story: when you want to develop secure applications, you’re not writing code in a vacuum.  You need to understand how the operating system actually works.

    Windows API’s (root) are here.

    You have to dig around a bit to find the Dynamic Link Library search order:

    The dynamic-link library (DLL) search order used by the system depends on whether safe DLL search mode is enabled or disabled.

    Windows Vista, Windows Server 2003, and Windows XP SP2:  Safe DLL search mode is enabled by default. To disable this feature, create the HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode registry value and set it to 0. Calling the SetDllDirectory function effectively disables SafeDllSearchMode while the specified directory is in the search path and changes the search order as described in this topic.

    Windows XP and Windows 2000 SP4:  Safe DLL search mode is disabled by default. To enable this feature, create the SafeDllSearchMode registry value and set it to 1.

    If SafeDllSearchMode is enabled, the search order is as follows:

    1. The directory from which the application loaded.
    2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
    3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
    4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
    5. The current directory.
    6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key.

    If SafeDllSearchMode is disabled, the search order is as follows:

    1. The directory from which the application loaded.
    2. The current directory.
    3. The system directory. Use the GetSystemDirectory function to get the path of this directory.
    4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
    5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
    6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key.
    Advertisements

    Posted March 21, 2008 by padraic2112 in security, software, tech

    Leave a Reply

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out / Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out / Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out / Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out / Change )

    Connecting to %s

    %d bloggers like this: