为什么有些DLL不是随机的？为什么很难为所有DLL部署完整的ASLR？

Question

为所有事物部署ASLR的挑战之一是，至少在Windows上，某些DLL(库)没有以与ASLR兼容的方式编译。(它们不是被编译成与位置无关的代码，因此它们被加载到内存中的位置不能随机化。)

这是有问题的，因为如果一个应用程序只加载一个非随机DLL，那么它实际上就不是随机的。为了阻止标准攻击(例如ROP攻击)，所有的代码都必须是随机的：即使是一个非随机DLL也足以使ROP攻击成为可能。因此，对于一阶近似，ASLR只有在所有DLL都是随机的情况下才能保护特定的应用程序。应用程序通常加载许多DLL，因为它只需要一个非随机DLL，因此确保所有DLL都是随机的显得尤为重要。

一般来说，这个行业正朝着增加随机化的方向发展，但是慢慢地：我想这需要时间把它带到任何程序都会使用的每个DLL中。例如，最近发现Dropbox不使用随机化.，因此任何使用Dropbox的程序都不受ROP攻击的保护(任何使用Dropbox的程序都会失去ASLR的好处)。

我的问题是:为什么一些DLL不是随机化的？它通常是某种技术障碍或技术问题，使得将DLL编译为独立于位置的代码变得困难或不可能吗？在构建DLL的开发人员中，是否缺乏对安全性的认识/关注？是遗留DLL非常古老，还没有被重新编译以利用随机性吗？默认情况下，Microsoft是否未能完成正确的操作(默认情况下，C++无法将DLL编译为独立于位置的代码)？完全是别的东西吗？

对于目前不支持随机化的DLL，是否有任何技术进步或工具可以帮助更多地部署ASLR/随机化？

相关资源：SlopFinder是一种工具，用于扫描系统中不支持ASLR的DLL。

Answer 1

有一些好的信息这里。显然，由于“向后兼容性问题”，只有将DLL标记为ASLR，DLL才能受ASLR的约束。虽然DLL本质上是要重新定位的，但我可以想象，一些(写得不好的)软件可能会做一些依赖DLL的技巧，这些技巧最终会出现在地址空间的相对较小的范围内(可能的候选是一些需要区分“数据指针”和“代码指针”的垃圾收集器 --我知道，当Chrome的Javascript解释器在Linux模拟的OpenBSD上启动时，出现了这样的问题)。

如果微软遇到了实现额外标志的麻烦，那么他们至少会遇到一种他们不能忽视的情况(在Windows世界中，向后兼容性是非常重要的)，这是合理的，如果不可能的话。

因此，DLL将允许ASLR发生，如果静态链接器这样说，当DLL最后一次构建。这是一个使用/DYNAMICBASE标志的问题。文档指出：

默认情况下，/DYNAMICBASE是打开的。

Visual 2010和2012的文档包含这句话，但不包含Visual 2008的文档。因此，必须假设大多数使用Visual 2010+的人都会生成与ASLR兼容的动态链接库，但大多数使用Visual 2008或以前版本的人都会生成不受其约束的DLL。

在上面的第一页链接中，有一条评论说：

在您的PE映像生成之后，您仍然可以使用Microsoft链接器来完成此操作。使用链接/edit /dynamicbase (或editbin /dynamicbase )。

因此，您可以“修复”一个DLL，但这是假设DLL不会与ASLR中断，也就是说，缺少标志只是因为DLL供应商使用的Visual的默认配置。