【云攻防系列】从CVE-2019-5736漏洞浅析AppArmor防御机制

随着云计算技术的日益成熟和 DevOps 概念的推广，越来越多的企业选择将其业务上云，基于云计算的容器技术在分布式计算环境中得到广泛部署。然而，容器在其生命周期内会存在多种安全威胁，如恶意镜像、运行时攻击和内核权限提升等。

目前，容器的安全防护主要依赖于 Linux 内核安全机制中的 DAC、MAC 和Namespace 隔离等技术。例如，对于 Ubuntu 系统而言，其会默认开启AppArmor 防护，该防护机制会为 docker 容器生成 docker-default 规则，以对 docker 容器内应用的行为进行限制，进而保障 docker 容器和 Linux 宿主机的安全。本文将从 docker 容器的 CVE-2019-5736 漏洞入手，浅析 AppArmor 对docker容器的实际防护效果，会从 CVE-2019-5736 漏洞概述及复现和探索 Apparmor 防御机制两个方面进行介绍。

2019年2月，runC 维护团队公布了影响 Docker、containerd、Podman 和 CRI-O 等默认运行时容器 runC 的严重漏洞 CVE-2019-5736。该漏洞是波兰 CTF 战队Dragon Sector 在CTF赛后对 runC 进行漏洞挖掘成功发现的，其能覆盖宿主机runC 程序完成容器逃逸。该漏洞关键点是在于 runC，docker 在运行 exec 类似功能的命令时，底层实际上是 runC 在执行，即由 runC 在容器内部执行用户指定的程序。

为深入探索 Apparmor 防御机制，在 docker 不同版本（v17.12 & v18.03）上使用不同 docker 命令进行了一系列实验。

【AppArmor】

AppArmor（Application Armor）是一种 MAC 机制，在自主访问控制 (DAC)基础上提供强制访问控制（MAC）来进一步保障 Linux 内核安全。不同于其他安全工具，AppArmor 旨在将程序限制在有限的资源集中，其将访问控制属性绑定到某个具体程序而并非系统用户。具体而言，每个进程都相应的有自己的安全配置文件，AppArmor 通过一个配置文件（profile）来指定一个应用程序的相关权限，即以白名单的方式定义该应用程序可以访问的系统资源。

AppArmor 配置文件会有两种工作模式，Enforce 和 Complain：

Enforce：此模式下加载的配置文件中定义的策略将强制执行，且会报告违规尝试（syslog/auditd）；

Complain：此模式下加载的配置文件中定义的策略不会强制执行，而是仅报告违反策略的尝试；

【docker exec/attach域】

• 在 docker 17.12 版本中，以 docker start/attach 方式运行的进程受 AppArmor 域的控制（docker-default 文件）；而以 docker exec 方式运行的进程则不受 AppArmor 域的控制，其在 AppArmor 看来算作 unconfined 域。

• 在 docker18.03 版本中，以 docker start/attach 方式和 docker exec 方式运行的进程均受 AppArmor (docker-default 文件)域的控制。

2.1 显示定义AppArmor 规则

2.1.1 实验方式

通过追踪 POC 运行状态，发现其在运行期间访问了如下路径：

[PATH-A]  /proc/<pid of each process>/cmdline[PATH-B]  /proc/<pid of the runc executed from docker exec>/exe[PATH-C]  /proc/<pid of the runc executed from docker exec>/fd/3

因此，可通过显式地在/etc/apparmor.d/abstractions/base加上下述规则，对AppArmor防御效果进行测试：

audit deny @{PROC}/@{pid}/cmdline rwklx,      #[RULE-A]audit deny @{PROC}/@{pid}/exe  rwklx,        #[RULE-B]audit deny @{PROC}/@{pid}/fd/* rwklx,         #[RULE-C]

2.1.2 实验现象

【某公有云主机】

    增加 [RULE-A] 后，POC 攻击被拦截，日志有 DENY 信息。

    增加 [RULE-B] 和 [RULE-C]，无法拦截 POC 攻击。

【本地主机】

    增加 [RULE-A] 后，使用 docker attach 或 docker exec 方式运行 POC：

1. POC 攻击每次都失败；

2. AppArmor 日志中每次都有 DENY，持续增加。

增加 [RULE-B] 和 [RULE-C] 后，无法拦截 POC 攻击。

2.1.3 现象解释

[RULE-A]生效：原因是 cmdline 是一个实际文件（至少不是 symlink）。

[RULE-B]不生效：原因是 PATH-B 指向宿主机 runc，而 AppArmor 只能过滤最终指向的文件的实际路径。

[RULE-C]不生效：原因是 PATH-C 也指向宿主机 runc。

2.2 docker 18.03测试分析

2.2.1 实验方式

鉴于 docker exec 和 docker attach 命令受 AppArmor 域控制不同，将采用以下两种方式进行 CVE-2019-5736 漏洞实验：1）exec 命令运行 POC 和 /bin/sh；2）attach 命令运行 POC，exec 命令运行 /bin/sh。

2.2.2 实验现象

【某公有云主机】

在 docker-default 规则防御下：i）POC攻击不被拦截；ii）AppArmor 日志中 audit 无对应 DENY 记录。

【本地主机】

• 使用 exec 方式运行 POC 和 /bin/sh：i）POC 攻击不被拦截；ii）AppArmor日志中 audit 无对应 DENY 记录。

• 使用 attach 运行POC，exec 方式运行 /bin/sh：i）POC 攻击不被拦截；ii）AppArmor 日志中 audit DENY 随机出现（重复4-5次实验），出现的话只有一条 DENY。

注：此处新建 malicious_directory 文件夹，以示与前文基础复现实验的区分。

2.2.3 实验解释