The Route to Host：从内核提权到容器逃逸

前言

绿盟科技研究通讯曾经发表过容器逃逸的技术文章《【云原生攻防研究】容器逃逸技术概览》[1]，该文中探讨了已有的容器逃逸技术。本文将沿着上文的思路，主要从Linux内核漏洞的角度对容器逃逸进行深度介绍，包括攻击原理、自动化利用和防御思路等内容。

目前Linux内核代码已经达到了2700万行量级[2]，仅每年通报的Linux内核漏洞就多达数十个。Linux内核主要使用C语言编写，由于C语言不是类型安全语言，而且偏底层，所以各种内存破坏类漏洞层出不穷。攻击者利用内核漏洞可以达到本地提权的目的。容器技术本身依赖于Linux内核提供的Namespaces和Cgroups机制，利用内核漏洞，攻击者可以绕过Namespaces对资源的隔离，达到逃逸的目的。相比于容器引擎漏洞造成的逃逸，Linux内核漏洞危害更大、威胁更广。

本文接下来会首先介绍利用内核漏洞进行逃逸的思路，重点不在于内核漏洞的利用手法，而是在于提权过后如何进行容器的逃逸。在实践中我们也注意到一部分内核漏洞的利用方法和经典思路不同，后文会对这些漏洞进行梳理。基于以上的了解，本文提出了一套流程以辅助攻击者利用内核漏洞进行容器逃逸。同时，进一步思考利用Linux内核漏洞进行逃逸能否实现工程化利用，这其中的难点是什么。最后，本文将从防御的角度进行探讨，哪些防御机制可以帮助我们保护容器系统的机密性、完整性和可用性。

声明：本文内容仅供合法教学及研究使用，不得将相关知识、技术应用与非法活动！

一、如何利用内核漏洞进行容器逃逸

为了能够更好地展示利用内核漏洞进行容器逃逸的原理，本文将以经典的内核提权漏洞CVE-2017-7308进行阐述。对于此漏洞的完整利用方法可以参考ExP原作者的博客[3]。

CVE-2017-7308是一个整数溢出漏洞，由于内核在判断收到数据长度时存在整数溢出，攻击者可以控制函数指针实现内核代码的任意执行。攻击者利用漏洞执行了内核代码以关闭SMEP和SMAP保护机制，为ret2usr[4]提供了方便。再次利用该漏洞，将控制流劫持到位于用户地址空间的代码中，CPU则以内核模式执行以下代码：

代码语言：javascript代码运行次数：0运行复制

void *g = find_task_by_vpid(1);switch_task_namespaces(g,(void*)init_nsproxy);commit_creds(prepare_kernel_cred(0));long mnt_fd = do_sys_open(AT_FDCWD,"/proc/1/ns/mnt", O_RDONLY,0);sys_setns(mnt_fd,0);long pid_fd = do_sys_open(AT_FDCWD,"/proc/1/ns/pid", O_RDONLY,0);sys_setns(pid_fd,0);

对于这段代码的理解需要首先从著名的数据结构task_struct说起：Linux内核中通过task_struct（/include/linux/sched.h）结构体管理进程（任务），task_struct是一个非常复杂的结构体，其中一个域为struct nsproxy *nsproxy。

代码语言：javascript代码运行次数：0运行复制

struct task_struct{      ...      struct nsproxy *nsproxy;      ...}

nsproxy指针指向了一个struct nsproxy结构体，该结构体的如下所示。

代码语言：javascript代码运行次数：0运行复制

* A structure to contain pointers to all per-process* namespaces - fs(mount), uts, network, sysvipc, etc.** The pid namespace is an exception -- it's accessed using* task_active_pid_ns.  The pid namespace here is the* namespace that children will use.** 'count' is the number of tasks holding a reference.* The count for each namespace, then, will be the number* of nsproxies pointing to it, not the number of tasks.** The nsproxy is shared by tasks which share all namespaces.* As soon as a single namespace is cloned or unshared, the* nsproxy iscopied.*/struct nsproxy {      atomic_t count;      struct uts_namespace *uts_ns;      struct ipc_namespace *ipc_ns;      struct mnt_namespace *mnt_ns;      struct pid_namespace *pid_ns_for_children;      struct net      *net_ns;      struct time_namespace *time_ns;      struct time_namespace *time_ns_for_children;      struct cgroup_namespace *cgroup_ns;};extern struct nsproxy init_nsproxy;

