问题标签 [aslr]

Windows 7 具有堆随机化和堆栈随机化功能。我怎么能管理它？它们如何影响我的应用程序的性能？在哪里可以找到有关其工作原理的更多信息？

我正在使用 Visual Studio 2008 开发 C++ 程序。我找不到该功能的任何编译器选项。

我正在为并行程序开发一个运行时系统，该系统可以利用跨多个进程的公共地址空间布局，可能分布在几个（千）节点上。很多时候，为这种环境构建的软件在默认启用地址空间随机化的 Linux 系统上运行，用户可能不希望或无法在系统范围内禁用它（通过sysctl -w kernel.randomize_va_space=0等）。这对并行程序施加了一些限制，并且可能会损害性能。因此，我们想弄清楚如何为我们构建的二进制文件禁用它。安全不是问题，因为该软件始终在受控环境中运行。

我找到了对各种标志和变量的引用，例如ET_EXEC, EF_AS_NO_RANDOM（显然从未合并？）和PF_RANDOMIZE，但我找不到任何描述我可以做些什么来设置这些标志的文档。一个理想的答案会告诉我哪个编译器/汇编器/链接器标志将禁用生成的二进制文件的随机化，以及它适用于哪些版本的工具链/内核。下一个最好的工具是在构建二进制文件后执行相同的操作。

由于我确信有人会建议它，我已经知道我们可以在运行时使用 进行此更改setarch -R，但最好将其记录在可执行文件中。

它看起来paxctl -rx应该可以解决问题，但它似乎不适用于不包含 PaX 补丁的内核中使用的当前方法。

它将如何更改代码，例如函数调用？

我在 VS2010 中编写程序，构建目标是 .NET 4。我相信DEP兼容性标志默认是打开的。真的吗？

.NET 默认情况下是否也与ASLR兼容，并且默认情况下我的进程是否打开了 ASLR，还是我必须在运行时请求它？

我在使用 FreeBSD 和大型 mmap 时遇到了一些麻烦。Linux 没有显示相同的问题。

在程序启动时，它总是可以获得 1 GB 的地图。但是，有一个重新加载操作，文件被替换和重新映射。新地图通常每次都会稍微大一点，因此它不能整齐地融入旧的 mmap 位置。这种重映射在 FreeBSD 上经常失败，但在 Linux 上几乎没有。（它在使用 ASLR 的 Linux 上更经常失败。FreeBSD 使用ASLR吗？）

我认为这是因为库加载了其他库以及在程序运行期间完成的内存分配导致了虚拟内存空间的碎片化。FreeBSD 的 malloc 实现或库加载可能有一些特殊性导致了这种情况。

我正在寻找一些我可以做的事情，以使其更有可能发挥作用。

我正在考虑的一件事是总是映射一个完整的 1 GB 空间，即使文件大小实际上可能是 890 MB。如果我能完成这项工作，那么我将始终有一个 1 GB 的插槽来将新的 895 MB 文件重新映射到其中。

ASLR和DEP是用于保护应用程序免受黑客攻击的两种技术。随着许多现代应用程序变得越来越具有安全意识，这些技术变得越来越重要。现在，我只关注 Windows 7 和这些技术。我想知道何时以及如何最好地使用这些技术，尤其是在使用 .NET 编译器以外的开发工具开发桌面应用程序时。（对于 .NET 安全性，这个问题将提供答案。）我对 Delphi 和 C++Builder 等编译器以及其他 WIN32 编译器特别感兴趣。基本上，我如何让这些应用程序同时支持 DEP 和 ASLR？有什么方法可以从我自己的（WIN32）代码中控制这些选项？

在 MSVC 中，Base Address Randomizaiton 是默认选项。（从 VS2005 开始？）

因此，我不再手动重新设置 dll 的基地址。

但是当我使用 VS2003 时，我重新设置了所有 dll 以提高加载性能。

如果我使用 ASLR 选项，加载性能总是下降？
（当然我可以得到其他好处）

我观看了 32 位进程的基于 ASLRed dll图像的地址。
这不是完全随机化。它只是随机化了 1/2 的概率。

例如，一旦我加载了一个 dll，图像就会加载到0x12345678上。
然后我再次加载图像，图像加载到0x23456789。（基地址已更改！）
但我再次加载图像
0x12345678
0x23456789
0x12345678
0x23456789
...

他们为什么这样做？
是因为崩溃报告的频率吗？（为了获得重新部署的 dll 的相同崩溃地址）

我听说过这个理论。地址空间位置随机化获取库并将它们加载到虚拟地址空间中的随机位置，这样如果黑客在您的程序中发现漏洞，他就没有预先知道的地址来执行返回 libc 攻击反对，例如。但想了几秒，作为防御手段，也没什么意义。

假设我们假设的 TargetLib（libc 或黑客正在寻找的其他任何东西）加载到一个随机地址而不是确定性地址。现在黑客并不提前知道 TargetLib 和其中的例程在哪里，但应用程序代码也不知道。它需要在二进制文件的某个地方有某种查找表，以便在 TargetLib 中找到例程，并且必须位于确定的位置。（或者在一个随机的位置，由其他东西指向。你可以添加任意数量的间接，但最终你必须从一个已知的位置开始。）

这意味着黑客不需要将攻击代码指向 TargetLib 的已知位置，只需将攻击代码指向应用程序查找表中 TargetLib 的条目，并取消引用指向目标例程的指针，攻击就会畅通无阻。

ASLR 的工作方式有什么我不明白的地方吗？因为如上所述，我看不出它只不过是一个减速带，提供了安全的形象，但没有实际的实质。我错过了什么吗？

我正在尝试使用 vsprops 文件将 ASLR 添加到项目中。我已验证该文件正在被项目使用，因为文件中还有其他设置正在被应用，并且在 MSVC 下打开项目时故意损坏文件会产生错误。当我将 ASLR 设置为时，yes我可以RandomizedBaseAddress="2"在<Tool Name=VCLinkerTool.

但是......它没有效果。我也可以放RandomizedBaseAddress="xxxxx"，它不在乎。就好像链接器的设置没有被拾取。我还尝试GenerateDebugInformation="True"了这是我看到其他 vsprops 文件使用的另一个设置，这也被忽略了。就好像链接器忽略了 vsprops 文件或其中的这些设置。

是什么赋予了？有没有人见过这个？