Felix Wilhelm recently tweeted a Proof of Concept (PoC) of container escape abusing release agent for cgroup v1.
d=`dirname $(ls -x /s*/fs/c*/*/r* |head -n1)`
mkdir -p $d/w;echo 1 >$d/w/notify_on_release
t=`sed -n 's/.*perdir=([^,]*).*/1/p' /etc/mtab`
touch /o; echo $t/c >$d/release_agent;echo "#!/bin/sh
$1 >$t/o" >/c;chmod +x /c;sh -c "echo 0 >$d/w/cgroup.procs";sleep 1;cat /o— Felix Wilhelm (@_fel1x) July 17, 2019
To be able to perform the attack, container was run with the “–privileged” flag which is not a setup for security anyway. When using this flag, containers have full access to all devices and lack restrictions from seccomp, AppArmor, and Linux capabilities. Nevertheless, “–privileged” flag is just a simplification of the necessary requirements for this attack, which is SYS_ADMIN capability for the container itself, as well as VFS for cgroup v1 mount with the read and write permission.
Felix was able to inject a custom command into the mechanism known as a “notify_on_release” in cgroup v1. When the last task in a cgroup leaves it, a release agent is executed by the kernel via call_usermodehelper_exec() (UserModeHelper – UMH) mechanism. Since the kernel is doing ‘clean-up’, UMH is executed on the host outside of the namespace / container.
More information about release_agent can be found here:
https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt
Linux Kernel Runtime Guard (LKRG) has functionality of limiting an UMH interface. By default, it is allowed to execute only LKRG’s whitelisted programs. For some people it might be not enough and in that case LKRG has an ability to fully lock UMH and nothing can be executed via this interface. This might break things if your distro uses UMH to invoke any programs e.g. if you are using release_agent 😉
You can see how LKRG can save you by preventing and detecting Felix’s container escape (based on UMH) here:
Thanks,
Adam
Comments
Leave a Reply