问题标签 [aslr]

Windows 8 中的堆随机化算法（用于分配堆内存）是否适用于 32 位和 64 位进程？还是仅适用于 64 位进程？

谢谢！

我目前正在我编写的一个小程序上测试一些漏洞利用，并想知道是否有一种方法可以“编码”类似 ASLR 的保护 - 或者只是使用一些编译技巧来制造它 - 限制可能的偏移值（像16）。

什么是 ASLR：http ://en.wikipedia.org/wiki/Address_space_layout_randomization

另外，如果这有任何帮助，我正在使用 i686-w64-mingw-gcc 来编译我的源代码，也许已经有一个选项（但我没有找到）。

谢谢 ！

目的是获取 AES 的 openssl 实现中预计算表的地址。这些表包含在aes_core.cinfo address SYMBOL_NAME文件中，并命名为Te0 、Te1 等。我正在尝试使用gdb.

所以这些是我到目前为止所遵循的步骤：

• 禁用 ASLR ( sudo sysctl kernel.randomize_va_space=0)
• 编译 openssl (version 101e)configure -d shared以保持调试符号
• 将程序链接到上面提到的 openssl 版本（我确保info sharedlibrary在 gdb 中使用）
• 在 gdb 中运行程序并使用info address Te0（或任何其他表）

结果：No symbol "Te0" in current context.

private_AES_set_encrypt_key例如，函数（也在aes_core.c中）不会发生同样的情况。事实上，在这种情况下，结果是：Symbol "private_AES_set_encrypt_key" is at 0x7ffff7a483f0 in a file compiled without debugging.这正是我所需要的。

我的想法：这些表是这样声明的，static const所以我猜它们可能会以某种方式进行优化，但是我再次有意编译 openssl 以支持调试。那么为什么我在 gdb 中看不到这些符号呢？

预先感谢您的帮助！

我正在尝试进行缓冲区溢出攻击。

我使用以下命令禁用了地址空间布局随机化 (ASLR)：sudo sysctl -w kernel.randomize_va_space=0

我不想让程序崩溃，而是通过使用缓冲区溢出覆盖堆栈上的返回地址以指向包含 printf() 语句的 target() 函数地址并打印代码中的“Holla.. Holla..”语句呼啦……呼啦……而不是让程序崩溃

我正在使用以下代码：

我目前正在阅读计算机系统简介：程序员的观点（http://www.amazon.com/Computer-Systems-Programmers-Perspective-2nd/dp/0136108040/ref=sr_1_2?s=books&ie=UTF8&qid=1421029641&sr=1 -2&keywords=introduction+to+computer+systems）并尝试了解阻止缓冲区溢出的方法。

我理解为什么在使用地址随机化以及如何编写漏洞利用时我们需要 NOP sleds，但我无法理解书中给出的与 NOP sleds 相关的地址计算。我将在这里引用它：-

（假设堆栈上程序的起始地址在 32 位系统上的范围为 2^23，在 64 位系统上为 2^32）

“如果我们设置一个 256 字节的 NOP sled，那么 n=2^23 上的随机化可以通过枚举 2^15 个起始地址来破解，这对于坚定的攻击者来说是完全可行的。对于 64 位的情况，尝试枚举 2^ 24 个地址更令人生畏。”

作者是如何分别得出 32 位和 64 位情况下的数字 2^15 和 2^24 的？一个解释会非常有帮助。

我们知道我们可以通过将代码编译为 PIE 来随机化代码、数据/堆栈/堆。而代码和数据在每次加载时总是有一个固定的偏移量。

有没有办法通过添加一些编译/链接标志我们可以将代码/数据偏移设置为随机值？

我一直在阅读有关 ASLR 的信息，并且有几个问题。我几乎没有编程经验，但我对它背后的理论很感兴趣。

我知道它会随机化 DLL、堆栈和堆在虚拟地址空间中的位置，以便恶意代码不知道它们的位置，但是实际程序在需要它们时如何知道它们的位置？

如果合法进程可以找到它们，那么是什么阻止了恶意代码做同样的事情呢？

最后，ASLR 试图阻止的恶意代码是否在它正在攻击的进程的用户空间中运行？

谢谢

我对 ASLR 很熟悉，但是今天我听到了一个关于在 Windows 中实现 ASLR 的新有趣事实。

如果进程 A 和 B 加载相同的 dll，为了优化性能，Windows 只会将其加载到物理内存一次，并且两个进程将通过共享页面共享同一个实例。

这是旧消息.. 但有趣的部分是进程 A 和 B 都将在相同的虚拟地址中加载共享库（为什么？？）。

在我看来，任何本地攻击（例如权限提升）都可以通过以下方式轻松绕过 ASLR：

我使用 Olly 做了一些简单的测试，发现共享库确实加载在同一个虚拟地址中。

如果真的是这样，那么 ASLR 对本地开发毫无用处吗？

我在启用了 ASLR 的开发盒上运行了这段 C 代码。它正在向函数返回一个 char 指针 (char *)，但返回的指针地址中的几个字节不知何故发生了变化，下面的 printf 输出：

char 指针0x00007f0b8e7fc120被返回到另一个函数，该函数被修改，因为0xffffffff8e7fc120它与原始指针地址相差一个字（4 字节）0xffffffff而不是0x00007f0b，最后四个字节（8e7fc120）相同。知道会发生什么吗？以及我该如何解决这个问题。该代码在 Intel Xeon 上的 linux 64 位架构上运行。这段代码来自一个现有的专有库，所以我不能分享确切的代码，但代码逻辑看起来像这样：

retadd 和 m1.addr 在 ASLR 开启时是不同的。

我下周要复习考试，我遇到了一个过去的问题。

认为;

• 根本没有防备
• buf 从 0xbffebfb0 开始
• (gdb) x/2wx $ebp 0xbffebfd8: 0xbffec068 0x08048fe1

a) 你想运行一个 24 字节长的有效载荷，应该将哪些字节复制到缓冲区中以进行攻击？（我想为 24 个字节填写 '\x90'）

b) 如果启用了 ASLR，每次运行时将堆栈偏移 0-15 个字节，那么什么有效负载（在 python 打印语句中描述）将始终让上面的 shellcode 执行？或者为什么这样的有效载荷是不可能的？