Docker安全之: 攻击面分析

1、Docker的攻击面分析

Dcoker的安全性问题主要有以下四个方面：

内核固有的安全性问题以及其对namespace和cgroup的支持情况
Docker守护程序本身的安全性
默认或者用户自定义配置文件的安全性
内核的“强化”安全功能以及其对容器的作用

1.1 攻击面一：攻击内核本身

由于Docker容器本身是运行在宿主机器内核之上的。并且其基本的进程隔离和资源限制是由内核的Namespace模块和Cgroup模块完成的。所以内核本身的安全性就是容器安全性的前提。针对内核的任意代码执行或者路径穿越漏洞可能导致容器逃逸。

其次，虽然Linux内核主线从相当早的版本开始对Namespace的支持就已经完善。但是如果Docker运行在自定义内核之上，且该内核对Namespace和Cgroup的支持不完善。可能导致不可预料的风险。

当然，并不是所有针对内核的漏洞都可以在容器中顺利利用。Docker的Seccomp以及Capability限制导致容器中进程无法使用内核所有功能，许多针对内核不成熟系统调用或者不成熟模块的攻击会由于容器

限制无法使用。例如针对内核bpf模块进行攻击的CVE-2017-16995就因为Docker容器默认禁止bpf系统调用而无法成功。

1.2 攻击面二：攻击Docker守护进程本身

虽然Docker容器具有很强的安全保护措施，但是Docker守护进程本身并没有被完善的保护。Docker守护进程本身默认由root用户运行，并且该进程本身并没有使用Seccomp或者AppArmor等安全模块进行保护。这使得一旦攻击者成功找到漏洞控制Docker守护进程进行任意文件写或者代码执行，就可以顺利获得宿主机的root权限而不会受到各种安全机制的阻碍。值得一提的是，默认情况下Docker不会开启User Namespace隔离，这也意味着Docker内部的root与宿主机root对文件的读写权限相同。这导致一旦容器内部root进程获取读写宿主机文件的机会，文件权限将不会成为另一个问题。这一点在CVE-2019-5636利用中有所体现。

由于Docker使用Go语言编写，所以绝大部分攻击者都以寻找Docker的逻辑漏洞为主。除此之外，一旦Docker容器启动之后，容器内进程因为隔离很难再影响到Docker守护进程本身。所以针对Docker容器的攻击主要集中在容器启动或者镜像加载的过程中。

对于这一点，Docker提供了一些对于镜像的签名认证机制。并且官方也推荐使用受信任的镜像以避免一些攻击。

除此之外，针对Docker攻击的另一种方式是攻击与Docker守护进程进行通信的daemon socket。该攻击从宿主机进行，与容器逃逸无关，在此不多做赘述。

1.3 攻击面三：配置文件错误导致漏洞

通常来说，默认情况下Docker的默认容器配置是安全的。但是基于最小权限规则配置的配置文件可能会导致一些比较特殊的应用程序（例如需要特殊网络配置的VPN服务等）无法正常运行。为此Docker提供了自定义安全规则的功能。它允许用户使用自定义安全配置文件代替默认的安全配置来实现定制化功能。但是如果配置文件的配置不当，就有可能导致Docker的安全性减弱，攻击面增加的情况。

举例来说，Docker容器使用–privileged参数启动的情况下。容器中可以运行许多默认配置下由于隔离无法使用的应用（如VPN，路由系统等）。但是该参数也会关闭Docker的所有安全保护。任何攻击者只要取得容器中的root权限，就可以直接逃逸至宿主机并获得宿主机root权限。

1.4 攻击面四：安全模块绕过

Docker的安全设计很大程度上依赖内核的安全模块。一旦内核安全模块本身存在逻辑漏洞等情况导致安全配置被绕过，或者模块被手动关闭。Docker本身的安全也会受到极大的威胁。好在，Linux内核安全模块本身安全性是有保障的。在数十年的维护升级过程中，只存在极个别被绕过的情况。且近几年间没有相关漏洞的曝光。

因此，内核安全模块被攻击的风险只存在于自定义内核等比较稀少的情况。

2、Docker历史漏洞整理

2.1 Docker 容器逃逸漏洞(CVE-2020-15257）

2.2 CVE-2019-14271

CVE-2019-14271的评分为7.5。该漏洞的产生原因是在使用docker cp从docker中拷贝文件时。Docker的docker-tar进程会chroot到容器目录下并且加载libnss.so模块。而由于docker-tar本身并没有被Docker容器限制。攻击者可以通过替换libnss.so的方式得到在容器外宿主机执行任意代码的机会[5]。

2.2 CVE-2019-5736

CVE-2019-5736的评分为9.3分。造成该漏洞的主要原因是Docker守护进程在执行docker exec等需要在容器中启动进程操作时对/proc/self/exe的处理不当。如果用户启动了由攻击者准备的docker容器或者被攻击者获得了容器中的root权限。那么在用户执行docker exec进入容器时，攻击者就可以在宿主机执行任意代码。