ASLR如何有效？
我听说过这个理论。地址空间位置随机化获取库并将其加载到虚拟地址空间中的随机位置，因此，如果黑客在您的程序中发现漏洞，他就没有预先知道的地址来执行返回到 libc 的攻击反对，例如。但想了几秒，这作为防御措施并没有任何意义。
假设我们假设的 TargetLib（libc 或黑客正在寻找的任何其他内容）加载到随机地址而不是确定性地址。现在，黑客事先并不知道 TargetLib 及其内部例程在哪里，但应用程序代码也不知道。它需要在二进制文件中的某个位置有某种查找表，以便查找 TargetLib 内部的例程，并且该表必须位于确定性位置。 （或者在随机位置，由其他东西指向。您可以添加任意数量的间接，但最终您必须从已知位置开始。）
这意味着他的攻击代码不是指向 TargetLib 的已知位置，黑客所需要做的就是将其攻击代码指向应用程序的查找表的 TargetLib 条目，并取消引用指向目标例程的指针，攻击就可以畅通无阻地进行。
ASLR 的工作方式有什么我不明白的地方吗？因为正如所描述的，我不明白这只是一个减速带，提供了安全的形象，但没有实际的实质内容。我错过了什么吗？
I've heard the theory. Address Space Location Randomization takes libraries and loads them at randomized locations in the virtual address space, so that in case a hacker finds a hole in your program, he doesn't have a pre-known address to execute a return-to-libc attack against, for example. But after thinking about it for a few seconds, it doesn't make any sense as a defensive measure.
Let's say that our hypothetical TargetLib (libc or anything else the hacker is looking for) is loaded at a randomized address instead of a deterministic one. Now the hacker doesn't know ahead of time where TargetLib and the routines inside it are, but neither does the application code. It needs to have some sort of lookup table somewhere in the binary in order to find the routines inside of TargetLib, and that has to be at a deterministic location. (Or at a random location, pointed to by something else. You can add as many indirections as you want, but eventually you have to start at a known location.)
This means that instead of pointing his attack code at the known location of TargetLib, all the hacker needs to do is point his attack code at the application's lookup table's entry for TargetLib and dereference the pointer to the target routine, and the attack proceeds unimpeded.
Is there something about the way ASLR works that I don't understand? Because as described, I don't see how it's anything more than a speed bump, providing the image of security but no actual substance. Am I missing something?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我相信这是有效的，因为它改变了共享库的基地址。回想一下，从共享库导入的函数在加载时会被修补到可执行映像中，因此本身没有表，只有指向分散在程序代码中的数据和代码的特定地址。
它提高了有效攻击的门槛，因为它将简单的缓冲区溢出（可以设置堆栈上的返回地址）变成了溢出必须包含确定正确位置的代码，然后跳转到它。想必这只会让事情变得更加困难。
实际上，Windows 中的所有 DLL 都是针对基地址进行编译的，它们可能不会在该基地址上运行，并且无论如何都会被移动，但核心 Windows 往往会对其基地址进行优化，以便不需要重定位。
I believe that this is effective because it changes the base address of the shared library. Recall that imported functions from a shared library are patched into your executable image when it is loaded, and therefore there is no table per se, just specific addresses pointing at data and code scattered throughout the program's code.
It raises the bar for an effective attack because it makes a simple buffer overrun (where the return address on the stack can be set) into one where the overrun must contain the code to determine the correct location and then jmp to it. Presumably this just makes it harder.
Virtually all DLLs in Windows are compiled for a base address that they will likely not run at and will be moved anyway, but the core Windows ones tend to have their base address optimized so that the relocation is not needed.
我不知道你的问题是否正确，但我会解释 ASLR 何时有效，何时无效。
假设我们有 app.exe 和 TargetLib.dll。
app.exe 正在使用（链接到）TargetLib.dll。
为了使解释简单，我们假设虚拟地址空间只有这两个模块。
如果两者都启用了 ALSR，则 app.exe 的基地址未知。它可能在加载时解析一些函数调用地址，但攻击者既不知道函数在哪里，也不知道解析的变量在哪里。加载 TargetLib.dll 时也会发生同样的情况。
尽管 app.exe 有一个查找表，但攻击者并不知道该表在哪里。
由于攻击者无法判断特定地址的内容是什么，因此他必须在不使用任何固定地址信息的情况下攻击应用程序。如果他使用堆栈溢出、堆溢出、释放后使用等常用的攻击方法，通常会更困难……
另一方面，如果 app.exe 未启用 ASLR，则攻击者更容易利用该应用程序。因为app.exe中的特定地址可能存在对感兴趣的API的函数调用，攻击者可以将该地址作为目标地址进行跳转。 （攻击应用程序通常从跳转到任意地址开始）。
补充：
你可能已经明白了，但我想澄清一件事。
当攻击者通过内存损坏等漏洞利用应用程序时，他通常被迫使用
固定地址跳转指令。他们无法使用相对地址跳转指令来利用。这就是 ALSR 对于此类漏洞确实有效的原因。I don't know if get you question correctly but I'll explain when ASLR is effective and when not.
Let's say that we have app.exe and TargetLib.dll.
app.exe is using(linked to) TargetLib.dll.
To make the explanation simple, let's assume that the virtual address space only has these 2 modules.
If both are ALSR enabled, app.exe's base address is unknown. It may resolve some function call addresses when it is loaded but an attacker knows neither where the function is nor where the resolved variables are. The same thing happens when TargetLib.dll is loaded.
Even though app.exe has a lookup table, an attacker does not know where the table is.
Since an attacker cannot tell what is the content of specific address he must attack the application without using any fixed address information. It is usually harder if he uses usual attacking method like stack overflow, heap overflow, use-after-free...
On the other hand, if app.exe is NOT ASLR enabled, it is much easier for an attacker to exploit the application. Because there may be a function call to a interesting API at specific address in app.exe and the attacker can use the address as a target address to jump. (Attacking an application usually starts from jumping to arbitrary address.).
Supplementation:
You may already understand it but I want to make one thing clear.
When an attacker exploit an application by vulnerability like memory corruption he is usually forced to use
fixed address jump instruction. They cannot userelative address jumpinstruction to exploit. This is the reason why ALSR is really effective to such exploits.