the problem with DLL search paths

recently, some old news has become new again. when i first read about DLL search order hijacking in nick harbour's post on mandiant's blog i thought to myself 'gee, that sounds an awful lot like a companion virus, except without the self-replication part'.

apparently i wasn't the only one. robert sandilands made the companion virus connection too, except for some reason he combined execution precedence companion viruses with path precedence companion viruses. path precedence is the only one needed here, and if you really think about path precedence companions or you go back and read nick harbour's post again you'll see that the all this focus people are giving to the issue of the current directory is taking attention away from a broader issue.

while the current directory could be used to initiate a compromise of a machine, if the malicious DLL is anywhere in the search path before the legitimate DLL there will still be a problem with an exotic form of persistence, and if an additional vulnerability (say in a browser, for example) can be used to plant a malicious DLL at the beginning of the search path then we will once again be able to compromise a machine regardless of the current directory centric mitigations that are available right now.

the real problem with DLL search paths is that they exist at all. there should be no searching, no question of which DLL your process is trying to load or where to find it. so long as there is searching for DLLs, there exists the possibility of finding and loading the wrong one (the malicious one).