这里出现了容器技术所需要的各种namespaces，由不同的指针指向不同的结构体。通过内核中的注释可以了解到：

1. struct nsproxy结构体中的指针指向了进程的namespaces；

2. 位于相同namespaces的进程会共享同一个struct nsproxy结构体。

可以自然地想到，宿主机上没有经过容器化的进程，它们位于同一组namespaces中，所以会共享同一个struct nsproxy结构体。Linux系统中，PID为1的进程被称为init进程，系统中的所有进程都是通过init进程直接或者间接fork而来的。所以所有没有被修改namespaces的进程都和init进程共享同一组namespaces，即它们拥有同一个struct nsproxy结构体。

如上文中代码所示，init进程的struct nsproxy结构体有一个特殊的名字init_nsproxy。init_nsproxy在内核中实现如下：

代码语言：javascript代码运行次数：0运行复制

struct nsproxy init_nsproxy ={      .count                  = ATOMIC_INIT(1),      .uts_ns                 =&init_uts_ns,#if defined(CONFIG_POSIX_MQUEUE) || defined(CONFIG_SYSVIPC)      .ipc_ns                 =&init_ipc_ns,#endif      .mnt_ns                 = NULL,      .pid_ns_for_children    =&init_pid_ns,#ifdef CONFIG_NET      .net_ns                 =&init_net,#endif#ifdef CONFIG_CGROUPS      .cgroup_ns        =&init_cgroup_ns,#endif#ifdef CONFIG_TIME_NS      .time_ns          =&init_time_ns,      .time_ns_for_children   =&init_time_ns,#endif};

于是可以得出这样的结论，如果可以将容器中进程的nsproxy结构体替换成init_proxy，那么就可以突破namespaces的限制，进而达到逃逸的目的。恰好，内核提供了这样的函数switch_task_namespaces：

代码语言：javascript代码运行次数：0运行复制

void switch_task_namespaces(struct task_struct *p,struct nsproxy *new){      struct nsproxy *ns;      might_sleep();      task_lock(p);      ns = p->nsproxy;      p->nsproxy = new;      task_unlock(p);      if(ns)            put_nsproxy(ns);}

这个函数在内核中的实现非常简单，该函数接受task_struct和nsproxy结构体指针作为参数，将task_struct中nsproxy指针指向了传进来的参数。

对于容器中进程来说，它们位于相同的PID namespaces中。容器中所有的进程都是通过该PID namespaces中的1号进程直接或间接fork而来的。可以通过内核函数find_task_by_vpid(1)获取容器内init进程的task_struct

代码语言：javascript代码运行次数：0运行复制

void *g = find_task_by_vpid(1);switch_task_namespaces(g, (void*)init_nsproxy);

通过调用这两个函数，成功将容器内的init进程切换到了init_nsproxy。至此，逃逸已经完成了一半。最后只需要将漏洞利用进程切换到和init进程相同的namespaces中去即可完成逃逸。这需要使用到setns系统调用[5]，该系统调用的功能就是将进行此系统调用的进程切换到指定的namespaces中。

代码语言：javascript代码运行次数：0运行复制

#define _GNU_SOURCE             /*See feature_test_macros(7) */#include int setns(int fd,int nstype);

只有拥有CAP_SYS_ADMIN权限的进程才能进行setns系统调用，如果想要切换mnt namespaces还额外需要CAP_SYS_CHROOT权限。参数fd是一个指向/proc/[pid]/ns/目录下文件的文件描述符；参数nstype指定了想要切换的namespaces，如果指定为0内核会根据fd指向的文件切换对应的namespaces。例如 setns(/proc/1/ns/mnt, 0)，其中[pid]为1，即刚刚切换的容器内init进程的进程号，这样可以切换mnt namespaces以访问宿主机上的文件系统，同理可以切换PID namespaces以查看运行在宿主机上的进程。

每个进程都有一个/proc/[pid]/ns/子目录，以软链接的方式展示可以使用setns系统调用的namespaces。在宿主机中查看进程的namespaces：

代码语言：javascript代码运行次数：0运行复制

$ ls -al /proc/self/nstotal 0dr-x--x--x 2 xsw xsw 0 Feb 22 23:14 .dr-xr-xr-x 9 xsw xsw 0 Feb 22 23:14 ..lrwxrwxrwx 1 xsw xsw 0 Feb 22 23:15 cgroup ->cgroup:[4026531835]lrwxrwxrwx 1 xsw xsw 0 Feb 22 23:15 ipc ->ipc:[4026531839]lrwxrwxrwx 1 xsw xsw 0 Feb 22 23:15 mnt ->mnt:[4026531840]lrwxrwxrwx 1 xsw xsw 0 Feb 22 23:15 net ->net:[4026531957]lrwxrwxrwx 1 xsw xsw 0 Feb 22 23:15 pid ->pid:[4026531836]lrwxrwxrwx 1 xsw xsw 0 Feb 22 23:15 user ->user:[4026531837]lrwxrwxrwx 1 xsw xsw 0 Feb 22 23:15 uts ->uts:[4026531838]

启动一个容器，再次查看：

代码语言：javascript代码运行次数：0运行复制

# ls -al /proc/self/nstotal 0dr-x--x--x 2 root root 0 Feb 23 07:15 .dr-xr-xr-x 9 root root 0 Feb 23 07:15 ..lrwxrwxrwx 1 root root 0 Feb 23 07:15 cgroup ->'cgroup:[4026531835]'lrwxrwxrwx 1 root root 0 Feb 23 07:15 ipc ->'ipc:[4026532758]'lrwxrwxrwx 1 root root 0 Feb 23 07:15 mnt ->'mnt:[4026532756]'lrwxrwxrwx 1 root root 0 Feb 23 07:15 net ->'net:[4026532816]'lrwxrwxrwx 1 root root 0 Feb 23 07:15 pid ->'pid:[4026532814]'lrwxrwxrwx 1 root root 0 Feb 23 07:15 user ->'user:[4026531837]'lrwxrwxrwx 1 root root 0 Feb 23 07:15 uts ->'uts:[4026532757]'

可以发现对应的ipc、mnt、net、pid和uts发生了变化，说明容器创建了对应的namespaces。利用漏洞进行提权、逃逸，在弹出的root shell中再次查看：

代码语言：javascript代码运行次数：0运行复制

# ls -al /proc/self/nstotal 0dr-x--x--x 2 root root 0 Feb 22 23:16 .dr-xr-xr-x 9 root root 0 Feb 22 23:16 ..lrwxrwxrwx 1 root root 0 Feb 22 23:16 cgroup ->cgroup:[4026531835]lrwxrwxrwx 1 root root 0 Feb 22 23:16 ipc ->ipc:[4026532758]lrwxrwxrwx 1 root root 0 Feb 22 23:16 mnt ->mnt:[4026531840]lrwxrwxrwx 1 root root 0 Feb 22 23:16 net ->net:[4026532816]lrwxrwxrwx 1 root root 0 Feb 22 23:16 pid ->pid:[4026532814]lrwxrwxrwx 1 root root 0 Feb 22 23:16 user ->user:[4026531837]lrwxrwxrwx 1 root root 0 Feb 22 23:16 uts ->uts:[4026532757]

为了不让完整的漏洞利用功亏一篑，由于我们已经通过漏洞利用实现了任意内核代码执行，可以考虑直接调用系统调用对应的内核函数完成namespaces的切换。sys_setns即为setns系统调用在内核中调用的函数，同理do_sys_open是open系统调用对应的内核函数。

代码语言：javascript代码运行次数：0运行复制

long mnt_fd = do_sys_open(AT_FDCWD,"/proc/1/ns/mnt", O_RDONLY,0);sys_setns(mnt_fd,0);long pid_fd = do_sys_open(AT_FDCWD,"/proc/1/ns/pid", O_RDONLY,0);sys_setns(pid_fd,0);

值得注意的是，K8s在1.19版本中才正式引入了Seccomp[8]。在没有Seccomp限制的版本仍然可以使用setns进行切换。

通过以上分析，我们总结出以下结论：在利用内核漏洞达到执行任意内核代码后，可以首先通过switch_task_namespaces(find_task_by_vpid, init_nsproxy)切换容器中init进程的namespaces，然后调用commit_creds(prepare_kernel_cred(0))进行提权以获取全部的Capabilities。在拿到CAP_SYS_ADMIN后，通过setns(open(“/proc/1/ns/mnt”,O_RDONLY), 0)可以成功完成容器逃逸。

二、内核提权，不止于此

通常情况下，对于内核漏洞来说，通过一些漏洞利用的手法，最终可以覆盖函数指针或者覆盖栈上的函数返回地址，劫持控制流到攻击者控制的内存区域（ret2usr）或者进行ROP，获取执行任意内核代码的能力，接着执行commit_creds(prepare_kernel_cred(0))进行提权。在实践的过程中，我们注意到还有一些内核漏洞及利用手法，采用了不同的提权方式，而这些漏洞也可能为容器逃逸提供便利。

1CVE-2016-5195

CVE-2016-5195即为大名鼎鼎的DirtyCoW漏洞，该漏洞利用Linux内核的写时复制（Copy-on-write）机制创建了条件竞争场景，成功绕过了vDSO对于内存权限的限制，攻击者可以实现本地提权。vDSO是一个共享库，内核会将其加载到所有进程的用户地址空间中。vDSO主要解决一些对于执行时间敏感的系统调用执行时间过长的问题。当root进程调用vDSO地址空间的函数时，注入的shellcode将会被执行。将反弹shell的代码写入到shellcode中，那么则会向指定IP和端口反弹一个root shell。

该原理也可用于容器逃逸，由于shellcode的调用者是宿主机上的进程，即使在没有切换namespaces的条件下也可以实现容器的逃逸。

vDSO的内存区域被设置为不可写，如果想要修改权限需要用到set_memory_rw 内核函数，其利用过程依然需要实现内核任意代码的执行。但是CVE-2016-5195利用Linux内核的Copy-on-Write机制的漏洞绕过了权限检查，最终实现了向vDSO中注入代码。

2CVE-2018-18955

CVE-2018-18955是一个逻辑漏洞，在这里不展开介绍其漏洞原理，有兴趣的读者可以从exploit-db[9]获取完整ExP进行复现，利用Metarget[10]辅助进行环境搭建。该漏洞恰好位于user namespaces的实现中，攻击者在容器内读取到宿主机中的密码文件等敏感文件，间接实现了容器逃逸。这里的逃逸没有突破namespaces的限制，但是客观上对宿主机的机密性造成了破坏。

Calliper 文档对比神器

文档内容对比神器

28 查看详情

如果一个漏洞发生在和权限管理以及容器实现机制相关的代码中，那么利用手段通常会和常见的内存类漏洞有所不同。对于这类漏洞，只能具体问题具体分析，这要求攻击者对内核有更加深入的了解。

3CVE-2022-0185

CVE-2022-0185[11]是一个“新鲜出炉”的Linux内核提权漏洞，绿盟科技研究通讯已经发布文章《Linux内核漏洞——CVE-2022-0185分析与思考》对此漏洞进行了介绍。这里主要想要介绍该漏洞依赖的另一种常见的提权手段：modprobe_path。CVE-2022-0185利用fsconfig系统调用实现上的漏洞，可以溢出任意字节。在覆盖了内核中的指针后，实现了内核任意读和内核任意写。攻击者覆盖了内核中变量modprobe_path，使得内核会以root权限执行用户指定的脚本，达到提权的目的。

modprobe_path变量保存着一个文件路径，每当加载或卸载内核模块、执行内核不识别的可执行程序时，modprobe_path指定路径的程序将会以root权限运行。提权准备一个脚本程序，该程序会设置/bin/bash的suid位。利用任意写等漏洞将modprobe_path覆盖为脚本程序的路径，然后执行一个错误的格式的文件。此时，/bin/bash会被设置为suid为，然后执行/bin/bash -p启动一个root权限的shell，即可达到提权的目的。

但是，通过modprobe_path只能完成容器内的提权操作。即使获得了完整的Capabilities，所有的操作也会受到Namespaces和Cgroups的限制，无法逃逸。而且，针对modprobe_path在提权中的滥用，内核实现了STATIC_USERMODEHELPER机制。在开启了STATIC_USERMODEHELPER的系统上，无法通过覆盖modprobe_path实现提权。

继续利用CVE-2022-0185，攻击者泄露了堆地址，最终通过ROP实现了内核代码任意执行，按照本文第一节的思路实现了容器逃逸。

本节以三个实际的漏洞案例展示了区别于经典commit_creds(prepare_kernel_cred(0))的Linux提权方式，除此以外，还有劫持prctl等提权方案。同时也可以看到，提权和逃逸操作并不完全等同，劫持vDSO的手段可以实现容器逃逸，而由于modprobe_path指向的文件是受到mnt namespaces隔离的，劫持modprobe_path不能实现容器的逃逸。

一个内核漏洞是否能够实现容器提权，除了漏洞本身外，很大程度也取决于漏洞利用的手法，这要求分析者不仅要对容器的实现原理了然于心，而且还需要对内核有充分的理解、对内核漏洞利用有足够的经验。这对分析人员提出了非常高的要求。下一节将从逃逸的角度给出内核漏洞的分析思路，不聚焦于漏洞利用的手段，而是主要关注内核漏洞和容器逃逸的关系。

三、分析思路

在验证漏洞利用程序可以进行本地提权后，应当如何进行容器逃逸？分析思路不是一成不变的，应当根据具体情况灵活选择。下面的步骤仅仅是一个参考，在实践时还需要结合实际进行考量。

1判断漏洞利用前提

和宿主机的环境相比，容器环境往往存在更多的防御机制。我们应当首先判断Capabilities和Seccomp限制情况。对于实验环境，尤其需要关注权限的限制。不同的容器引擎对于权限的默认配置也不同，构造什么样的环境取决于漏洞利用的目的。

构造实验环境时，我们还需要关注一些隐性条件。例如，该漏洞或利用程序是否依赖于开启某个编译选项、利用程序是否假设了一些防御机制未开启等。

2判断提权漏洞利用的方法

首先应当对漏洞提权利用程序有初步的了解，判断漏洞利用程序所需的Capabilities权限和需要的系统调用。如果漏洞的触发需要特殊的Capabilities，利用程序通常会进行unshare系统调用以创建user namespaces。除了unshare系统调用，漏洞利用程序可能还会使用到一些敏感的系统调用。例如上文提到的CVE-2016-5195漏洞利用程序在进行代码注入时，使用了ptrace系统调用。

接下来，需要判断提权的方法：

利用commit_cred(prepare_kernel_cred(0))进行提权

可以初步判断，漏洞利用程序是通过执行内核代码实现的内核提权。对于这种情形可以考虑直接构造逃逸的利用链[12]。

覆盖modprobe_path或劫持prctl实现的提权

基于modprobe_path和劫持prctl的提权方式不能直接应用于容器的逃逸。对于这种情况，需要继续构造利用链。CVE-2022-0185利用程序的作者首先使用modprobe_path的方式进行本地提权，对于容器逃逸，作者继续利用溢出漏洞构造了ROP利用链，最终实现了内核代码任意执行。

覆盖vDSO进行提权

上文已经进行了分析，利用vDSO可以实现容器的逃逸。对于这种情形可以考虑直接进行漏洞利用。

逻辑漏洞导致的提权

相关权限管理和容器实现机制产生的漏洞，需要深入挖掘内核相关的机制，具体案例具体分析。

3逃逸利用

最后即为漏洞利用过程，需要构造payload。在构造payload时，仍然有一些问题需要考虑。例如，绕过KALSR需要考虑使用相对于内核的偏移量+内核基址进行调用、漏洞利用是否对内存布局有限制等问题。只有将所有问题考虑周全，才能构造出一个可用的漏洞利用程序。

四、进一步思考：自动化利用

漏洞自动化利用（AEG）如火如荼的今天，容器逃逸如果可以工具化、工程化将大大提高漏洞利用的效率。本节将展望利用Linux内核漏洞的容器自动化逃逸，并梳理其实现的技术难点，希望对感兴趣的读者有所启发。

假设已经通过一些漏洞利用手段获得了内核代码任意执行的能力，自动化利用需要将逃逸代码注入到payload中。程序的输入是内核漏洞利用程序的源代码，输出则是容器逃逸的漏洞利用程序。自动化利用的程序面临着以下难点：

1. 识别内核漏洞提权所使用的方法。如上文所述，提权具有多种方法。即使输入的漏洞利用代码是通过执行内核代码commit_creds(prepare_kernel_cred(0))进行提权，也需要考虑是通过ret2usr或者ROP甚至是直接注入shellcode进行的。从编译器的角度看，其都以数据的形式存在，想要进行区分需要识别具体的特征。

2. 识别payload。和难点1相同，payload总是以代码和数据形式存在的。只有定位了payload，才能将提权的代码注入到payload中。除识别payload外，还需要识别注入点在payload的偏移量。

3. 生成正确形式的payload。由于KASLR的存在，对于内核中函数或者变量的引用都需要使用内核基址+相对于内核基址的偏移量。首先需要确认利用源码中绕过KASLR的代码，识别出内核基址保存在哪个变量中。同时还需要搭建本地环境，在本地环境中计算出其相对于内核基址的偏移量。

以上就是The Route to Host：从内核提权到容器逃逸的详细内容，更多请关注创想鸟其它相关文章！