Seems to be kernel32.dll doesn't use a fully qualified path to some DLLs which it loads and that's why they can be loaded from application directory(the directory from which the application loaded). For example, these DLLs are: fltlib.dll, version.dll, dbghelp.dll
It's really dangerous and this is a security issue, because there are no any possibilities for app to make control over this loading. Delay loading Kernel32.dll is not supported, so we can't use SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32) because all happens before user code! SetDllDirectory("") also useless and moreover it excludes only current directory not application directory. CWDIllegalInDllSearch doesn't help because it also exclude only only current directory not application directory.
So, this info:
is USELESS! It doesn't give any practise answers how to protect an application from this DLL preloading attack.
Of course you can say that all programs are in "Program Files" directory and only administrators can write to these directories. But not all apps are in "Program Files" directory. Besides all know that very often users have administrator accounts and that's why it's very simple to install one of these malware DLL silently to some application's directory and get a silent control over ANY application, because this malware DLL can emulate(read use real functions from real DLLs) all system API functions from real DLL to the application, so application never know that it uses malware DLL! Besides in this way malware DLL can bypass FIREWALL! For example if you copy some of malware DLL to the browser directory(it can be anything: Internet Explorer, FireFox, Chrome or any other) some malware code will be act as browser, which already have an allowing rule in the firewall settings, usually outgoing connections to ports 80,443,53. It's really a potential hole for leaks!
Of course it's possible to make post-loading checks and if found such malware DLLs unload them and delete. But it's bad decision because if malware DLL already loaded to the application address space it can do anything what it wants and that's why unloading and deleting it after it already loaded can be useless!
These DLLs are absent here: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs But a recomendation to add them to this registry entry is not a good idea for end user. Besides, how many of them can be? I don't know.
Decision: Just DISABLE loading system DLLs from others paths except system paths (with %windir% prefix). So just enable loading system DLLs from paths, where they are located (%windir%\system32, %windir%\syswow64, %windir%\winsxs and so on). It's really strangely why the main system library (like kernel32.dll) loads system libraries which it uses from application directory where it can't be by definition! All system DLLs must be loaded only from paths with prefix %windir% or some other system paths, but not from application directory path, not from current directory path, not even from the paths that are listed in the PATH environment variable.
Steps to reproduce: First way(simple, just to see what paths will be for loaded DLLs ). 1. Put any from these DLLs: fltlib.dll, version.dll, dbghelp.dll to the application directory for ANY application (Internet Explorer or Windows Live Mail or any else) 2. See what paths have these loaded DLLs
Second way. 1. Make your own DLLs with the names: fltlib.dll, version.dll, dbghelp.dll And add your own code to DLL_PROCESS_ATTACH It's really simple. If app will call some functions from these DLLs you can emulate real API functions and do some your code! 2. Put any from these DLLs to the application directory for ANY application (Internet Explorer or Windows Live Mail or any else) 3. See what happens ))
I can give you an example of such DLL. It's work! I just simply show some message instead of some malware code.
How to make Microsoft solve this issue?
I tried here: сonnect.microsoft.com/VisualStudio/feedback/details/1139089 But yet the silence...
