semi-arbitrary cgroup resource write with malicious hugetlb configuration

[cyphar]

This is not a security issue, because it requires a malicious config.json. The following description is from a draft security advisory (which was assigned CVE-2023-45804 -- which has since been retracted) that has been closed.

---

When writing hugetlb cgroup limits, runc includes a user-provided string as part of the pathname, which was not sanitised. As a result, an malicious config.json would cause runc to write an arbitrary numerical value to a file within /sys/fs/cgroup as long as the file name ends with .limit_in_bytes (on a cgroupv1 system) or .max (on a cgroupv2 system) -- note that we verify all cgroupfs writes are to cgroupfs, and the suffix is hardcoded and determined by what cgroup configuration the host has.

In practice this means that an attacker could modify cgroup limits of an arbitrary cgroup on the system, which could result in denial-of-service attacks (by lowering the limits of system service cgroups) or allow the container process to get more resource access than permitted (by modifying its own cgroup, and any parent cgroups with limits).

This vulnerability has been assigned a CVE by GitHub (CVE-2023-45804), but according to our analysis this issue is outside of our threat model. Malicious config.json files are (generally) considered to be outside of the scope of runc's security model (a malicious config.json can be used to disable all namespaces and security primitives by design, so exploits that require modifying config.json are usually not considered vulnerabilities in runc).

The only exceptions are when higher-level runtimes (such as Kubernetes) have a security model that results in unsafe config.jsons being generated by untrusted users -- in our view, many such vulnerabilities are strictly speaking not vulnerabilities in runc, but in the interest of supporting the wider container community we treat them as vulnerabilities regardless.

However, as far as we can tell, even Kubernetes doesn't allow you to exploit this (the suffix of the hugepages- key used to configure the vulnerable path string in Kubernetes must be a valid size string and thus cannot contain ../), so as far as we are concerned this is not a vulnerability and there is no risk to runc users.

[cyphar]

Fixes already merged:

• 2c9598c ("libct/cgroups.OpenFile: clean "file" argument")
• b426e9b ("libct/cgroups.OpenFile: clean "file" argument") (backport)