Linux Kernel Vulnerability: Escaping Containers by Abusing Cgroups

CVE-2022-0492, a recently disclosed high-severity Linux vulnerability that relates to a weakness in the handling of release_agent in cgroups, could allow for container escape under some circumstances. Fortunately, in common container configurations, the various layers of security hardening will block the effective execution of this vulnerability.

However, as with all CVEs, it’s important to ensure that the patch is applied quickly. And as is generally the case with Linux kernel vulnerabilities, it’s also important that all affected systems are rebooted to ensure that the patched version is used. At the moment, paying attention to patching Linux hosts is especially relevant since there have been other critical vulnerabilities such as “Dirty Pipe” that also need to be addressed.

Back in November 2021, Team Nautilus detected the first real-world exploitation of this container escape technique.

The importance of defense-in-depth

There are a few excellent technical write-ups on the details of this vulnerability, including New Linux Vulnerability CVE-2022-0492 Affecting Cgroups: Can Containers Escape? and CVE-2022-0492: How Release_Agent Escape Became a Vulnerability. From these reports, we can see that this vulnerability — like other recent examples such as CVE-2022-0185 in January — shows the importance of using defense-in-depth techniques with containerization.

Docker and similar technologies take a layered approach to security, using several distinct Linux security mechanisms to provide process isolation. Namespaces, capabilities, seccomp filters, and AppArmor or SELinux all play a part in reducing the risks of container escape.

In this case, both the Docker default seccomp filter and AppArmor policy will block the exploitation of the vulnerability. Only if both are disabled does exploitation become possible.

While Docker will default to enable AppArmor and seccomp, Kubernetes disabled the default seccomp profile. So, for Kubernetes, this must be re-enabled in each workload or at the cluster level using mutating admission controllers such as OPA Gatekeeper or Kyverno. There’s also a Kubernetes feature in development that will allow this to be enabled by default.

The risks of user namespaces

Another thing that this vulnerability has in common with CVE-2022-0185 is that when user namespaces are enabled on the host, exploitation can be easier. User namespaces are intended to improve security by allowing processes to think they’re operating as root while not having full access to the underlying host.

However, user namespaces are a mixed blessing. Implementing them is complex. And when using them, it’s possible to get access to Linux kernel code paths that may have vulnerabilities.

Recommendations

There are a few practical actions that companies can take to reduce the impact of this CVE:

1. Most importantly, make sure that all hosts are regularly patched and rebooted to ensure that the new kernel version is in use.
2. Make sure that all the container security layers are used on all workloads. Specifically for Kubernetes, ensure that all workloads have a seccomp filter in place.
3. Don’t run containers as the root user unless absolutely necessary.
4. If the host doesn’t use user namespaces for its operation, make sure that this feature is disabled at the host level.

Conclusion

One of the challenges of using Docker-style containers that use the Linux kernel to provide isolation has always been the large attack surface that this presents. CVE-2022-0492 is another example of how important it is to take the time to harden your execution environment and make use of all the available layers of security. This will help you reduce the risk that attackers with access to containers can break out to the underlying host.