容器逃逸之AppArmor绕过-CVE-2019-16884复现
2023-2-18
| 2024-5-28
0  |  阅读时长 0 分钟
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个链接如下代码判断存在逻辑问题
经调试,rootfsdest 依次为
输出
也就是说黑名单没有起作用!缺少了个 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 文件确实写进去了,
notion image
执行一下 ls 命令是为了确定是否进入到容器里面了
notion image
获取 /proc/self/attr/exec 内容确实写入了,但为啥 /flag 还是能正常读取?
 
因为写入 runc 产生的 procfs 因为他的 procfs 是容器的,每个进程运行时才能看到他们进程自己专属的 /proc/self 目录,自己伪造的是一个真实的文件系统 没有这种特性

漏洞利用

ssh 登陆至容器,注意不能 docker exec 进入,因为这个镜像里面通过 qemu 模拟了一个镜像,这个镜像才是漏洞环境
创建apparmor规则
应用规则
随便建个 flag 文件
启动一个正常镜像,无权限读取/flag内容
notion image
创建一个恶意镜像
利用
notion image

漏洞修复

在执行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-config
    • apt install libseccomp-dev

参考链接

  • 云安全
  • 漏洞复现
  • ArchLinux 双网卡 kubeadm Kubenetes 集群安装moby容器逃逸-CVE-2019-14271复现
    Loading...
    目录