似乎是kernel32.dll没有使用它加载的某些DLL的完全限定路径，这就是为什么可以从应用程序目录（加载应用程序的目录）加载它们的原因。例如，这些DLL是：fltlib.dll，version.dll，dbghelp.dll
这是非常危险的，这是一个安全问题，因为应用程序没有任何可能控制此加载。延迟加载Kernel32.dll不受支持，因此我们不能使用SetDefaultDllDirectories（LOAD_LIBRARY_SEARCH_SYSTEM32），因为所有都发生在用户代码之前！ SetDllDirectory（“”）也没用，而且它只排除当前目录而不是应用程序目录。 CWDIllegalInDllSearch没有帮助，因为它也只排除当前目录而不是应用程序目录。
所以，这个信息：
https://msdn.microsoft.com/en-us/library/windows/desktop/ff919712%28v=vs.85%29.aspx
是USELESS！它没有给出任何练习答案如何保护应用程序免受此DLL预加载攻击。
当然，您可以说所有程序都在“Program Files”目录中，只有管理员才能写入这些目录。但并非所有应用都在“Program Files”目录中。除了所有人都知道，用户经常拥有管理员帐户，这就是为什么将这些恶意软件DLL中的一个静默安装到某个应用程序的目录并对任何应用程序进行静默控制非常简单，因为这个恶意软件DLL可以模拟（读取使用实际的真实函数） DLLs）从真正的DLL到应用程序的所有系统API函数，所以应用程序永远不知道它使用恶意软件DLL！除此之外，恶意软件DLL可以绕过防火墙！例如，如果您将一些恶意软件DLL复制到浏览器目录（它可以是任何东西：Internet Explorer，FireFox，Chrome或任何其他），一些恶意软件代码将充当浏览器，它在防火墙设置中已经有一个允许规则，通常到端口80,443,53的传出连接。这真的是泄漏的潜在漏洞！
当然可以进行加载后检查，如果发现此类恶意软件DLL将其卸载并删除。但这是一个糟糕的决定，因为如果恶意软件DLL已经加载到应用程序地址空间，它可以做任何它想要的东西，这就是为什么在已经加载后卸载和删除它可能是无用的！
这里没有这些DLL： HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ KnownDLLs 但是，将它们添加到此注册表项的推荐对最终用户来说并不是一个好主意。此外，他们中有多少人可以？我不知道。
决策： 只是禁用从系统路径以外的其他路径加载系统DLL（使用％windir％前缀）。因此，只需从它们所在的路径启用加载系统DLL（％windir％\ system32，％windir％\ syswow64，％windir％\ winsxs等）。 奇怪的是，为什么主系统库（如kernel32.dll）从应用程序目录中加载了系统库，而这些系统库根本无法定义！所有系统DLL必须仅从具有前缀％windir％或其他系统路径的路径加载，但不能从应用程序目录路径加载，而不能从当前目录路径加载，甚至不能从PATH环境变量中列出的路径加载。
重现的步骤： 第一种方式（简单，只是看看加载DLL的路径是什么）。 1.将这些DLL中的任何一个：fltlib.dll，version.dll，dbghelp.dll放到任何应用程序的应用程序目录中（Internet Explorer或Windows Live Mail或其他任何应用程序） 2.查看这些加载的DLL的路径
第二种方式。 1.使用以下名称创建自己的DLL：fltlib.dll，version.dll，dbghelp.dll 并将自己的代码添加到DLL_PROCESS_ATTACH这非常简单。 如果app会调用这些DLL中的某些函数，您可以模拟真正的API函数并执行一些代码！ 2.将这些DLL中的任何一个放入任何应用程序的应用程序目录（Internet Explorer或Windows Live Mail或其他任何应用程序） 3.看看会发生什么））
我可以举一个这样的DLL的例子。这是工作！我只是简单地显示一些消息而不是一些恶意软件代码。
如何让Microsoft解决此问题？
我在这里试过：сonnect.microsoft.com/ VisualStudio / feedback / details / 1139089 但是沉默......
答案 0 :(得分：2)
如果他们可以写入您的应用程序目录，他们已经拥有您的系统。当他们只能覆盖主应用程序的恶意版本时，为什么要担心他们编写恶意版本的dbghelp.dll。
换句话说，如果你给某人一定程度的控制权，那么他们就有更容易做恶意的事情。