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

, ,
阅读： 1,997

前言

绿盟科技技术博客曾经发表过容器逃逸的技术文章《【云原生攻防研究】容器逃逸技术概览》[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则以内核模式执行以下代码：

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。

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

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

/*
 * 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 is copied.
 */
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在内核中实现如下：

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：

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

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

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

#define _GNU_SOURCE             /* See feature_test_macros(7) */
#include <sched.h>

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：

$ ls -al /proc/self/ns
total 0
dr-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]

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

# ls -al /proc/self/ns
total 0
dr-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中再次查看：

# ls -al /proc/self/ns
total 0
dr-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系统调用对应的内核函数。

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))进行提权。在实践的过程中，我们注意到还有一些内核漏洞及利用手法，采用了不同的提权方式，而这些漏洞也可能为容器逃逸提供便利。

1、CVE-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中注入代码。

2、CVE-2018-18955

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

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

3、CVE-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的代码，识别出内核基址保存在哪个变量中。同时还需要搭建本地环境，在本地环境中计算出其相对于内核基址的偏移量。

以上难点频繁提到了“识别”，实际上“识别”的操作实际已经超出了编译相关知识的范畴，笔者认为，应当结合NLP、AEG相关知识进行辅助。

五、 防御手段

前文主要站在攻击者角度进行讨论，本节将站在防御者的角度，主要介绍针对于内核漏洞导致的逃逸的防御手段。

1、最小权限原则

针对利用内核漏洞的容器逃逸手法最好的防御思路就是最小权限原则[13]。该概念最早由Peter J. Denning在1976年提出，指计算机中的每个主体（进程）只能访问当下所需要的客体（资源）。

Capabilities

Capabilities[14]在2.2版本引入内核，主要解决root权限过于集中的问题。Capabilities将内核的root权限划分为若干的能力，子进程会按照一定的规则继承父进程的能力。

多个漏洞的利用都会受到Capabilities的限制，CVE-2017-7308需要CAP_SYSLOG权限以绕过KASLR，CVE-2021-22555需要CAP_NET_ADMIN以触发漏洞。

如果一个容器只被赋予了所需的Capabilities，那么会显著增加漏洞的利用难度。

Seccomp

Seccomp[15]最早在3.16版本引入内核，其主要功能是限制进程使用特定的系统调用，子进程会继承父进程的seccomp限制。上文提到的Capabilities限制可以通过创建一个user namespaces进行绕过，在新的user namespaces中用户会被授予完整的Capabilities，但是仅局限于受限的环境中。创建user namespaces需要使用unshare系统调用，正如上文所提及的一样，作为敏感的系统调用unshare被docker的默认seccomp配置所限制。如果一个容器只赋予了程序所需的Capabilities和系统调用，那么大多数的内核漏洞都将无法被利用。

Seccomp和Capabilities共同作用，完成对容器安全的守护。

LSM

LSM，指Linux安全模块，例如SELinux[16]、AppArmor等。通过强制访问控制，限制进程可以访问的资源。相比于Capabilities和Seccomp，LSM可以进行更加细粒度的访问控制，包括可以访问文件、套接字等。但是，如何写出良好的LSM配置文件则是问题的难点。对于此问题，有多篇研究论文[17-19]。主流的方式是利用动态分析的方法，获取容器应用所需要的权限全集。或者使用静态的分析手段，结合程序分析的方法，自动生成配置文件。

Non-root containers

由于容器的创建需要使用namespaces，而namespaces的创建时需要特权操作，所以使用容器时默认情况下会得到一个root权限的环境。以Docker为例，默认会得到一个被Capabilities和Seccomp限制的root shell。Non-root containers实际上是最小权限原则在容器环境中的应用。同样以Docker为例，Docker提供了三种不同形式Non-root containers：

  1. Userns-remap[20]
  2. Rootless mode[21]
  3. USER containers[22]

Userns-remap是指容器的创建位于一个新的User namespaces中。利用User namespaces可以使用普通用户权限启动一个容器。Rootless mode的实现同样依赖于User namespaces，相比于Userns-remap，Docker的守护进程和容器都没有运行在root权限下。USER containers则是通过user映射实现的，在容器中能够以普通用户的权限执行程序。

2、安全防护系统

上文提供了多种防御机制，在启用上述机制的容器系统上逃逸已经变得困难重重。但是，网络安全没有银弹，为了避免百密一疏，还应配备安全防护系统提供专业防护。例如，通过漏洞扫描，及时发现并修复系统存在的安全漏洞；通过配置核查，及时找出并加固系统薄弱项；通过运行时入侵检测，及时发现异常攻击、漏洞利用行为等。

