Hi @ll, in <http://seclists.org/fulldisclosure/2015/Nov/101> I showed general mitigations for DLL hijacking via runtime dependencies (<https://msdn.microsoft.com/en-us/library/ms685090.aspx>). DLL hijacking is but also possible via load-time dependencies (<https://msdn.microsoft.com/en-us/library/ms684184.aspx>)! Example: Quite some executable installers use the function timeGetTime() (<https://msdn.microsoft.com/en-us/library/dd757629.aspx>) implemented in WinMM.dll (and NO other function from WinMM.dll). BUT WHY? This function yields the same result as GetTickCount() (<https://msdn.microsoft.com/en-us/library/ms724408.aspx>) implemented in Kernel32.dll. The notable difference: WinMM.dll is NOT in the list of "known DLLs" (<https://support.microsoft.com/en-us/kb/164501>), so EVERY program which uses timeGetTime() from WinMM.dll instead of GetTickCount() will load a rogue WinMM.dll which exports timeGetTime from its application directory. This means: such programs are vulnerable to DLL hijacking unless run from SAFE locations like %ProgramFiles% or %SystemRoot% where unprivileged users can't place a rogue WinMM.dll etc. in the programs application directory. More general: if an executable installer links to functions not provided by "known DLLs" for all supported versions of Windows it is vulnerable to DLL hijacking via load-time dependencies, and there is NO mitigation except to run it from a safe location! Now that's a typical "catch 22": an installers task is to write the files of an application safely, i.e. without the possibility of tampering, to safe locations, i.e. %ProgramFiles% and %SystemRoot%, while the installer itself is located somewhere else, typically in a user's "Downloads" or %TEMP% directory, which are but unsafe and allow tampering via DLL hijacking. TELL YOUR USERS! TELL YOUR CUSTOMERS! WARN THEM! Or (better!): reduce your programs dependencies, i.e. stick to the basics^Wfunctions provided by Kernel32.dll (and the other "known DLLs") and eliminate the attack vectors for DLL hijacking via WinMM.dll and other "unknown DLLs". If you don't or can't: see above and WARN ALL YOUR USERS/CUSTOMERS! JFTR: the list of "known DLLs" varies with different Windows versions! Examples: 1. Version.dll was one of the "known DLLs" of Windows NT 5.x (resp. still is in Windows Embedded POSReady 2009): the (many) executable installers linked to its functions were/are therefore not vulnerable in Windows NT 5.x resp. Windows Embedded POSReady 2009. In newer versions of Windows Version.dll is none of the "known DLLs", so all executable installers using its functions became vulnerable to DLL hijacking then. 2. SetupAPI.dll is none of the "known DLLs" in Windows NT 5.x, but became so in newer versions of Windows: the (many) executable installers linked to its functions were/are vulnerable unter Windows NT 5.x resp. Windows Embedded POSReady 2009, but ain't vulnerable any more in all newer versions of Windows. Conclusion: executable installers which link to "unknown DLLs" are in general unsafe for normal users. The only SAFE option for general use is: DUMP executable installers. stay tuned Stefan Kanthak
