我正在尝试 ASLR 在 Centos 7.2.1115 x86_64 中的工作方式。
这是我/proc/$pid/maps两次运行 Firefox（在 Pastebin 上）的转储：
#1
#2
基本上，ASLR 有效。它随机化 .data 和 .text 偏移量。
但是，它以相同的顺序打包所有库和可执行文件，并且没有间隙。（嗯，大多数情况下。有几个变化，但它们看起来纯粹是偶然的。）
因此，一旦单个地址被泄露，ASLR 的整个部分就会消失。
我的问题是，这是现在常见的情况吗？哪些系统可以解决这个问题以及如何解决？
我的意思是，64位地址空间很大，你可以随机把每个库扔到它上面，然后检查它是否与任何东西重叠，最多重试几次后成功放置。然而，我通过谷歌搜索找到的最好的已经实现的解决方案是 Android 上的库加载顺序随机化。
但是，它以相同的顺序打包所有库和可执行文件，并且没有间隙。因此，一旦单个地址被泄露，ASLR 的整个部分就会消失。
不完全的。ASLR 仍然可以减少盲目利用的机会，帮助防止攻击者可靠地跳转到执行点。如果您不知道要覆盖的特定点，那么您的下一个策略就是 NOP 雪橇附近的内存。再加上起始地址是随机的，无论碎片如何，您都可能会在永不着陆的地方挑选一些有用的代码。
我的意思是，64 位地址空间很大，你可以随机把每个库扔给它，然后检查它是否与任何东西重叠，最多重试几次后成功放置。
没错，但这会导致性能问题。每个随机化条目都将需要TLB中的一个条目，从而导致更高的资源利用率和更多由于块对齐而被浪费/未使用的内存。
我的问题是，到目前为止，这是常见的情况吗？哪些系统可以解决这个问题以及如何解决？
由于上述原因，这确实是常见的情况。了解攻击的局限性有助于理解为什么使用更昂贵的“无处不在的内存位”的好处有限。
加分点：最常见的利用是将过多的数据写入数据块，然后执行它。NX位也是一个重要的对策。