从 vmcore 中挖掘出的 CVE

在某次 kernel panic 的 vmcore 分析中，我发现这可能是一个允许低权限用户或远程攻击者触发的拒绝服务漏洞，经过对调用栈的回溯分析与构造 PoC 验证，并将测试结果提交给 Redhat 后，最终由 Redhat 确认：CVE-2020-10708。

漏洞原理

这是一个存在于 audit 子系统的竞争条件漏洞，漏洞原理比较简单，构造漏洞场景也很简单，我们直接通过 vmcore 来看看是怎么发生的。
首先看下 panic 堆栈：

crash> bt
PID: 22814  TASK: ffff8d1b40ea0fd0  CPU: 1   COMMAND: "audispd"
 #0 [ffff8d1b69ee3c60] machine_kexec at ffffffff96a60afa
 #1 [ffff8d1b69ee3cc0] __crash_kexec at ffffffff96b13402
 #2 [ffff8d1b69ee3d90] panic at ffffffff97107a9b
 #3 [ffff8d1b69ee3e10] audit_panic at ffffffff96b271e4
 #4 [ffff8d1b69ee3e28] audit_log_lost at ffffffff96b2722f
 #5 [ffff8d1b69ee3e40] audit_printk_skb at ffffffff96b2743c
 #6 [ffff8d1b69ee3e60] audit_log_end at ffffffff96b27692
 #7 [ffff8d1b69ee3e78] audit_log_exit at ffffffff96b2ce51
 #8 [ffff8d1b69ee3ee8] __audit_syscall_exit at ffffffff96b2f40d
 #9 [ffff8d1b69ee3f20] syscall_trace_leave at ffffffff96a395f4
#10 [ffff8d1b69ee3f48] int_check_syscall_exit_work at ffffffff9711fac2
    RIP: 00007fa2967ab170  RSP: 00007ffc7ce357d0  RFLAGS: 00000200
    RAX: 0000000000000000  RBX: 0000000000000000  RCX: 0000000000000000
    RDX: 0000000000000000  RSI: 0000000000000000  RDI: 0000000000000000
    RBP: 0000000000000000   R8: 0000000000000000   R9: 0000000000000000
    R10: 0000000000000000  R11: 0000000000000000  R12: 0000000000000000
    R13: 0000000000000000  R14: 0000000000000000  R15: 0000000000000000
    ORIG_RAX: 000000000000003b  CS: 0033  SS: 002b

发生 panic 的函数是：

void audit_panic(const char *message)
{
    switch (audit_failure)
    {
    case AUDIT_FAIL_SILENT:
        break;
    case AUDIT_FAIL_PRINTK:
        if (printk_ratelimit())
            printk(KERN_ERR "audit: %s\n", message);
        break;
    case AUDIT_FAIL_PANIC:
        /* test audit_pid since printk is always losey, why bother? */
        if (audit_pid)
            panic("audit: %s\n", message);  // audit_pid != NULL, panic here
        break;
    }
}

这里触发 panic 需要满足两个条件：

1. audit_failure 设置成 AUDIT_FAIL_PANIC，AUDIT_FAIL_PANIC 是指示在 audit 失败的时候主动触发 panic；
2. audit_pid 不为空，即当前 audit 是启用的。

继续回溯发现，在 audit_log_end 中有一处对 audit_pid 的判断：

void audit_log_end(struct audit_buffer *ab)
{
    if (!ab)
        return;
    if (!audit_rate_check()) {
        audit_log_lost("rate limit exceeded");
    } else {
        struct nlmsghdr *nlh = nlmsg_hdr(ab->skb);
        nlh->nlmsg_len = ab->skb->len - NLMSG_HDRLEN;

        if (audit_pid) {
            skb_queue_tail(&audit_skb_queue, ab->skb);
            wake_up_interruptible(&kauditd_wait);
        } else { // audit_pid == NULL 
            audit_printk_skb(ab->skb);
        }
        ab->skb = NULL;
    }
    audit_buffer_free(ab);
}

但这里是在 audit_pid == NULL 时调用 audit_printk_skb，与 audit_panic 中对 audit_pid 的判断结果明显不同，唯一的解释就是：在 audit_log_end 判断 audit_pid 是否为 NULL 时，此时 audit_pid == NULL，进入了 audit_printk_skb，而在这之后，audit_panic 判断 audit_pid 是否为 NULL 之前，由于某些原因（如 auditd 重启），audit_pid 被重新赋值，从而导致 audit_panic 触发 panic。

PoC

从攻击者的角度来说，要触发 panic 的前提是系统管理员（root）设置过 AUDIT_FAIL_PANIC，即 audit 失败后 panic。其次需要等待一小段的窗口期，并在这个窗口期内触发任意一条 audit 规则。一个典型的场景是，在 auditd 重启时，会经历一段 audit_pid 从 NULL 变成非 NULL 的时间，在这个时间里触发的 audit 规则如果恰好满足两个满足上述描述的 audit_log_end 与 audit_panic 对 audit_pid 的判断时机，就能够触发 panic。这其实是一个非常苛刻的条件，但可以通过循环来提高命中的概率。

1. 【需要 root 权限】设置 AUDIT_FAIL_PANIC 并添加一条任意的 audit 规则：
   `[root@test ~]# cat /etc/audit/rules.d/audit.rules

-D
-b 8192
-f 2
-w /etc/hosts -p rwa -k hosts`

1. 【需要 root 权限】不断杀死 auditd 进程并启动 auditd，这其实是制造 audit_pid 从 NULL 变成非 NULL 的环境：
   while true; do ps aux | grep "/sbin/auditd" | grep -v "grep" | awk '{print $2}' | xargs kill; service auditd start; systemctl reset-failed auditd.service; done
2. 【不需要 root 权限】不断触发审计规则：
   while true; do cat /etc/hosts > /dev/null; done
3. 等待 panic 发生