The basics are simple. Windows has a search path for DLLs, much the same way it has a $PATH for finding executables. If you can figure out what DLLs an app requests without an absolute path (triggering this search process), you can then place your hostile DLL somewhere higher up the search path so it'll be found before the real version is, and Windows will happilly feed your attack code to the application.
So, let's pretend your system's DLL search path looks something like this:
a) . <--current working directory of the application, highest priority, first check
b) windows
c) windowssystem32
d) windowssyswow64 <-- lowest priority, last check
and some application Foo.exe requests "bar.dll", which happens to live in the syswow64 (d) subdir. This gives you the opportunity to place your malicious version in a), b), or c) and it will be loaded into the app automatically whenever the app requests bar.dll. And now your foo is well and trully bar'd.
As stated before, even an absolute full path can't protect against this, if you can replace the DLL with your own version.
And of course, this isn't really limited to Windows either. Any OS which allows for dynamic linking of external libraries is theoretically vulnerable to this.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…