[置顶] 泰晓 RISC-V 实验箱,配套 30+ 讲嵌入式 Linux 系统开发公开课
LWN 121845: 内核 2.6 中地址空间的随机化
原文:Address space randomization in 2.6 原创:By corbet @ Feb. 2, 2005 翻译:By unicornx of TinyLab.org 校对:By Anle Huang
Arjan van de Ven has posted a series of patches which add some address space randomization to the 2.6 kernel. With these patches applied, each process’s stack will begin at a random location, and the beginning of the memory area used for
mmap()
(which is where shared libraries go, among other things) will be randomized as well. These patches represent an improvement in the kernel’s security infrastructure, but the reception on the public lists has been surprisingly hostile.
Arjan van de Ven 发布了一个补丁系列,为 2.6 内核添加了地址空间随机化功能。应用该补丁后,每个进程的栈(stack)空间的起始位置不再固定不变,除此之外,被 mmap()
用来映射(共享库以及其他一些内容)的内存区域的起始地址也将随机化。这些补丁体现了内核安全基础架构上的改进,但令人惊讶的是,从邮件列表上的回应来看并没有受到社区的一致欢迎,甚至还招致部分人的反对。
Many buffer overflow exploits, especially those used in large-scale attacks, contain hardcoded addresses. An exploit which overflows a stack variable will place some executable code on the stack; it then overwrites the return pointer so that the broken function “returns” into the exploit code. If you look at a given distribution’s shipped version of a vulnerable program, an exploit will always be able to place its payload at the same address on the stack, so it can contain that address directly. If, instead, the exploit author does not know ahead of time where the payload will end up, actually getting the computer to execute that code will be much harder.
许多针对缓冲区溢出(buffer overflow)漏洞的攻击程序(exploits),特别是那些用于大规模攻击的代码中,通常会包含一些硬编码的地址。攻击程序的运行机制是利用溢出漏洞在栈上放置一些恶意指令(译者注,在本文中也称之为 payload,即实际发挥攻击作用的指令);同时修改栈中的返回地址,诱导原函数 “返回” 到攻击程序预先放置的恶意指令中(并执行之)。如果查看某个发行版中含有漏洞的那个程序,其栈上可用于放置恶意指令的位置总是相同的,这也就是为何攻击程序中可以固定指定该地址的原因。反之,如果对于攻击程序的作者来说,该地址不固定,他就无法提前指定存放恶意指令的位置,那么攻击就很难实施。
That is why the stack randomization patch helps. When the stack location is deterministic, a relatively simple exploit can be made to work on all systems running the vulnerable distribution. If the stack moves, instead, hardcoded addresses no longer work.
这就是引入栈空间地址随机化补丁的原因。当栈位置是确定时,攻击程序相对来说编写起来就比较简单,而且可以在所有系统(特指运行存在漏洞程序的系统)上起作用。相反,如果栈的起始位置是随机变化的,则攻击程序就就无法通过硬编码的方式注入恶意攻击指令。
Moving the
mmap()
area has similar benefits. One popular type of exploit prepares the stack and then “returns” into a shared library somewhere. That return can, for example, cause the application to behave as if it had intentionally calledsystem()
or a similar library function. Moving the libraries around makes these attacks harder.
随机布置 mmap()
区域具有类似的好处。一种流行的攻击程序会利用栈溢出漏洞 “返回” 函数执行流程到某个共享库中执行特定的函数。这么做可以使得应用程序的行为看上去如同自己调用了 system()
或类似的库函数(译者注:system()
是标准的库函数,一般存在于 libc 共享库中)。将这些库文件的存放位置随机化也会使得类似的攻击变得更加困难。
One of the biggest complaints that has been raised is that the amount of randomization is insufficient. The patches, as posted, vary the stack base within a 64KB area and the
mmap()
base within a 1MB range. Alignment requirements prevent just any address from being used with the result that only a relatively small number of possible base addresses exists. So a determined attacker could repeatedly run a hardcoded exploit with some assurance that, within a reasonable amount of time, the stack would land at the right place and the exploit would work. Placing a long series of no-op instructions at the beginning of the payload can also make an exploit more robust when faced with randomization.
对该补丁的一个最大的抱怨是随机的范围不够大。在已发布的补丁中,栈基址只能在 64KB 的区间内随机生成,mmap()
区的基址的随机变化范围在 1MB 范围内。考虑到由于对齐的要求,并不是所有地址都可以使用,导致在上述范围内能用的基地址就更少了。所以,如果一个攻击者使用一个硬编码地址持续地尝试,那么只要时间允许,系统中总会出现一个栈区恰好落在期望的地址上,导致攻击可以成功。另外,在恶意指令的前面放置一串空操作指令(no-op instructions)也可以在地址随机化状态下提高攻击命中的概率。
Arjan responds that the amount of randomization is not the issue at the moment. He is trying to get the infrastructure into the kernel and tested in a minimally disruptive way; the degree of randomization can be tweaked upward later on. That amount may never get as high as some people would like, at least on 32-bit systems, because it cuts back on the available virtual address space. But it is likely to go up once the developers are convinced that things are working.
Arjan 回应说,目前随机的范围大小不是问题。他正试图将该机制纳入内核并在影响最小的前提下进行测试;随机程度可以稍后调整。但可能永远不会像某些人想象的那样高(至少在32位系统上),因为基地址随机后会导致可用的虚拟地址空间变小。一旦该特性经验证的确有用,他会尽快提高随机的范围大小。
In any case, a larger randomness makes the problem harder, but does not change its fundamental nature. With the ability to keep trying, an attacker will eventually get around any degree of randomization possible on 32-bit systems (64-bit systems are a different story). Thus, says Ingo Molnar:
总而言之,更大的随机性当然会使攻击更困难,但并不会改变该问题的实质。由于能够持续尝试,在 32 位系统上,攻击者最终总是可以绕过任何程度的随机化(当然 64 位系统是另一回事)。因此,Ingo Molnar 总结说:
conclusion: stack randomisation (and other VM randomisations) are not a tool against local attacks (which are much easier and faster to brute-force) or against targeted remote attacks, but mainly a tool to degrade the economy of automated remote attacks.
目前的结论是:栈的随机化(和其他虚拟地址的随机化)并不能从根本上解决本地攻击问题(采用蛮力,即持续尝试方式下本地攻击的成功速度会更快,破解更容易)或针对某个特定目标的远程攻击问题,但至少可以使得远程自动攻击付出更高的代价。
Randomization is not a magic bullet which solves a wide range of security problems. It does make an attack harder, however, and that can only be a good thing.
所以说,随机化并不是解决各种安全问题的灵丹妙药。然而,它的确使得攻击变得更加困难,这对我们来说只会是一件好事。
猜你喜欢:
- 我要投稿:发表原创技术文章,收获福利、挚友与行业影响力
- 知识星球:独家 Linux 实战经验与技巧,订阅「Linux知识星球」
- 视频频道:泰晓学院,B 站,发布各类 Linux 视频课
- 开源小店:欢迎光临泰晓科技自营店,购物支持泰晓原创
- 技术交流:Linux 用户技术交流微信群,联系微信号:tinylab
支付宝打赏 | 微信打赏 | |
请作者喝杯咖啡吧 |
Read Album:
- LWN 531148: Linux 内核文件中的非常规节
- Linux 内核的代码仓库管理与开发流程简介
- LWN 600644: 扩展内核栈
- LWN 563185: 优化抢占
- LWN 575497: 我们很快就可以有 Deadline 调度器了吗?