DLL Hijacking Just Won’t Die
I've used this behaviour --- non-maliciously --- multiple times in the past to override APIs for logging/tracing/debugging purposes. For example, I have a set of DLLs[1] that you can put in the same directory as the .exe of an application and it will log all network traffic that it generates. Very useful and convenient compared to the alternatives. Another use is to workaround compatibility problems.<p>What I find more saddening is the trend to view <i>any</i> behaviour that could potentially be exploited as a vulnerability, regardless of how useful it could be, which just leads to locked-down user-hostile systems where nothing is possible without going through some sort of ridiculously bureaucratic excess of process.<p>Thus, I think the root cause of this problem is not with the DLL loading behaviour, but with this...<p><i>The bad guy just navigates a frame of your browser to the DLL of his choice and, if you’re on Chrome or Microsoft Edge, the DLL is dropped in the Downloads folder without even asking</i><p>...entirely unconsented file download. The design of putting all downloads in one place is a small contributing factor.<p>[1] <a href="http://www.netresec.com/?page=Blog&month=2011-01&post=Proxocket---A-Winsock-Proxy-Sniffer" rel="nofollow">http://www.netresec.com/?page=Blog&month=2011-01&post=Proxoc...</a><p>Edit: we can also exploit this behaviour benevolently by putting a set of DLLs in the Downloads folder that would be loaded by any installers being run from there, which could do things like sandboxing/install logging. (Presumably browsers would be not so brash as to overwrite an existing file of the same name in there!?) It's not so bad after all...