Dennis Jenkins wrote:
You can do something very similar on windows. Just dump a
hacked "kernel32.dll" into the same directory as the EXE. This might
not work with SP2 of XP for system DLLs. However, if the EXE uses a
non-system DLL (like libJpeg.dll), then just replace that one. Put some
code into the DllMain function that installs whatever hook procedure you
need, and viola! You have just compromised the EXE and can do anything
on that system that you want that the user running the EXE has the
rights to do.
Dennis,
This issue with the DLL search order has been changed in Win XP SP1 and
later, as the following link explains.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/secure06122003.asp
The pertinent section is copied below.
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.
The SetDllDirectory function, also available in Windows XP SP1, modifies
the search path used to locate DLLs for the application and affects all
subsequent calls to the LoadLibrary and LoadLibraryEx functions by the
application.
Dennis Cote
