New Linux Kernel cgroups Vulnerability Could Let Attackers Escape Container

Details have emerged about a now-patched high-severity vulnerability in the Linux kernel that could potentially be abused to escape a container in order to execute arbitrary commands on the container host.

 

The shortcoming resides in a Linux kernel feature called control groups, also referred to as cgroups version 1 (v1), which allows processes to be organized into hierarchical groups, thereby making it possible to limit and monitor the usage of resources such as CPU, memory, disk I/O, and network.

 

Tracked as CVE-2022-0492 (CVSS score: 7.0), the issue concerns a case of privilege escalation in the cgroups v1 release_agent functionality, a script that’s executed following the termination of any process in the cgroup.

 

“The issue stands out as one of the simplest Linux privilege escalations discovered in recent times: The Linux kernel mistakenly exposed a privileged operation to unprivileged users,” Unit 42 researcher Yuval Avrahami said in a report published this week.

 

The man page for cgroups explains its function as follows –

 

Whether or not the release_agent program is invoked when a particular cgroup becomes empty is determined by the value in the notify_on_release file in the corresponding cgroup directory. If this file contains the value 0, then the release_agent program is not invoked. If it contains the value 1, the release_agent program is invoked. The default value for this file in the root cgroup is 0.

 

Specifically, the Palo Alto Networks threat intelligence team noted that the bug is a consequence of a missing verification to check whether the process setting the release_agent file had administrative privileges, thereby making it ripe for potential exploitation.

 

In other words, should this release_agent file be overwritten by an attacker, the kernel can be forced into calling an arbitrary binary configured in the release agent with the highest possible permissions – a scenario that could effectively allow a complete takeover of the machine.

 

It’s, however, worth noting that only processes with “root” privileges can write to the file, meaning that the vulnerability solely permits root processes to escalate privileges.

 

“At first glance, a privilege escalation vulnerability that can only be exploited by the root user may seem bizarre,” Avrahami explained. “Running as root doesn’t necessarily mean full control over the machine: There’s a gray area between the root user and full privileges that includes capabilities, namespaces and containers. In these scenarios where a root process doesn’t have full control over the machine, CVE-2022-0492 becomes a serious vulnerability.”

 

Although containers running with AppArmor or SELinux are protected from the flaw, users are recommended to apply the patches in light of the fact that it could be abused by other malicious host processes to elevate privileges.

 

This is far from the first time release_agent has resurfaced as an attack vector. In July 2019, Google Project Zero researcher Felix Wilhelm demonstrated a “quick and dirty” proof-of-concept (PoC) exploit leveraging the feature to break out of privileged Kubernetes and Docker containers.

 

Then in November 2021, cloud security firm Aqua disclosed details of a cryptocurrency mining campaign that used the exact same container escape technique to drop the XMRig coin miner on infected hosts, making it the first recorded instance of real-world exploitation.

 

“CVE-2022-0492 marks another Linux vulnerability that can be exploited for container escape,” Avrahami concluded. “Fortunately, environments that follow best practices are protected from this vulnerability. Environments with lax security controls hosting untrusted or publicly exposed containers are, unsurprisingly, at high risk.”

 

Full article attribution is made to its original source and author.