【软件与系统安全笔记】五、内存破坏防御

最新推荐文章于 2024-05-28 10:57:08 发布

框架主义者

最新推荐文章于 2024-05-28 10:57:08 发布

阅读量1.2k

点赞数

分类专栏：二进制文章标签：系统安全安全

本文链接：https://blog.csdn.net/weixin_47102975/article/details/126822624

版权

二进制专栏收录该内容

11 篇文章 5 订阅

订阅专栏

【软件与系统安全】五、内存破坏防御

这是《【软件与系统安全】笔记与期末复习》系列中的一篇

虽然对缓冲区溢出的认知已超过 40 年之久, 但缓冲区溢出仍未被消除。部分原因在于存在大量的利用选项：

多样的目标: 不仅仅可以利用返回地址, 实际上可以利用任意代码地址或数据
多样的使用: 可以利用“读”或“写”操作
多样的利用方式: 对代码可以“注入”或“重用”
当前对溢出的防御措施多样, 但不完全

防御可以在不同的时机进行

编程前
开发过程中 (防御性编程)
测试时 (fuzzing, . . .)
代码运行时 (检测和缓解: stack canaries, DEP, . . .)

‍

Stack Canaries 栈金丝雀

是栈溢出的检测机制, 又称“栈 cookies”，由 gcc 的 StackGuard 实现

原理：将一个 dummy 值(或随机值)写到栈上的返回地址之前,并在函数返回时检查该值。不小心构造的栈溢出(假定是顺序栈粉碎)会覆写该“canary”单元, 该行为将被探测到。

攻破 StackGuard 的基本方法

对 canary 单元, 用正确的值覆写

如果 canary 所使用的随机值范围很小, 则枚举每种可能性
或先实施一个 memory disclosure 攻击, 获知 canary 的值

无法抵御 disclosure 攻击是 StackGuard 的最大局限性

disclosure 攻击通过对缓冲区的“overread”实现
著名例子: 对 SSL 的 Heartbleed 攻击
以下程序为什么会对 Stackguard 的 canaries 造成威胁?
- 通过对缓冲区的“overread”, 攻击者读取超出栈缓冲区之外的值, 从而获取 canary 的值

char packet[10];
…
// suppose len is adversary controlled
strncpy(buf, packet, len);
send(fd, buf, len);

有时不需要覆写返回地址, 可以溢出:

安全敏感的局部变量
堆数据
全局数据
· · ·
本质上, 攻击者只需要劫持一个函数指针

劫持函数指针

void foo () {...}
void bar () {...}
int main() {
    char buf [16];
    void (*f) () = &foo;
    gets(buf);
    f();
}

假定我们没有机会溢出返回地址

可溢出缓冲区, 使得函数指针被修改为 bar 的地址, 然后函数调用将调用 bar 而非 foo

劫持函数指针的其他方法

使用堆溢出，对堆上的函数指针进行劫持
劫持全局函数指针
劫持全局偏移量表(GOT)中的函数指针, 被动态链接函数所使用

‍

攻破 StackGuard 的其他方法

有时不需要覆写返回地址, 可以溢出:

安全敏感的局部变量
堆数据
全局数据
- 全局数据溢出: 攻击位于全局数据区的缓冲区
· · ·

如何防御?

让函数指针位于其他类型数据的下方(更低地址)
在全局数据区和其他管理表结构之间使用守卫页

守卫页(Guard Pages)

也是一种运行时检测方法, 可以看作StackGuard的扩展

在一个进程地址空间中关键内存区域之间放置守卫页 (像一些gaps)

需借助CPU内存管理单元(MMU)的管理功能将它们标记为非法地址
任何对其的访问尝试都导致进程被终止

效果: 能失效缓冲区溢出攻击, 特别是对全局数据区的溢出攻击

甚至可以在栈帧之间、或者堆缓冲区之间放置守卫页

可以提供更进一步的保护, 防止栈溢出和堆溢出攻击
会导致执行时间和内存的很大开销, 因为要支持大量页映射

‍

数据执行保护(DEP)

冯诺依曼体系结构

将代码作为数据存储
使得攻击者可以向栈或堆注入代码, 而栈和堆原本只应该存储数据

哈佛架构

虚拟地址空间切分为一个数据区和一个代码区
代码区可读且可执行
数据区可读且可写
没有区域是既可写又可执行的

Data Execution Prevention （数据执行保护）: 是一种运行时缓解技术

DEP又称作Nx-bit (non executable bit), W⊕X

能够阻止代码注入攻击

很多缓冲区溢出攻击涉及将机器码复制到目标缓冲区, 然后将执行转移到这些缓冲区

一种防御方法就是阻止在栈/堆/全局数据区中执行代码, 并假定可执行代码只能出现在进程地址空间中除这些位置外的其他位置需要CPU内存管理单元(MMU)提供支持, 将虚拟内存的对应页标记为不可执行
对于每一个被映射的虚拟内存页, 都有这样额外的1个no-executebit, 置位时, 表示该页的数据不能作为代码执行, 一旦程序控制流到达该页, CPU会产生陷入

DEP 被绝大多数操作系统和指令集体系结构支持

一些CPU早有支持(如Solaris的SPARC), 只需修改Solaris内核参数即可启用
x86系列后来才向MMU中加入no-execute位
Linux/Unix类系统, Windows均已提供相应扩展, 支持使用DEP特性

对 Nx-bit 的不同叫法

Intel: XD (eXecute Disable)
AMD: Enhanced Virus Protection
ARM: XN (eXecute Never)

如果CPU硬件支持, DEP可作为操作系统更新, 通过更改对进程虚拟地址空间的内存管理, 提供对现有漏洞程序的保护

DEP将栈和堆置为不可执行, 对多种缓冲区溢出攻击提供了一种高度的保护

但有一些合法程序需要将可执行代码放在栈上：

如Java运行时系统、运行时代码生成、Linux信号处理程序等
需要针对这些需求制定一些专门条款(Special provisions)

‍

攻击 DEP——代码重用攻击

思路: 重用程序自身的代码

Return-to-libc: 用危险的库函数的地址替换返回地址

代码重用攻击: Return to libc

危险库函数如 system()

攻击者构造合适的参数(在栈上, 返回指令指针的上方)

在x64架构上，还需要更多的工作：设置参数传递寄存器的值

函数返回，库函数得到执行

例如：execve(“/bin/sh”)

甚至可以链接两个库函数调用

‍

具体地

攻击者用一个溢出填充buffer:
- 更改栈上保存的ebp为一个合适地址
- 更改返回指令指针为一个欲执行的库函数的地址
- 写一个占位符值(库函数会认为其是返回地址,如果想利用它调用第二个库函数, 应写入第二个库函数的地址)
- 写一个或多个要传递给此库函数的参数
当被攻击的函数返回时, 恢复(更改过的)ebp, 然后pop更改后的返回地址到eip, 从而开始执行库函数代码
因为库函数相信它已被调用, 故会将栈顶当前值(占位符)作为它自己栈帧的返回指令指针, 之上是参数
最终会在占位符位置的下方创建起一个新的栈帧 (对应于库函数的执行)
根据库函数参数类型以及库函数对参数的解释方式, 攻击者可能需要准确地知道参数地址以做溢出写