Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Control Groups (cgroups) are a Linux feature that allows for admins to limit and isolate resources for processes. Cgroups are managed via cgroupfs, a management API exposed as a file system; editing this file system will affect the cgroups. There are many different cgroup subsystems, such as the memory group.

Each subsystem is mounted at /sys/fs/cgroup/<subsystem>. Within these cgroups, there can be childs as well, such as docker. The vulnerability in this post is within cgroups.

One of the features within v1 of the cgroup functionality is release_agent. It allows admins to run a script upon the termination of a process within a c group. This is done by writing to the cgroupfs filesystem at /sys/fs/cgroup/memory/release_agent. This script runs with root permissions with access to all namespaces.

CVE-2022-0492 simply does NOT check that the process setting the release_agent file has admin privileges (CAP_SYS_ADMIN). As a result, anybody who can set this file is able to escalate privileges. Can this be used as a container escape?

The Linux filesystem sets the owner of the file to be root. As a result, only the root user or users with the CAP_DAC_OVERRIDE capability are allowed to do this. Although root only being able to edit this doesn't seem like a problem, the root user may not have full capabilities. Having a namespace within a different container is a different story though.

By default, cgroups in containers are mounted read only. A work around for this is to use the unshare SYSCALL to create a child user and cgroup namespace. However, the release_agent is only in the root cgroup, making this not exploitable in some cases. As a result, only the root container process can set the release agent. Interesting!

An additional method is possible with the CAP_SYS_ADMIN permission we can mount to the cgroupfs with no questions asked. With this, it would be possible to set the release_agent file for privilege escalation.

SELinux and AppArmour prevent BOTH of theses attack from the gate. This is because these prevent mounting to the cgroupfs from the container, making all of the attacks possible. To see if you are vulnerable, there is a list in the article and a script as well.

Overall, a super interesting container escape from a simple bug. The analysis of exploitability was fascinating. Defense-in-depth does work to prevent attacks!