容器逃逸之AppArmor绕过-CVE-2019-16884复现type
status
date
slug
summary
tags
category
icon
password
漏洞环境
环境部署 (X)
不过有个坑，这里自动搭建的 runc 版本有点问题，见 issue89
这里使用 ssst0n3 大佬的镜像
一定要创建网络噢，否则SSH连不上去
漏洞影响版本
- runC <= 1.0.0-rc8 (Docker < 19.03.1)
漏洞与 AppArmor 有关
漏洞描述
在容器镜像中可以声明一个VOLUME, 挂载至/proc, 欺骗runc使其认为AppArmor已经成功应用，从而绕过AppArmor策略。
AppArmor
相信不少同学在Centos搭建环境被 SELinux 坑过不少，AppArmor 作为 SELinux 代替品出现，是一个Linux内核安全模块，允许系统管理员通过每个程序的配置文件限制程序的功能，上手和易用性比SELinux友好太多。
该模块可以从宿主机中设置相应的规则，限制容器内的文件能不能从容器内被读写执行，
Docker 在 Linux 中也是通过查看
/sys/module/apparmor/parameters/enabled 判断宿主机是否开启 AppArmor，如不开启则开启Docker默认AppArmor策略。具体runC在启动容器时会尝试加载AppArmor策略：将 exec+AppArmor策略文件路径写入 /proc/self/attr/exec，可参考源码，后面/proc/<pid>/attr会在使用主要的安全模块时使用到。Process attributes associated with “major” security modules should be accessed and maintained using the special files in /proc/…/attr. A security module may maintain a module specific subdirectory there, named after the module. /proc/…/attr/smack is provided by the Smack security module and contains all its special files. The files directly in /proc/…/attr remain as legacy interfaces for modules that provide subdirectories.
修改
/proc/self/attr/exec内容，可以在exec时修改限制策略。 
The /proc/self/attr/exec file can be written to change the tasks confinement at exec time. It is used to perform the change_onexec operation.
漏洞分析
CVE-2019-16884 可以使得用户绕过AppArmor的一些策略进而可以实现一些越权操作，上面提到 docker 加载 AppArmor 是通过写入
/proc/self/attr/exec 实现的，我们可以通过挂在 /proc 卷让 runC 误认为它已成功加载 AppArmor 策略。不过 runc 在挂载时
checkMountDestination 方法有对 /proc 进行黑名单校验第2个链接如下代码判断存在逻辑问题
经调试，
rootfs 和 dest 依次为
输出
也就是说黑名单没有起作用！缺少了个
path=="." 的判断，如有正确判断，checkMountDestination 方法会返回异常调用链为
libcontainer.Init() -> prepareRootfs() -> mountToRootfs() -> checkMountDestination()
–> apparmor.ApplyProfile(l.config.AppArmorProfile)
可以注意到，应用 AppArmor 在挂载 rootfs 之后，Debug 一下确实是如此。前面我们知道 AppArmor 通过写入
/proc/self/attr/exec 去写入 AppArmor 规则的，那按理说，我们在先伪造 /proc 目录，然后 AppArmor 还是可以正常写入 /proc/self/attr/exec 才对？因为我一开始是想着 AppArmor 先写入，然后被我们伪造的 /proc 路径给覆盖了。既然能正常写入 /proc/self/attr/exe 那为啥还能bypass apparmor呢？这边调试一下，确保 AppArmor 文件确实写进去了，
执行一下 ls 命令是为了确定是否进入到容器里面了
获取
/proc/self/attr/exec 内容确实写入了，但为啥 /flag 还是能正常读取？因为写入 runc 产生的
procfs 因为他的 procfs 是容器的，每个进程运行时才能看到他们进程自己专属的 /proc/self 目录，自己伪造的是一个真实的文件系统 没有这种特性漏洞利用
ssh 登陆至容器，注意不能 docker exec 进入，因为这个镜像里面通过 qemu 模拟了一个镜像，这个镜像才是漏洞环境
创建apparmor规则
应用规则
随便建个 flag 文件
启动一个正常镜像，无权限读取/flag内容
创建一个恶意镜像
利用
漏洞修复
在执行mount操作前，检查目的路径是否为/proc或位于/proc下, 如果是，则必须为
procfs其他
关于断点调试点一些小坑
因为 docekr 的各个组件的调用顺序是 docker run -> dockerd -> containerd -> containerd-shim -> runc ，因为 runc 是 cli 来的，我们并不知道入参是什么，这里用了个笨方法，依次拉 docker cli、dockerd、containerd 和 runc 的代码下来，然后 docker cli -> dockerd 是 HTTP REST 请求，dockers -> containerd 是 gRPC 请求，经 debug 发现 dockerd 通过 containerd 依赖的 client 去 gRPC调用。然后调用 containers-shim 以及 containers-shim 调 runc 通过系统命令调用，一开始在 moby 库找了很多 runc 代码发现没有 rootfs.go 这个文件，原来是 moby 并没有直接依赖 runc 的这部分代码。
各个版本
- docker-ce-19.03.2
- docker-ce-cli-19.03.2
- containerd.io-1.2.6-3
- runc-1.0.0-rc8
- 注意低版本编译默认没有开启 apparmor 选项，
tags "seccomp apparmor" seccomp选项需要安装依赖apt install pkg-configapt install libseccomp-dev