云原生时代，安全不可缺席。绿盟科技星云实验室将持续输出云原生安全研究成果，最新成果直接赋能绿盟科技云原生安全产品NCSS-C，为您的云原生业务保驾护航。

六、总结

本文分别从namespaces实现原理、典型逃逸漏洞、通用逃逸方法和防御手段等角度，就利用Linux内核漏洞进行逃逸做进行了深入的探讨。尽管每个漏洞各有各的不同，但是就容器逃逸来讲还是遵循了一些固定的步骤。无论是攻击者还是防御者，都应当尽可能深入了解其背后的原理，做到知其然更知其所以然。

同时也可以注意到，容器安全攻防博弈演进的特性，这也是整个信息安全领域的基本特征。攻击和防御手段的进步是相辅相成的，防御机制会促进新型攻击手法的诞生，新型攻击手法则又会对防御机制提出更高的要求。本文的重点在攻击，但也是想帮助防御者理解容器逃逸的攻击方法，毕竟，未知攻，焉知防？

最后，向大家推荐由绿盟科技星云实验室编写的《云原生安全：攻防实践与体系构建》一书，本书系统梳理云原生安全可能面临的威胁与风险，给出切实可行的防护方案，随书附带丰富的配套实验。云原生从业者以及对云原生安全感兴趣的同学一定不要错过！

参考资料

  1. https://mp.weixin.qq.com/s/_GwGS0cVRmuWEetwMesauQ
  2. GitStats – linux (phoronix.com)
  3. Project Zero: Exploiting the Linux kernel via packet sockets (googleprojectzero.blogspot.com)
  4. Kemerlis V P, Portokalidis G, Keromytis A D. {kGuard}: Lightweight Kernel Protection against {Return-to-User} Attacks[C]//21st USENIX Security Symposium (USENIX Security 12). 2012: 459-474.
  5. setns(2) – Linux manual page (man7.org)
  6. namespaces(7) – Linux manual page (man7.org)
  7. Seccomp security profiles for Docker | Docker Documentation
  8. Restrict a Container’s Syscalls with seccomp | Kubernetes
  9. Linux – Broken uid/gid Mapping for Nested User Namespaces – Linux local Exploit (exploit-db.com)
  10. Metarget/metarget: Metarget is a framework providing automatic constructions of vulnerable infrastructures. (github.com)
  11. Will’s Root: CVE-2022-0185 – Winning a $31337 Bounty after Pwning Ubuntu and Escaping Google’s KCTF Containers (willsroot.io)
  12. Route to Root: Container Escape Using Kernel Exploitation (cyberark.com)
  13. J. Denning. Fault tolerant operating systems. ACM Computing Surveys (CSUR). December 1976, 8 (4): 359 – 389. ISBN 0360-0300.
  14. capabilities(7) – Linux manual page (man7.org)
  15. seccomp(2) – Linux manual page (man7.org)
  16. selinux(8) – Linux manual page (man7.org)
  17. Ghavamnia S, Palit T, Benameur A, et al. Confine: Automated system call policy generation for container attack surface reduction[C]//23rd International Symposium on Research in Attacks, Intrusions and Defenses (RAID 2020). 2020: 443-458.
  18. Mattetti M, Shulman-Peleg A, Allouche Y, et al. Securing the infrastructure and the workloads of linux containers[C]//2015 IEEE Conference on Communications and Network Security (CNS). IEEE, 2015: 559-567.
  19. Lei L, Sun J, Sun K, et al. SPEAKER: Split-phase execution of application containers[C]//International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment. Springer, Cham, 2017: 230-251.
  20. Isolate containers with a user namespace | Docker Documentation
  21. Run the Docker daemon as a non-root user (Rootless mode) | Docker Documentation
  22. Dockerfile reference | Docker Documentation

版权声明

本站“技术博客”所有内容的版权持有者为绿盟科技集团股份有限公司（“绿盟科技”）。作为分享技术资讯的平台，绿盟科技期待与广大用户互动交流，并欢迎在标明出处（绿盟科技-技术博客）及网址的情形下，全文转发。
上述情形之外的任何使用形式，均需提前向绿盟科技（010-68438880-5462）申请版权授权。如擅自使用，绿盟科技保留追责权利。同时，如因擅自使用博客内容引发法律纠纷，由使用者自行承担全部法律责任，与绿盟科技无关。

Spread the word. Share this post!

Meet The Author