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^[1], also referred to as
cgroups version 1 (v1), which allows processes to be organized into
hierarchical groups, effectively 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^[2]
(CVSS score: 7.0), the issue^[3]
concerns^[4]
a case^[5]
of privilege escalation^[6]
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^[7]
in a report published this week.

The man page^[8]
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^[9]
or SELinux^[10] are protected from the
flaw, users are recommended to apply^[11] the patches^[12] 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 emerged as an
attack vector. In July 2017, Google Project Zero researcher Felix
Wilhelm demonstrated^[13] 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^[14] 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.”