DLL 预加载攻击。 kernel32.dll 从应用目录加载系统库答案

【问题标题】：DLL preloading attack. kernel32.dll loads system libraries from application directoryDLL 预加载攻击。 kernel32.dll 从应用目录加载系统库
【发布时间】：2015-02-20 17:13:38
【问题描述】：

似乎 kernel32.dll 没有使用它加载的某些 DLL 的完全限定路径，这就是为什么它们可以从应用程序目录（加载应用程序的目录）加载的原因。例如，这些 DLL 是：fltlib.dll、version.dll、dbghelp.dll

这真的很危险，这是一个安全问题，因为应用程序无法控制此加载。不支持延迟加载 Kernel32.dll，因此我们不能使用 SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32)，因为这一切都发生在用户代码之前！ SetDllDirectory("") 也没有用，而且它只排除当前目录而不是应用程序目录。 CWDIllegalInDllSearch 没有帮助，因为它也只排除当前目录而不是应用程序目录。

所以，这个信息：

没用！它没有给出任何实践答案如何保护应用程序免受这种 DLL 预加载攻击。

当然，您可以说所有程序都在“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% 前缀）。因此，只需启用从它们所在的路径（%windir%\system32、%windir%\syswow64、%windir%\winsxs 等）加载系统 DLL。这真的很奇怪，为什么主系统库（如 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 中，真的很简单。如果应用程序将从这些 DLL 中调用某些函数，您可以模拟真正的 API 函数并执行一些代码！ 2. 将这些 DLL 中的任何内容放入任何应用程序（Internet Explorer 或 Windows Live Mail 或任何其他）的应用程序目录 3.看看会发生什么))

我可以给你一个这样的 DLL 的例子。这是工作！我只是简单地显示一些消息而不是一些恶意软件代码。

如何让微软解决这个问题？

我在这里试过：сonnect.microsoft.com/VisualStudio/feedback/details/1139089 但还是一片寂静……

【问题讨论】：

我在这里尝试过：connect.microsoft.com/VisualStudio/feedback/details/1139089 但是还是沉默......
你有什么问题？
@harryj 如何让微软解决这个问题？
好的，这不是这里的主题。投票结束。（你可以试试微软的论坛，但实际上你永远无法让微软相信这确实是一个安全漏洞。）
请注意，如果攻击者是管理员，还有很多其他方法可以将错误代码注入您的应用程序 - 他们可以安装兼容性修复程序，例如，指示 Windows 在您的应用程序时加载其 DLL正在运行。或者安装系统服务。或用户模式设备驱动程序。或数十种其他方式中的任何一种。在这种情况下，确实有太多可能的攻击来消除它们。此外，如果您的应用程序不在 Program Files 中，那么您（或系统管理员）有责任确保该目录具有适当的权限。

标签： windows security dll kernel32

【解决方案1】：

如果他们可以写入您的应用程序目录，则他们已经拥有您的系统。当他们可以覆盖您的主应用程序的恶意版本时，为什么还要担心他们编写恶意版本的 dbghelp.dll。

换句话说，如果您给予某人该级别的控制权，那么他们就有更简单的方法来做恶意的事情。

【讨论】：

> 他们可以覆盖您的主应用程序的恶意版本。 即使它会被数字签名？ :)) 对于应用程序和用户来说，关键词是“静默”，也“容易”利用此漏洞。还有你没看到的主要内容：为什么主系统库（如 kernel32.dll）会从应用程序目录中加载它使用的系统库，而根据定义它不能是这样的？
Windows 不需要对可执行文件进行数字签名，因此如果有人恶意覆盖或修改了应用程序的可执行文件，您在运行应用程序时不会收到警告。规则是应用程序目录中的所有内容都是可信的。
但是，如果系统管理员愿意，可以通过软件限制策略实施白名单。
@harryj Windows 不需要对可执行文件进行数字签名，因此如果有人恶意覆盖或修改了应用程序的可执行文件，您在运行应用程序时不会收到警告。 我会知道的。如果我在数字签名的 EXE 文件中进行验证。最终用户也可以手动检查我的应用程序是否有数字签名。 规则是应用程序目录中的所有内容都是可信的。 这是非常糟糕的规则！
@harryj 一切......都是可信的听起来很糟糕而且目光短浅！但问题不在于此，而是：为什么微软让 kernel32.dll 从应用程序目录中加载它使用的系统库，而根据定义它不能是这样的？