写这篇内容的起因是我前段时间在自己搭的一个模拟漏洞环境里做栈溢出实验。当时目标程序开启了常见的栈保护选项结果连续几个晚上都在和一段不可名状的随机数据搏斗——每次溢出都稳定地触发stack smashing detected程序直接终止ESP和返回地址眼看着到手边又飞走。后来我意识到问题不在攻击手法本身而是我压根没搞清楚canary 在什么时候出现、什么时候校验、哪些路径根本不会碰它。这篇文章就是把这些思考沉淀下来canary 保护的底层机制、业界常用的绕过手法及其成立条件、一个完整演示案例的调试全过程以及现代防护体系下绕 canary到底意味着什么。对 CTF 选手、漏洞研究入门者、以及想理解栈防护边界的安全开发同学应该都能有些参考价值。1. canary不是拦路虎先搞清楚它到底在保护什么1.1 从一次崩溃现场说起先回到那次调试现场。一个很普通的 64 位程序栈上有个 0x20 字节的缓冲区后面跟着局部变量。我用常规的 A 字符填充触发溢出结果程序在返回时直接崩溃。注意这个崩溃点很有讲究——它不是在写入缓冲区的时候立刻崩的而是等到函数即将ret时才崩。这说明栈保护机制是在函数返回前做了一次体检。x86-64 下的典型栈布局大概是这样的地址从高到低高地址 --------------------------- | 参数区 / 其他变量 | --------------------------- | 返回地址8字节 | --------------------------- | 调用者 RBP8字节 | --------------------------- | canary8字节 | --------------------------- | 局部缓冲区 | -- 溢出点在这里 --------------------------- 低地址canary 被放在局部缓冲区和 RBP/返回地址之间。程序编译时插入了生成 canary和校验 canary两段代码。进入函数时会从某个随机源取出一个值放进这个位置函数返回前会重新读取并与之比较。一旦不相等直接调用专门的错误处理函数终止进程。我直到现在都记得第一次看这个布局时的感受这玩意儿本质上就是一个栈上的哨兵它的存在不是为了防溢出写入而是为了确保任何从低地址向高地址的连续覆盖都必定经过它。所以你填充数据时只要想碰到 RBP 和返回地址就一定会先覆盖 canary。程序的逻辑很简单——发现哨兵被动过说明栈内容被破坏了那返回地址也极可能不可信索性直接终止。1.2 canary的一生生成、加密、校验与差异搞清楚布局只是第一步更关键的问题是这个哨兵值从哪来为什么每次运行都不一样为什么它低位总是\x00在 glibc 环境下Linux x86-64线程局部存储TLS里专门有一个槽位保存随机 canary引用方式在汇编里通常是fs:0x28。程序每次启动时系统会生成一个随机数放入这个槽位之后所有函数的 canary 校验都对照这个值。正是这个随机性让攻击者没办法像之前那样直接猜出返回地址前的 8 字节。有一个细节很值得展开canary 的低位字节固定为\x00。为什么这要考虑按字符串读取的场景。如果一个能读内存的函数比如strcpy、printf(%s)恰好把 canary 所在的内存当作字符串输出遇到\x00就会自然截断这样攻击者就无法完整泄露 canary。同时这个\x00也在某种程度上保证了 canary 本身不会成为超长字符串的源头。反过来说如果 canary 是纯随机值、不含终止符那么一个缓冲区溢出通过strcpy就可以把它覆盖成任意内容——可校验时仍然要比较所以它的哨兵作用反而弱了。不同编译器对 canary 的生成策略还有差异。经典 GCC 有两种常见形态类型生成方式特点Random canary从随机源取 64 位 / 32 位随机值低位置零最常见每次进程启动都变Terminator canary由\n、\r、\xff、\x00等字节组成旧式实现防止破坏字符串函数XOR canary随机值再与返回地址异或某些编译器/加固选项下使用XOR canary 的校验逻辑会连同返回地址一起做运算等于把 canary 和返回地址绑定了。如果攻击者只覆盖 canary、不知道返回地址的原始值校验就一定失败反之如果只覆盖返回地址而 canary 保持原样校验同样失败。这种设计把两种数据的完整性绑定在一起比普通 canary更强一些。不过目前主流的 glibc/GCC 默认仍是随机 canary。校验代码本身也有一些值得注意的细节。正常函数的开头会有mov rax, qword ptr fs:[0x28]、mov qword ptr [rbp-8], rax这样的操作返回前再用xor rax, qword ptr [rbp-8]之类的指令做比较。如果被攻击者直接通过其他方式改写返回地址比如栈迁移函数根本不会走到校验逻辑——这一点是后面所有绕过思路的核心。2. 常见的绕过思路每一种手法背后都有一个决定性前提网上讲绕 canary 的资料不少但多数只给攻击模板不讲成立条件。我自己测试下来的体会是每种绕过手法的本质都是找到一个可以不经过 canary 校验或能让校验值本身变成可控的路径。这里按其实用性和前提条件逐类展开。2.1 泄露式绕过先读后填对付随机 canary 最直接的办法如果你能让程序主动把 canary 打印出来那 canary 的随机性就形同虚设。这类利用的核心是越界读能力而不是栈溢出本身。最经典的渠道是格式化字符串漏洞printf(user_input);如果用户输入里包含%p、%llx这类格式说明符printf 就会按可变参数的逻辑从栈上连续取值。注意这里的栈就是当前函数的栈而 canary 恰恰就保存在这个栈的固定位置rbp-0x8附近。只要输入的偏移正确canary 就能被当成一个普通参数泄露出来。具体怎么找偏移我一般用分界标记法AAAAAAAA%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p逐个偏移数过去直到在某个位置突然出现一串以0x开头、后八位以00结尾的 16 字节十六进制数。这个以 00 结尾的特征非常明显因为它就是 canary 的低位终止字节。64 位环境下 canary 通常是 8 字节打印出来形如0x65e20d8b001b3a00。另一种泄露渠道是越界读。有些程序会把栈上的内存块直接复制发送给客户端比如memcpy(send_buf, stack_buf, stack_size);如果stack_size实际超过了stack_buf的边界数据里就会带上 canary。这类场景在文件解析、协议处理程序里很常见测试时值得重点关注。泄露式的核心前提是你确实拥有某种越界读原语而且读的路径不会因 canary 的\x00而中断。如果用strcpy、sprintf(%s)这类以字符串为载体的函数泄露读到终止符就断了你必须想其他办法。这一点我在后面案例里会再踩一次。2.2 暴力猜测32位程序里 fork 出来的子进程canary 是稳定的对 64 位程序来说随机 canary 有 8 字节除掉低位\x00还有 7 字节暴力穷举不现实。但 32 位程序不同——canary 只有 4 字节低位固定为\x00实际需要猜的只有 3 字节最多2^24 16777216种组合。如果目标允许 fork这个数字就变得非常可行。关键是 fork 的行为fork 出来的子进程完全继承父进程的地址空间和 TLS也就是 canary 不变。这是暴力猜测能够成立的决定性前提。很多网络服务会为每个连接 fork 一个子进程来响应请求这意味着攻击者每次尝试失败的代价只是断掉一次连接子进程崩溃不影响父进程继续 fork 新的子进程。具体思路是这样连接服务器触发一次溢出用\x00作为 canary 第一位字节第二位第三位第四位依次尝试0x00到0xff观察程序是否继续正常运行没有触发 stack smashing 报错一旦某次填充后程序没有崩溃说明该字节猜对了逐字节穷举最后拼出完整 canary。32 位下穷举 3 字节并不可怕但最好在目标环境支持并发时做速度优化。我实际测试时单进程串行发包太慢用多线程同时尝试不同字节区间效果明显。判定成功的标志也很讲究——不能只看是否崩溃因为如果 canary 前几字节猜对了但后续字节填错照样会崩必须每次都从猜测中最低的那个字节开始采用由低到高渐进的方式。64 位下也有过暴力思路但理论成功率极低通常只存在于学术讨论或极端弱随机源场景实战中基本不考虑。2.3 间接改变控制流不触发 canary 校验的路径很多人被 canary 卡住是因为潜意识里认为要劫持控制流就一定要修改返回地址。其实返回地址只是控制流劫持的一种载体它上面的保护并不等于所有控制流都受保护。一个典型的思路是溢出覆盖局部变量。注意溢出方向是从低地址向高地址增长局部变量如果恰好排在缓冲区高地址方向之前比如某些结构体成员、索引值、大小字段会先于 canary 被覆盖。一个很著名的模式是索引型越界char buf[16]; int idx; memcpy(buf, user_input, strlen(user_input));如果idx在不经意间会被当作数组下标使用覆盖它就能实现任意位置读写。这种利用根本不需要碰 canary因为控制流转移发生在数组访问阶段函数到返回点之前可能根本没触发校验。另一个思路是修改栈上保存的函数指针。某些程序会把函数指针暂存在栈上比如调用回调的上下文结构体、注册的异常处理函数等。溢出数据流会先经过这些函数指针覆盖它们后程序在函数返回前就会去调用被篡改的地址。典型的例子是 Windows 下的 SEH 链覆盖但 Linux 下也有类似情况比如栈上保存了signal handler或atexit注册的回调指针结构体通过vtable调用虚函数局部构造的func_table、ops结构体。这类方式的核心前提是目标程序在栈上放了可控且可劫持的指针数据而不是一定要通过返回地址。实用性取决于你对程序数据布局的掌握程度。还有一种 回避式的做法是栈迁移。假设你不打算老老实实回到原函数返回地址而是直接把栈指针rsp转移到一块你完全可控的内存区域比如全局变量、堆缓冲区、.bss然后在那里接着执行 ROP 链。这样函数的返回值其实已经被绕过了——前提是你必须有一个能控制rsp的 gadget比如经典的leave; ret这个 gadget 把rbp传给rsp再执行ret。如果攻击者能控制rbp指向的数据看起来像一串地址这条链就能跑起来。注意它不需要触发 canary 校验因为这个函数根本不按正常返回的路径走——但前提是你已经可以通过某条路径改写rbp或者栈上的数据。2.4 TLS canary覆写釜底抽薪式的极端手法前三种方式本质上是绕过还有一种更彻底的方式直接让 canary 的参照值变成我们可控的值。因为 canary 校验是和 TLS 中的原始值比较如果你能任意写入 TLS 区域把 canary 的基准值改成自己选择的数据那么溢出写入的 canary 值只要能跟这个改过的值对上即可。这需要攻击者具备任意地址写原语通常是格式化字符串漏洞或堆漏洞配合使用。具体思路先泄露 TLS 中 canary 槽位的地址在某些架构中需要先计算线程局部存储相对fs/gs的偏移利用某个任意写原语把 canary 槽位的值改成已知固定值比如全A构造溢出 payload 时canary 字段直接填这个固定值正常返回到目标地址校验通过。这个手法在 CTF 里出现得不多主要因为多数栈溢出题目不具备任意写原语但真实漏洞组合场景下它是非常成立的思路。尤其是可以配合堆的unlink、house of spirit等手法使用攻击面一下子就扩大了。缺点是操作门槛高需要对 TLS 布局和指针计算有较深理解。我会把它放在真实环境组合拳那部分一起讲是因为它往往不是单一漏洞完成的而是一套漏洞链的最后一步。2.5 绕过手法速查表手法核心前提难度适用场景格式化字符串泄露存在可控格式化字符串或越界读原语低最常见暴力穷举32位目标程序使用 fork 模型、canary 不变中网络服务覆盖局部变量/函数指针栈上存在可利用的指针或索引中特定程序逻辑栈迁移存在leave; retgadget 且数据布局可控中高栈溢出配合全局区可用TLS canary 覆写存在任意地址写原语高漏洞组合链XOR canary 绕过仍需泄露 canary且需同时恢复原始返回地址或利用异或关系高加固场景3. 一个完整案例从崩溃点到 shell 的调试全记录理论讲太多容易飘下面用一个我搭的模拟程序把整条链路走一遍。这个程序完全虚构但漏洞模式在现实工程里经常出现。目标是开启 canary NX 部分 RELRO无 PIE为了聚焦 canary 绕过PIE 的影响放到下一章展开。3.1 保护全开时碰到的第一道墙程序是个简易聊天服务核心函数读入一条消息存到栈缓冲区然后用一个不安全的函数把它格式化输出#include stdio.h #include string.h #include unistd.h void echo_message(char *msg) { char buf[0x20]; char local_canary_check[8]; strcpy(buf, msg); // 故意存在的漏洞 printf(buf); printf(\n); } int main() { char input[0x100]; while (1) { read(0, input, 0x100); echo_message(input); } return 0; }注意strcpy(buf, msg)没有任何长度检查printf(buf)又是格式字符串。两个漏洞组合在一起正好给了泄露 canary和溢出返回地址两条路。先运行checksec看保护Arch: amd64-64-little RELRO: Partial RELRO Stack: Canary found NX: NX enabled PIE: No PIE (0x400000)第一道墙就是Stack: Canary found。我用 pattern 填充定位崩溃点记录溢出偏移这一点后面计算很重要。用cyclic 200发给程序在 gdb 里看到崩溃信息Program received signal SIGSEGV, Segmentation fault. 0x00000000004007c4 in echo_message ()再深入看发现程序其实先触发了__stack_chk_fail调用说明校验已经发现 canary 被改了。这个信号就是第一道墙的典型特征。3.2 找泄露点格式化字符串的两步猜测法现在要做的是把 canary 从栈上钓出来。因为程序用了printf(buf)一个典型的 payload 就是%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p输出会是一串地址。我的经验是不要把 payload 直接一发打到底先分两到三步缩小范围。第一步发AAAA%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p这样的标记串数一下从哪个偏移开始能看到0x4141414141414141这个值。这个值能帮你定位输入在栈上的位置偏移。假设定位到输入从第 6 个%p开始那 canary 就在输入之后、RBP 之前通常是偏移 10~15 之间的某个位置。为什么因为栈帧里除了我们可控的输入参数区还有保存的 RBP、返回地址等固定内容。我一般用这样的探测序列%6$p.%7$p.%8$p.%9$p.%10$p.%11$p.%12$p.%13$p.%14$p.%15$p每个输出按序对应栈偏移。canary 的特征是以0x开头8 字节低两位为00。这个特征非常醒目扫一眼就能从一堆地址里挑出来。我那次测试的输出摘录0x7fffffffde20.0x7fffffffde30.0x70243625.0x70243625.0x4141414141414141.0x65e20d8b001b3a00.0x4007d0第 6 个偏移位置出现了0x65e20d8b001b3a00就是 canary。为了验证不是其他栈数据可以多发几次如果这个值每次都变因为进程重启随机化特征就更确定了。确认之后后面所有溢出 payload 里canary 字段都填这个值。3.3 计算偏移与 payload 构造踩过的坑拿到 canary 后还不能直接打。我用 gdb 精确计算了buf到 canary 的距离(gdb) p buf $1 (char (*)[32]) 0x7fffffffddf0 (gdb) p $rbp - 8 $2 0x7fffffffe008两个地址一减0x7fffffffe008 - 0x7fffffffddf0 0x18 24。也就是说缓冲区到 canary 之间是 24 字节其中前 0x2032 字节区域里有 8 字节被 canary 占用实际写入顺序是先填 24 字节数据到达 canary再填 8 字节 canary 原值再填 8 字节 RBP可以随便填最后填返回地址。完整 payload 长这样#!/usr/bin/env python3 from pwn import * context.arch amd64 p process(./demo_server) # 第一步泄露 canary p.sendline(b%11$p) # 假设第11个偏移是 canary canary int(p.recvline().strip(), 16) log.success(fcanary: {hex(canary)}) # 第二步构造溢出链 payload bA * 24 # 填充到 canary payload p64(canary) # 原样保留 canary payload bB * 8 # 伪造 RBP payload p64(0x4010b0) # 一个 pop rdi; ret gadget payload p64(0x402018) # binsh 字符串地址 payload p64(0x401070) # system 的 PLT 地址 p.sendline(payload) p.interactive()这里有几个坑值得单独说第一canary的\x00不能丢。泄露出来的值是 8 字节最低位是\x00。有些新手把p64(canary).rstrip(b\x00)之后直接拼 payload结果 canary 变成 7 字节整个栈偏移全乱。canary 必须补满 8 字节低字节就是\x00不要去掉。第二payload 里不要混入换行符或空白。程序用read(0, input, 0x100)读取所以可以接受任意字节但如果你用sendline会额外发一个\n这个\n有可能会被strcpy当作字符串的一部分写进栈导致后续printf输出的内容出现意外换行。稳妥的做法是用send而不是sendline。第三ROP 链的地址必须对。无 PIE 时 ELF 基址是0x400000但要确认 PLT 地址和 gadget 地址在当前版本里有效。我用 ROPgadget 找到pop rdi; ret的实际偏移后再写进脚本不要凭记忆拍脑袋。第四RBP 伪造其实无所谓。在简单返回场景里RBP 会被leave; ret恢复但通常不会影响你的 ROP 链只要能正常弹栈执行即可。真正要注意的是 ROP 链对齐问题——很多情况下在调用system前需要ret一次来对齐栈否则会因栈未对齐崩溃。我实际调试时在这里卡了将近四十分钟最后给 ROP 链最前面加了一个ret; nop的 gadget 才稳定。3.4 绕过 canary 后的下一道门PIE 与 NX 联动上面这个案例我特意把 PIE 关掉了因为这样可以把注意力集中在 canary 上。但真实环境里 PIE 几乎必开这意味着 ELF 的基址也是随机的。你会遇到这样的局面canary 泄露出来了ROP 链也编好了可是pop rdi; ret的地址是多少不知道。解决办法其实还是同一套思路用格式化字符串泄露更多的栈数据。栈上往往保存着返回地址而返回地址属于程序代码段基于它的低 12 位可以推导出整个 ELF 基址。比如你在第 12 个偏移看到一个0x7f...开头的地址那是 libc 里的地址看到0x55...PIE 开启时程序基址高四位通常是0x55或0x56开头的地址那就是程序代码段地址。用这个地址减去它对应的已知符号偏移就得到基址然后重新计算所有 gadget。NX 开启时栈不可执行所有补丁必须变成 ROP。这不一定更复杂但要求你至少有一个可用的 gadget 链。这里有两个常用技巧如果目标有read或write这类函数可以先调用read把第二段 ROP 读到.bss段再栈迁移过去解决单次输入长度不够的问题one_gadget约束检查时注意 registers 的状态有些约束在真实的 GNU 环境里很难满足不如老老实实拼 ROP。结合 canary 和 PIE绕过链路就变成格式化字符串泄露 canary格式化字符串泄露某个代码段地址推算 PIE 基址构造 ROP 链用 canary 过校验用 PIE 基址更正所有符号地址发送 payload拿到 shell。整套流程下来你会发现canary 只是把无脑覆盖返回地址这个老套路挡掉了但它挡不住边泄露边利用的组合攻击。这正说明单一防护措施永远不是终点。4. 真实环境中的组合拳canary 只是第一层可以先把结论放出来canary 的绕过难点不在 canary 本身而在于它和 PIE、NX、RELRO 结合起来以后攻击链变长、约束变多、触发条件变苛刻。这一章聊聊真实环境里常见的组合场景和相应思路。4.1 RELRO 状态决定了你还能不能碰 GOTRELRO 有三种状态No RELRO、Partial RELRO、Full RELRO。No RELROGOT 完全可写直接覆盖某个 GOT 表项指向 shellcode 或 libc 函数几乎是最快的劫持路径Partial RELROGOT 的前半部分只读但.got.plt里动态解析的函数表项仍然可写。攻击者可以覆盖__free_hook、printf_hook这类函数指针的地址达到控制流转移Full RELRO整张 GOT 全部只读函数指针劫持阵地转移到 libc 内部的_rtld_global、exit_function_list、__malloc_hook等结构。在绕 canary 拿 shell的综合利用里Partial RELRO 是最常见也最友好的状态。因为栈溢出配合 ROP 可以直接调用system不必非得写 GOT。但如果溢出长度不够构造完整 ROPGOT 劫持就成了退路。这里有一个容易忽略的操作细节覆盖 GOT 表项之前先确认你要覆盖的那个函数已经被调用过、对应 GOT 已写入真实地址。否则你覆盖的是一个跳转 PLT 用的待解析地址程序在后续调用时可能会走 PLT 解析流程把你覆盖的值冲掉。调试时出现过不少次明明覆盖成功了一调用就崩的情况多数是没先触发该函数解析。4.2 堆漏洞与 canary 的组合互不干扰但有先后栈溢出可以绕 canary堆漏洞则根本不需要面对 canary。如果你手头的目标程序同时存在一个堆溢出和一个栈溢出可以先用堆漏洞拿到 libc 基址或完成任意写再回到栈溢出这根线上。典型的操作次序堆漏洞泄露 heap 地址与 libc 地址利用堆漏洞写入一个 ROP 链到堆上绕过 NX用栈溢出配合 canary 泄露把返回地址劫持成leave; ret跳转到堆上的 ROP 链或者干脆用堆漏洞改__free_hook然后栈溢出只负责触发一次free。这种组合下 canary 甚至可以被完全搁置——前提是触发栈溢出的那个函数本身可以泄露 canary。如果程序里格式化字符串漏洞和栈溢出漏洞不在同一个函数那就需要把两段读写拼接起来。我自己的经验是先做信息泄露再做控制流转移最后才是弹 shell。信息泄露阶段通常是上手先摸所以压轴阶段里 canary 早已不是秘密。换句话说真正困住攻击者的往往不是 canary而是信息泄露通道不够多。4.3 RET2DL_RUNTIME_RESOLVE不依赖GOT可写性的备胎如果有 Full RELRO、没有现成system地址、也不方便泄露 libc 基址有一个比较古典但不失有效的思路伪造动态链接器的解析参数让程序在下一次 PLT 解析时直接解析system再跳过去。这个技术通常叫ret2dlruntimeresolve。它的核心是覆盖.rela.plt和.dynsym里的数据把要解析的符号索引改成system/execve等。理论上它需要把伪造的解析结构写到可写内存所以栈溢出配合一段 ROP 就能实现。canary 在这里同样不是阻碍只要你先把 canary 泄露掉通过栈溢出把控制流引到 PLT0 和伪造参数地址即可。这个手法对栈的布局要求比较高payload 里同时要包含伪造的 Elf64_Rela、 Elf64_Sym、字符串表等结构。我一般在空间不足时才会选择它因为它比常规 ROP 麻烦得多但在全防护状态下收益极高。4.4 不同平台的差异Windows /GS 与 ARM64 的 canary 细节最后给多平台视角做个收尾。Windows 的栈保护叫/GSSecurity Cookie机制与 Linux 的 canary 非常相似但细节不同它使用一个进程级全局变量__security_cookie函数入口处把它压入栈返回前恢复。攻击者可以通过修改全局变量来中和校验这给了逃过/GS的特定路径同时 Windows 的异常处理结构SEH在 x86 平台上自成一套体系攻击者在 32 位程序里往往优先覆盖 SEH 链而不是返回地址。ARM64 的 canary 也很有意思它通常从线程指针TPIDR_EL0读取保存在栈上某个固定偏移。ARM64 的LR链接寄存器不像 x86 返回地址那样严格地存储在栈上所以有些函数甚至没有栈保存LR的环节canary 的使用位置也不同。做移动端漏洞利用时这些差异会直接影响 gadget 搜索和 ROP 链构造。Android 的 Bionic libc 也实现了 TLS canary机制与 glibc 类似但它在 AArch64 上对栈帧的插入位置和编译器选项有关。只能说每个平台都有一套 canary 的“方言”但核心矛盾不变要么泄露它要么绕开它要么改写它。把基础原理吃透跨平台只是换套偏移量的事。5. 防御者视角从绕过手法反看 canary 的边界很多做防御的同学一听绕 canary就紧张仿佛这东西形同虚设。其实从上面所有绕过手法能反过来得出一个更清醒的结论canary 从来不是用来对抗完整攻击链的安全边界它只针对“连续的内存越界写覆盖返回地址”这一种特定攻击模式做了阻断。一个栈缓冲区越界读、任意地址写、堆溢出、逻辑漏洞——这些都不直接受 canary 约束。canary 唯一严防死守的是你必须在返回地址前写入足够多的数据。如果攻击者的原语是一次越界写一个字节且每次都不触发校验那 canary 也能被逐字节猜出来——只不过速度慢得让攻击变得不现实这本身也是一种有效威慑。从防御加固的实践角度来看有几件事比 canary 本身更值得做栈布局随机化和变量重排。有些编译器支持将局部变量重新排列使敏感变量不紧邻缓冲区增加溢出定位的难度。还有-fstack-protector-strong只对含有数组或指针操作的函数插桩覆盖面更合理比全量插桩效率更高。完整 RELRO PIE NX ASLR 的组合。四个开关全部打开以后一次典型的栈溢出利用需要同时完成泄露 canary、泄露 PIE 基址、泄露 libc 基址、构造 ROP、保证栈对齐。这一整套步骤任何一环出错都会失败。我的实测经验是在完全开启的现代 Linux 环境里光栈对齐这一项就能让很多半吊子攻击脚本当场报废。影子栈与硬件辅助防护。Intel CET 的 shadow stack、ARM 的 Pointer AuthenticationPAC和 Memory TaggingMTE是更进一层的思路。影子栈用硬件维护一份返回地址备份即使栈上返回地址被改写从影子栈取出的真实返回地址还是原值直接把 ROP 劫持路径堵死。PAC 则把返回地址签名绑定到栈指针上篡改后的地址无法通过验证。这些方案虽然还没有在所有平台默认启用但已经代表了未来栈防护的方向。回到绕 canary 这件事本身我最后想分享一个实践心得做漏洞研究时别把 canary 当成一道坎把它当成一个强制你完善信息泄露链路的契机。很多攻击者在练习栈溢出时习惯直接打返回地址一旦遇到 canary 就卡死但真正成熟的分析流程里信息泄露本来就应该排在控制流劫持之前。学会先把 canary 钓出来你的漏洞利用能力反而是整个提升了一截。在我实际调试的经历里还有一个小技巧值得记录如果你已经确认某段代码存在格式字符串漏洞可以在一次交互里同时完成 canary 泄露和后续溢出利用不必分成两步。格式字符串本身会先打印数据然后进入溢出路径只要你精确控制printf的偏移和溢出长度就能让程序先迷茫一秒、再按你的剧本执行。这种一步到位的组合 payload在真实服务里尤其好用因为它减少了交互次数也降低了对网络稳定性的要求。希望这些记录对你调试、分析或者防御都有一点参考。遇到 canary 别再下意识皱眉了——它只是栈上的一个哨兵而哨兵的意义从来不在挡住谁在于让你重新思考还有哪些路可走。
写这篇内容的起因是我前段时间在自己搭的一个模拟漏洞环境里做栈溢出实验。当时目标程序开启了常见的栈保护选项结果连续几个晚上都在和一段不可名状的随机数据搏斗——每次溢出都稳定地触发stack smashing detected程序直接终止ESP和返回地址眼看着到手边又飞走。后来我意识到问题不在攻击手法本身而是我压根没搞清楚canary 在什么时候出现、什么时候校验、哪些路径根本不会碰它。这篇文章就是把这些思考沉淀下来canary 保护的底层机制、业界常用的绕过手法及其成立条件、一个完整演示案例的调试全过程以及现代防护体系下绕 canary到底意味着什么。对 CTF 选手、漏洞研究入门者、以及想理解栈防护边界的安全开发同学应该都能有些参考价值。1. canary不是拦路虎先搞清楚它到底在保护什么1.1 从一次崩溃现场说起先回到那次调试现场。一个很普通的 64 位程序栈上有个 0x20 字节的缓冲区后面跟着局部变量。我用常规的 A 字符填充触发溢出结果程序在返回时直接崩溃。注意这个崩溃点很有讲究——它不是在写入缓冲区的时候立刻崩的而是等到函数即将ret时才崩。这说明栈保护机制是在函数返回前做了一次体检。x86-64 下的典型栈布局大概是这样的地址从高到低高地址 --------------------------- | 参数区 / 其他变量 | --------------------------- | 返回地址8字节 | --------------------------- | 调用者 RBP8字节 | --------------------------- | canary8字节 | --------------------------- | 局部缓冲区 | -- 溢出点在这里 --------------------------- 低地址canary 被放在局部缓冲区和 RBP/返回地址之间。程序编译时插入了生成 canary和校验 canary两段代码。进入函数时会从某个随机源取出一个值放进这个位置函数返回前会重新读取并与之比较。一旦不相等直接调用专门的错误处理函数终止进程。我直到现在都记得第一次看这个布局时的感受这玩意儿本质上就是一个栈上的哨兵它的存在不是为了防溢出写入而是为了确保任何从低地址向高地址的连续覆盖都必定经过它。所以你填充数据时只要想碰到 RBP 和返回地址就一定会先覆盖 canary。程序的逻辑很简单——发现哨兵被动过说明栈内容被破坏了那返回地址也极可能不可信索性直接终止。1.2 canary的一生生成、加密、校验与差异搞清楚布局只是第一步更关键的问题是这个哨兵值从哪来为什么每次运行都不一样为什么它低位总是\x00在 glibc 环境下Linux x86-64线程局部存储TLS里专门有一个槽位保存随机 canary引用方式在汇编里通常是fs:0x28。程序每次启动时系统会生成一个随机数放入这个槽位之后所有函数的 canary 校验都对照这个值。正是这个随机性让攻击者没办法像之前那样直接猜出返回地址前的 8 字节。有一个细节很值得展开canary 的低位字节固定为\x00。为什么这要考虑按字符串读取的场景。如果一个能读内存的函数比如strcpy、printf(%s)恰好把 canary 所在的内存当作字符串输出遇到\x00就会自然截断这样攻击者就无法完整泄露 canary。同时这个\x00也在某种程度上保证了 canary 本身不会成为超长字符串的源头。反过来说如果 canary 是纯随机值、不含终止符那么一个缓冲区溢出通过strcpy就可以把它覆盖成任意内容——可校验时仍然要比较所以它的哨兵作用反而弱了。不同编译器对 canary 的生成策略还有差异。经典 GCC 有两种常见形态类型生成方式特点Random canary从随机源取 64 位 / 32 位随机值低位置零最常见每次进程启动都变Terminator canary由\n、\r、\xff、\x00等字节组成旧式实现防止破坏字符串函数XOR canary随机值再与返回地址异或某些编译器/加固选项下使用XOR canary 的校验逻辑会连同返回地址一起做运算等于把 canary 和返回地址绑定了。如果攻击者只覆盖 canary、不知道返回地址的原始值校验就一定失败反之如果只覆盖返回地址而 canary 保持原样校验同样失败。这种设计把两种数据的完整性绑定在一起比普通 canary更强一些。不过目前主流的 glibc/GCC 默认仍是随机 canary。校验代码本身也有一些值得注意的细节。正常函数的开头会有mov rax, qword ptr fs:[0x28]、mov qword ptr [rbp-8], rax这样的操作返回前再用xor rax, qword ptr [rbp-8]之类的指令做比较。如果被攻击者直接通过其他方式改写返回地址比如栈迁移函数根本不会走到校验逻辑——这一点是后面所有绕过思路的核心。2. 常见的绕过思路每一种手法背后都有一个决定性前提网上讲绕 canary 的资料不少但多数只给攻击模板不讲成立条件。我自己测试下来的体会是每种绕过手法的本质都是找到一个可以不经过 canary 校验或能让校验值本身变成可控的路径。这里按其实用性和前提条件逐类展开。2.1 泄露式绕过先读后填对付随机 canary 最直接的办法如果你能让程序主动把 canary 打印出来那 canary 的随机性就形同虚设。这类利用的核心是越界读能力而不是栈溢出本身。最经典的渠道是格式化字符串漏洞printf(user_input);如果用户输入里包含%p、%llx这类格式说明符printf 就会按可变参数的逻辑从栈上连续取值。注意这里的栈就是当前函数的栈而 canary 恰恰就保存在这个栈的固定位置rbp-0x8附近。只要输入的偏移正确canary 就能被当成一个普通参数泄露出来。具体怎么找偏移我一般用分界标记法AAAAAAAA%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p逐个偏移数过去直到在某个位置突然出现一串以0x开头、后八位以00结尾的 16 字节十六进制数。这个以 00 结尾的特征非常明显因为它就是 canary 的低位终止字节。64 位环境下 canary 通常是 8 字节打印出来形如0x65e20d8b001b3a00。另一种泄露渠道是越界读。有些程序会把栈上的内存块直接复制发送给客户端比如memcpy(send_buf, stack_buf, stack_size);如果stack_size实际超过了stack_buf的边界数据里就会带上 canary。这类场景在文件解析、协议处理程序里很常见测试时值得重点关注。泄露式的核心前提是你确实拥有某种越界读原语而且读的路径不会因 canary 的\x00而中断。如果用strcpy、sprintf(%s)这类以字符串为载体的函数泄露读到终止符就断了你必须想其他办法。这一点我在后面案例里会再踩一次。2.2 暴力猜测32位程序里 fork 出来的子进程canary 是稳定的对 64 位程序来说随机 canary 有 8 字节除掉低位\x00还有 7 字节暴力穷举不现实。但 32 位程序不同——canary 只有 4 字节低位固定为\x00实际需要猜的只有 3 字节最多2^24 16777216种组合。如果目标允许 fork这个数字就变得非常可行。关键是 fork 的行为fork 出来的子进程完全继承父进程的地址空间和 TLS也就是 canary 不变。这是暴力猜测能够成立的决定性前提。很多网络服务会为每个连接 fork 一个子进程来响应请求这意味着攻击者每次尝试失败的代价只是断掉一次连接子进程崩溃不影响父进程继续 fork 新的子进程。具体思路是这样连接服务器触发一次溢出用\x00作为 canary 第一位字节第二位第三位第四位依次尝试0x00到0xff观察程序是否继续正常运行没有触发 stack smashing 报错一旦某次填充后程序没有崩溃说明该字节猜对了逐字节穷举最后拼出完整 canary。32 位下穷举 3 字节并不可怕但最好在目标环境支持并发时做速度优化。我实际测试时单进程串行发包太慢用多线程同时尝试不同字节区间效果明显。判定成功的标志也很讲究——不能只看是否崩溃因为如果 canary 前几字节猜对了但后续字节填错照样会崩必须每次都从猜测中最低的那个字节开始采用由低到高渐进的方式。64 位下也有过暴力思路但理论成功率极低通常只存在于学术讨论或极端弱随机源场景实战中基本不考虑。2.3 间接改变控制流不触发 canary 校验的路径很多人被 canary 卡住是因为潜意识里认为要劫持控制流就一定要修改返回地址。其实返回地址只是控制流劫持的一种载体它上面的保护并不等于所有控制流都受保护。一个典型的思路是溢出覆盖局部变量。注意溢出方向是从低地址向高地址增长局部变量如果恰好排在缓冲区高地址方向之前比如某些结构体成员、索引值、大小字段会先于 canary 被覆盖。一个很著名的模式是索引型越界char buf[16]; int idx; memcpy(buf, user_input, strlen(user_input));如果idx在不经意间会被当作数组下标使用覆盖它就能实现任意位置读写。这种利用根本不需要碰 canary因为控制流转移发生在数组访问阶段函数到返回点之前可能根本没触发校验。另一个思路是修改栈上保存的函数指针。某些程序会把函数指针暂存在栈上比如调用回调的上下文结构体、注册的异常处理函数等。溢出数据流会先经过这些函数指针覆盖它们后程序在函数返回前就会去调用被篡改的地址。典型的例子是 Windows 下的 SEH 链覆盖但 Linux 下也有类似情况比如栈上保存了signal handler或atexit注册的回调指针结构体通过vtable调用虚函数局部构造的func_table、ops结构体。这类方式的核心前提是目标程序在栈上放了可控且可劫持的指针数据而不是一定要通过返回地址。实用性取决于你对程序数据布局的掌握程度。还有一种 回避式的做法是栈迁移。假设你不打算老老实实回到原函数返回地址而是直接把栈指针rsp转移到一块你完全可控的内存区域比如全局变量、堆缓冲区、.bss然后在那里接着执行 ROP 链。这样函数的返回值其实已经被绕过了——前提是你必须有一个能控制rsp的 gadget比如经典的leave; ret这个 gadget 把rbp传给rsp再执行ret。如果攻击者能控制rbp指向的数据看起来像一串地址这条链就能跑起来。注意它不需要触发 canary 校验因为这个函数根本不按正常返回的路径走——但前提是你已经可以通过某条路径改写rbp或者栈上的数据。2.4 TLS canary覆写釜底抽薪式的极端手法前三种方式本质上是绕过还有一种更彻底的方式直接让 canary 的参照值变成我们可控的值。因为 canary 校验是和 TLS 中的原始值比较如果你能任意写入 TLS 区域把 canary 的基准值改成自己选择的数据那么溢出写入的 canary 值只要能跟这个改过的值对上即可。这需要攻击者具备任意地址写原语通常是格式化字符串漏洞或堆漏洞配合使用。具体思路先泄露 TLS 中 canary 槽位的地址在某些架构中需要先计算线程局部存储相对fs/gs的偏移利用某个任意写原语把 canary 槽位的值改成已知固定值比如全A构造溢出 payload 时canary 字段直接填这个固定值正常返回到目标地址校验通过。这个手法在 CTF 里出现得不多主要因为多数栈溢出题目不具备任意写原语但真实漏洞组合场景下它是非常成立的思路。尤其是可以配合堆的unlink、house of spirit等手法使用攻击面一下子就扩大了。缺点是操作门槛高需要对 TLS 布局和指针计算有较深理解。我会把它放在真实环境组合拳那部分一起讲是因为它往往不是单一漏洞完成的而是一套漏洞链的最后一步。2.5 绕过手法速查表手法核心前提难度适用场景格式化字符串泄露存在可控格式化字符串或越界读原语低最常见暴力穷举32位目标程序使用 fork 模型、canary 不变中网络服务覆盖局部变量/函数指针栈上存在可利用的指针或索引中特定程序逻辑栈迁移存在leave; retgadget 且数据布局可控中高栈溢出配合全局区可用TLS canary 覆写存在任意地址写原语高漏洞组合链XOR canary 绕过仍需泄露 canary且需同时恢复原始返回地址或利用异或关系高加固场景3. 一个完整案例从崩溃点到 shell 的调试全记录理论讲太多容易飘下面用一个我搭的模拟程序把整条链路走一遍。这个程序完全虚构但漏洞模式在现实工程里经常出现。目标是开启 canary NX 部分 RELRO无 PIE为了聚焦 canary 绕过PIE 的影响放到下一章展开。3.1 保护全开时碰到的第一道墙程序是个简易聊天服务核心函数读入一条消息存到栈缓冲区然后用一个不安全的函数把它格式化输出#include stdio.h #include string.h #include unistd.h void echo_message(char *msg) { char buf[0x20]; char local_canary_check[8]; strcpy(buf, msg); // 故意存在的漏洞 printf(buf); printf(\n); } int main() { char input[0x100]; while (1) { read(0, input, 0x100); echo_message(input); } return 0; }注意strcpy(buf, msg)没有任何长度检查printf(buf)又是格式字符串。两个漏洞组合在一起正好给了泄露 canary和溢出返回地址两条路。先运行checksec看保护Arch: amd64-64-little RELRO: Partial RELRO Stack: Canary found NX: NX enabled PIE: No PIE (0x400000)第一道墙就是Stack: Canary found。我用 pattern 填充定位崩溃点记录溢出偏移这一点后面计算很重要。用cyclic 200发给程序在 gdb 里看到崩溃信息Program received signal SIGSEGV, Segmentation fault. 0x00000000004007c4 in echo_message ()再深入看发现程序其实先触发了__stack_chk_fail调用说明校验已经发现 canary 被改了。这个信号就是第一道墙的典型特征。3.2 找泄露点格式化字符串的两步猜测法现在要做的是把 canary 从栈上钓出来。因为程序用了printf(buf)一个典型的 payload 就是%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p输出会是一串地址。我的经验是不要把 payload 直接一发打到底先分两到三步缩小范围。第一步发AAAA%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p这样的标记串数一下从哪个偏移开始能看到0x4141414141414141这个值。这个值能帮你定位输入在栈上的位置偏移。假设定位到输入从第 6 个%p开始那 canary 就在输入之后、RBP 之前通常是偏移 10~15 之间的某个位置。为什么因为栈帧里除了我们可控的输入参数区还有保存的 RBP、返回地址等固定内容。我一般用这样的探测序列%6$p.%7$p.%8$p.%9$p.%10$p.%11$p.%12$p.%13$p.%14$p.%15$p每个输出按序对应栈偏移。canary 的特征是以0x开头8 字节低两位为00。这个特征非常醒目扫一眼就能从一堆地址里挑出来。我那次测试的输出摘录0x7fffffffde20.0x7fffffffde30.0x70243625.0x70243625.0x4141414141414141.0x65e20d8b001b3a00.0x4007d0第 6 个偏移位置出现了0x65e20d8b001b3a00就是 canary。为了验证不是其他栈数据可以多发几次如果这个值每次都变因为进程重启随机化特征就更确定了。确认之后后面所有溢出 payload 里canary 字段都填这个值。3.3 计算偏移与 payload 构造踩过的坑拿到 canary 后还不能直接打。我用 gdb 精确计算了buf到 canary 的距离(gdb) p buf $1 (char (*)[32]) 0x7fffffffddf0 (gdb) p $rbp - 8 $2 0x7fffffffe008两个地址一减0x7fffffffe008 - 0x7fffffffddf0 0x18 24。也就是说缓冲区到 canary 之间是 24 字节其中前 0x2032 字节区域里有 8 字节被 canary 占用实际写入顺序是先填 24 字节数据到达 canary再填 8 字节 canary 原值再填 8 字节 RBP可以随便填最后填返回地址。完整 payload 长这样#!/usr/bin/env python3 from pwn import * context.arch amd64 p process(./demo_server) # 第一步泄露 canary p.sendline(b%11$p) # 假设第11个偏移是 canary canary int(p.recvline().strip(), 16) log.success(fcanary: {hex(canary)}) # 第二步构造溢出链 payload bA * 24 # 填充到 canary payload p64(canary) # 原样保留 canary payload bB * 8 # 伪造 RBP payload p64(0x4010b0) # 一个 pop rdi; ret gadget payload p64(0x402018) # binsh 字符串地址 payload p64(0x401070) # system 的 PLT 地址 p.sendline(payload) p.interactive()这里有几个坑值得单独说第一canary的\x00不能丢。泄露出来的值是 8 字节最低位是\x00。有些新手把p64(canary).rstrip(b\x00)之后直接拼 payload结果 canary 变成 7 字节整个栈偏移全乱。canary 必须补满 8 字节低字节就是\x00不要去掉。第二payload 里不要混入换行符或空白。程序用read(0, input, 0x100)读取所以可以接受任意字节但如果你用sendline会额外发一个\n这个\n有可能会被strcpy当作字符串的一部分写进栈导致后续printf输出的内容出现意外换行。稳妥的做法是用send而不是sendline。第三ROP 链的地址必须对。无 PIE 时 ELF 基址是0x400000但要确认 PLT 地址和 gadget 地址在当前版本里有效。我用 ROPgadget 找到pop rdi; ret的实际偏移后再写进脚本不要凭记忆拍脑袋。第四RBP 伪造其实无所谓。在简单返回场景里RBP 会被leave; ret恢复但通常不会影响你的 ROP 链只要能正常弹栈执行即可。真正要注意的是 ROP 链对齐问题——很多情况下在调用system前需要ret一次来对齐栈否则会因栈未对齐崩溃。我实际调试时在这里卡了将近四十分钟最后给 ROP 链最前面加了一个ret; nop的 gadget 才稳定。3.4 绕过 canary 后的下一道门PIE 与 NX 联动上面这个案例我特意把 PIE 关掉了因为这样可以把注意力集中在 canary 上。但真实环境里 PIE 几乎必开这意味着 ELF 的基址也是随机的。你会遇到这样的局面canary 泄露出来了ROP 链也编好了可是pop rdi; ret的地址是多少不知道。解决办法其实还是同一套思路用格式化字符串泄露更多的栈数据。栈上往往保存着返回地址而返回地址属于程序代码段基于它的低 12 位可以推导出整个 ELF 基址。比如你在第 12 个偏移看到一个0x7f...开头的地址那是 libc 里的地址看到0x55...PIE 开启时程序基址高四位通常是0x55或0x56开头的地址那就是程序代码段地址。用这个地址减去它对应的已知符号偏移就得到基址然后重新计算所有 gadget。NX 开启时栈不可执行所有补丁必须变成 ROP。这不一定更复杂但要求你至少有一个可用的 gadget 链。这里有两个常用技巧如果目标有read或write这类函数可以先调用read把第二段 ROP 读到.bss段再栈迁移过去解决单次输入长度不够的问题one_gadget约束检查时注意 registers 的状态有些约束在真实的 GNU 环境里很难满足不如老老实实拼 ROP。结合 canary 和 PIE绕过链路就变成格式化字符串泄露 canary格式化字符串泄露某个代码段地址推算 PIE 基址构造 ROP 链用 canary 过校验用 PIE 基址更正所有符号地址发送 payload拿到 shell。整套流程下来你会发现canary 只是把无脑覆盖返回地址这个老套路挡掉了但它挡不住边泄露边利用的组合攻击。这正说明单一防护措施永远不是终点。4. 真实环境中的组合拳canary 只是第一层可以先把结论放出来canary 的绕过难点不在 canary 本身而在于它和 PIE、NX、RELRO 结合起来以后攻击链变长、约束变多、触发条件变苛刻。这一章聊聊真实环境里常见的组合场景和相应思路。4.1 RELRO 状态决定了你还能不能碰 GOTRELRO 有三种状态No RELRO、Partial RELRO、Full RELRO。No RELROGOT 完全可写直接覆盖某个 GOT 表项指向 shellcode 或 libc 函数几乎是最快的劫持路径Partial RELROGOT 的前半部分只读但.got.plt里动态解析的函数表项仍然可写。攻击者可以覆盖__free_hook、printf_hook这类函数指针的地址达到控制流转移Full RELRO整张 GOT 全部只读函数指针劫持阵地转移到 libc 内部的_rtld_global、exit_function_list、__malloc_hook等结构。在绕 canary 拿 shell的综合利用里Partial RELRO 是最常见也最友好的状态。因为栈溢出配合 ROP 可以直接调用system不必非得写 GOT。但如果溢出长度不够构造完整 ROPGOT 劫持就成了退路。这里有一个容易忽略的操作细节覆盖 GOT 表项之前先确认你要覆盖的那个函数已经被调用过、对应 GOT 已写入真实地址。否则你覆盖的是一个跳转 PLT 用的待解析地址程序在后续调用时可能会走 PLT 解析流程把你覆盖的值冲掉。调试时出现过不少次明明覆盖成功了一调用就崩的情况多数是没先触发该函数解析。4.2 堆漏洞与 canary 的组合互不干扰但有先后栈溢出可以绕 canary堆漏洞则根本不需要面对 canary。如果你手头的目标程序同时存在一个堆溢出和一个栈溢出可以先用堆漏洞拿到 libc 基址或完成任意写再回到栈溢出这根线上。典型的操作次序堆漏洞泄露 heap 地址与 libc 地址利用堆漏洞写入一个 ROP 链到堆上绕过 NX用栈溢出配合 canary 泄露把返回地址劫持成leave; ret跳转到堆上的 ROP 链或者干脆用堆漏洞改__free_hook然后栈溢出只负责触发一次free。这种组合下 canary 甚至可以被完全搁置——前提是触发栈溢出的那个函数本身可以泄露 canary。如果程序里格式化字符串漏洞和栈溢出漏洞不在同一个函数那就需要把两段读写拼接起来。我自己的经验是先做信息泄露再做控制流转移最后才是弹 shell。信息泄露阶段通常是上手先摸所以压轴阶段里 canary 早已不是秘密。换句话说真正困住攻击者的往往不是 canary而是信息泄露通道不够多。4.3 RET2DL_RUNTIME_RESOLVE不依赖GOT可写性的备胎如果有 Full RELRO、没有现成system地址、也不方便泄露 libc 基址有一个比较古典但不失有效的思路伪造动态链接器的解析参数让程序在下一次 PLT 解析时直接解析system再跳过去。这个技术通常叫ret2dlruntimeresolve。它的核心是覆盖.rela.plt和.dynsym里的数据把要解析的符号索引改成system/execve等。理论上它需要把伪造的解析结构写到可写内存所以栈溢出配合一段 ROP 就能实现。canary 在这里同样不是阻碍只要你先把 canary 泄露掉通过栈溢出把控制流引到 PLT0 和伪造参数地址即可。这个手法对栈的布局要求比较高payload 里同时要包含伪造的 Elf64_Rela、 Elf64_Sym、字符串表等结构。我一般在空间不足时才会选择它因为它比常规 ROP 麻烦得多但在全防护状态下收益极高。4.4 不同平台的差异Windows /GS 与 ARM64 的 canary 细节最后给多平台视角做个收尾。Windows 的栈保护叫/GSSecurity Cookie机制与 Linux 的 canary 非常相似但细节不同它使用一个进程级全局变量__security_cookie函数入口处把它压入栈返回前恢复。攻击者可以通过修改全局变量来中和校验这给了逃过/GS的特定路径同时 Windows 的异常处理结构SEH在 x86 平台上自成一套体系攻击者在 32 位程序里往往优先覆盖 SEH 链而不是返回地址。ARM64 的 canary 也很有意思它通常从线程指针TPIDR_EL0读取保存在栈上某个固定偏移。ARM64 的LR链接寄存器不像 x86 返回地址那样严格地存储在栈上所以有些函数甚至没有栈保存LR的环节canary 的使用位置也不同。做移动端漏洞利用时这些差异会直接影响 gadget 搜索和 ROP 链构造。Android 的 Bionic libc 也实现了 TLS canary机制与 glibc 类似但它在 AArch64 上对栈帧的插入位置和编译器选项有关。只能说每个平台都有一套 canary 的“方言”但核心矛盾不变要么泄露它要么绕开它要么改写它。把基础原理吃透跨平台只是换套偏移量的事。5. 防御者视角从绕过手法反看 canary 的边界很多做防御的同学一听绕 canary就紧张仿佛这东西形同虚设。其实从上面所有绕过手法能反过来得出一个更清醒的结论canary 从来不是用来对抗完整攻击链的安全边界它只针对“连续的内存越界写覆盖返回地址”这一种特定攻击模式做了阻断。一个栈缓冲区越界读、任意地址写、堆溢出、逻辑漏洞——这些都不直接受 canary 约束。canary 唯一严防死守的是你必须在返回地址前写入足够多的数据。如果攻击者的原语是一次越界写一个字节且每次都不触发校验那 canary 也能被逐字节猜出来——只不过速度慢得让攻击变得不现实这本身也是一种有效威慑。从防御加固的实践角度来看有几件事比 canary 本身更值得做栈布局随机化和变量重排。有些编译器支持将局部变量重新排列使敏感变量不紧邻缓冲区增加溢出定位的难度。还有-fstack-protector-strong只对含有数组或指针操作的函数插桩覆盖面更合理比全量插桩效率更高。完整 RELRO PIE NX ASLR 的组合。四个开关全部打开以后一次典型的栈溢出利用需要同时完成泄露 canary、泄露 PIE 基址、泄露 libc 基址、构造 ROP、保证栈对齐。这一整套步骤任何一环出错都会失败。我的实测经验是在完全开启的现代 Linux 环境里光栈对齐这一项就能让很多半吊子攻击脚本当场报废。影子栈与硬件辅助防护。Intel CET 的 shadow stack、ARM 的 Pointer AuthenticationPAC和 Memory TaggingMTE是更进一层的思路。影子栈用硬件维护一份返回地址备份即使栈上返回地址被改写从影子栈取出的真实返回地址还是原值直接把 ROP 劫持路径堵死。PAC 则把返回地址签名绑定到栈指针上篡改后的地址无法通过验证。这些方案虽然还没有在所有平台默认启用但已经代表了未来栈防护的方向。回到绕 canary 这件事本身我最后想分享一个实践心得做漏洞研究时别把 canary 当成一道坎把它当成一个强制你完善信息泄露链路的契机。很多攻击者在练习栈溢出时习惯直接打返回地址一旦遇到 canary 就卡死但真正成熟的分析流程里信息泄露本来就应该排在控制流劫持之前。学会先把 canary 钓出来你的漏洞利用能力反而是整个提升了一截。在我实际调试的经历里还有一个小技巧值得记录如果你已经确认某段代码存在格式字符串漏洞可以在一次交互里同时完成 canary 泄露和后续溢出利用不必分成两步。格式字符串本身会先打印数据然后进入溢出路径只要你精确控制printf的偏移和溢出长度就能让程序先迷茫一秒、再按你的剧本执行。这种一步到位的组合 payload在真实服务里尤其好用因为它减少了交互次数也降低了对网络稳定性的要求。希望这些记录对你调试、分析或者防御都有一点参考。遇到 canary 别再下意识皱眉了——它只是栈上的一个哨兵而哨兵的意义从来不在挡住谁在于让你重新思考还有哪些路可走。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
