Re: Distribution of MFC42.dll
From: Doug Harrison [MVP] (dsh_at_mvps.org)
Date: 07/02/04
- Next message: Joseph M. Newcomer: "Re: Is the following code MT-Safe?"
- Previous message: Christopher J. Holland: "Re: Access to the CMDIFrameWnd"
- In reply to: David Lowndes: "Re: Distribution of MFC42.dll"
- Next in thread: David Lowndes: "Re: Distribution of MFC42.dll"
- Reply: David Lowndes: "Re: Distribution of MFC42.dll"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 01 Jul 2004 19:58:46 -0500
David Lowndes wrote:
>>Regarding searching the Windows directories first to avoid spoofing,
>>I'd expect if this is done at all, it will be for a select few DLLs. If it
>>were performed for all DLLs, it seems there would be a high probability of
>>breaking quite a few apps, not to mention negating the advice MS has been
>>putting out for several years as a partial solution to DLL hell. Not to
>>mention, for a DLL that is not subject to the OS file protection feature,
>>this would make it _easier_ to spoof on the millions of systems that are run
>>as administrators, in which anyone can write to the Windows directories.
>
>My thoughts exactly - hence the search for the truth on this matter.
Well, this is certainly interesting:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/secure06122003.asp
<q>
DLL Search Order Has Changed
No longer is the current directory searched first when loading DLLs! This
change was also made in Windows XP SP1. The default behavior now is to look
in all the system locations first, then the current directory, and finally
any user-defined paths. This will have an impact on your code if you install
a DLL in the application's directory because Windows Server 2003 no longer
loads the 'local' DLL if a DLL of the same name is in the system directory.
A common example is if an application won't run with a specific version of a
DLL, an older version is installed that does work in the application
directory. This scenario will fail in Windows Server 2003.
The reason this change was made was to mitigate some kinds of trojaning
attacks. An attacker may be able to sneak a bad DLL into your application
directory or a directory that has files associated with your application.
The DLL search order change removes this attack vector.
</q>
Taken literally, this strikes me as horribly misguided for the reasons I
gave in my last message, but thankfully, it's wrong. Contrast it with the
LoadLibraryEx docs:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/loadlibraryex.asp
<q>
This standard strategy searches for a file in the following sequence:
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 obtains the path of
this directory, but it is searched.
Windows Me/98/95: This directory does not exist.
The Windows directory. Use the GetWindowsDirectory function to get the path
of this directory.
The directories that are listed in the PATH environment variable.
Windows Server 2003, Windows XP SP1: The default value of
HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode is 1
(current directory is searched after the System and Windows directories).
Windows XP: If HKLM\System\CurrentControlSet\Control\Session
Manager\SafeDllSearchMode is 1, the current directory is searched after the
System and Windows directories, but before the directories in the PATH
environment variable. The default value is 0 (current directory is searched
before the system and Windows directories).
</q>
This documentation states the directory containing the application is ALWAYS
searched first, which is as it should be. It's what I observe when I do a
simple test in my Windows XP SP1 system. I created a DLL, z.dll, that
exports a single function, f. I compiled one version to print "Windows" and
moved it to the System32 directory. Then I changed the function to print
"temp" and recompiled, leaving this z.dll in my temp directory. I wrote a
program "zexe" that links to z.dll and calls f. Here's what I observe:
1. EXE is in temp, DLL is in temp, DLL is in System32: "temp" is printed
regardless of the current directory my command prompt is at when I run
%temp%\zexe, even when the current directory is System32.
2. EXE is in root directory, DLL is in temp, DLL is in System32, current
directory is temp: "Windows" is printed when I run \zexe.
3. EXE is in root directory, DLL is in temp, DLL has been deleted from
System32, current directory is temp: "temp" is printed.
These results are consistent with the LoadLibraryEx docs, not the MSDN
article cited above. So, you'll only observe a behavioral change if you're
loading DLLs from some "current directory" different from the application
directory.
-- Doug Harrison Microsoft MVP - Visual C++
- Next message: Joseph M. Newcomer: "Re: Is the following code MT-Safe?"
- Previous message: Christopher J. Holland: "Re: Access to the CMDIFrameWnd"
- In reply to: David Lowndes: "Re: Distribution of MFC42.dll"
- Next in thread: David Lowndes: "Re: Distribution of MFC42.dll"
- Reply: David Lowndes: "Re: Distribution of MFC42.dll"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
