Impact

In runc, netlink is used internally as a serialization system for specifying the relevant container configuration to the C portion of our code (responsible for the based namespace setup of containers). In all versions of runc prior to 1.0.3, the encoder did not handle the possibility of an integer overflow in the 16-bit length field for the byte array attribute type, meaning that a large enough malicious byte array attribute could result in the length overflowing and the attribute contents being parsed as netlink messages for container configuration.

This vulnerability requires the attacker to have some control over the configuration of the container and would allow the attacker to bypass the namespace restrictions of the container by simply adding their own netlink payload which disables all namespaces.

Prior to 9c444070ec7bb83995dbc0185da68284da71c554, in practice it was fairly difficult to specify an arbitrary-length netlink message with most container runtimes. The only user-controlled byte array was the namespace paths attributes which can be specified in runc's config.json, but as far as we can tell no container runtime gives raw access to that configuration setting -- and having raw access to that setting would allow the attacker to disable namespace protections entirely anyway (setting them to /proc/1/ns/... for instance). In addition, each namespace path is limited to 4096 bytes (with only 7 namespaces supported by runc at the moment) meaning that even with custom namespace paths it appears an attacker still cannot shove enough bytes into the netlink bytemsg in order to overflow the uint16 counter.

However, out of an abundance of caution (given how old this bug is) we decided to treat it as a potentially exploitable vulnerability with a low severity. After 9c444070ec7bb83995dbc0185da68284da71c554 (which was not present in any release of runc prior to the discovery of this bug), all mount paths are included as a giant netlink message which means that this bug becomes significantly more exploitable in more reasonable threat scenarios.

The main users impacted are those who allow untrusted images with untrusted configurations to run on their machines (such as with shared cloud infrastructure), though as mentioned above it appears this bug was not practically exploitable on any released version of runc to date.

Patches The patch for this is d72d057ba794164c3cce9451a00b72a78b25e1ae and runc 1.0.3 was released with this bug fixed.

Workarounds To the extent this is exploitable, disallowing untrusted namespace paths in container configuration should eliminate all practical ways of exploiting this bug. It should be noted that untrusted namespace paths would allow the attacker to disable namespace protections entirely even in the absence of this bug.

References commit d72d057ba794 ("runc init: avoid netlink message length overflows") https://bugs.chromium.org/p/project-zero/issues/detail?id=2241

Credits Thanks to Felix Wilhelm from Google Project Zero for discovering and reporting this vulnerability. In particular, the fact they found this vulnerability so quickly, before we made a 1.1 release of runc (which would've been vulnerable) was quite impressive.

For more information If you have any questions or comments about this advisory: Open an issue in our repo

Last updated 24 July 2024

"A bug was found in runc where runc exec --cap executed processes with non-empty inheritable Linux process capabilities, creating an atypical Linux environment and enabling programs with inheritable file capabilities to elevate those capabilities to the permitted set during execve(2).

This bug did not affect the container security sandbox as the inheritable set never contained more capabilities than were included in the container's bounding set."

Please bump to 1.1.2.

https://bugs.gentoo.org/844085

Impact It was found that AppArmor, and potentially SELinux, can be bypassed when /proc inside the container is symlinked with a specific mount configuration.

Patches Fixed in runc v1.1.5, by prohibiting symlinked /proc: https://github.com/opencontainers/runc/pull/3785

This PR fixes CVE-2023-27561 as well.

Workarounds Avoid using an untrusted container image.

Last updated 24 July 2024

(I'm not subscribed to openwall and wasn't in Cc -- hopefully this gets treated like a reply properly...)

On 2024-09-03, Mike O'Connor said: While I suspect there's enough mitigating factors for this vuln to truly be low severity, proving that arbitrary file creation isn't super-severe (let alone risky) can be hard. I'm thinking of the Palo Alto mess CVE-2024-3400 from a few months back, where such behavior was thought to not be as big of a deal... until it was.

What is the security impact of creating an empty /etc/nologin? Or an empty override file that might cause some systemd service (e.g. some firewall setup) to not to run upon reboot/restart? Have there been OS assessments about where empty arbitrarily-named files can do the most disruption? Maybe a title like:

touch considered harmful: How the presence of a file can change OS and application behavior and make your head hurt

Sure, there's predictable tmp, and the impact of removing/overwriting files is pretty obvious. But, this runc writeup reminded me that the impact of arbirary file creation often gets short-changed. These are very good points, thanks!

We went back and forth on the assessment and we discussed the possibility of DoSes by creating files and so on, but we weren't aware of an analysis that showed what the practical impact could be and what a reasonable scoring should be. Does it make sense for every 0-byte file creation bug to get C:H/I:H/A:H by default? Should we always analyse the severity based on the worst possible hypothetical scenario even if it's not clear in advance (such as a cron job running filenames as commands, as in CVE-2024-3400)?

The other issue is that these kinds of attacks (involving a malicious configuration) are not entirely within runc's threat model and so there is an argument that the CVSS score should be 0, but given that tools like Docker and Kubernetes (especially the latter) allow untrusted users to do somewhat arbitrary configurations we have to shoulder the brunt of security issues that come out of that (regardless of runc's threat model).

But yeah, there is probably an argument to be made that the impact could be argued as moderate, but I wasn't convinced there was a strong enough justification to show that I:M is justified for such a restricted file-creation attack nor was it clear how to analyse C: and H: outside of coming up with hypotheticals that might not be accurate in practice.

I will keep this discussion in mind when we discuss formalising the runc threat model!

-- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>

Impact

A bug was found in Moby (Docker Engine) where containers were incorrectly started with non-empty inheritable Linux process capabilities, creating an atypical Linux environment and enabling programs with inheritable file capabilities to elevate those capabilities to the permitted set during execve(2). Normally, when executable programs have specified permitted file capabilities, otherwise unprivileged users and processes can execute those programs and gain the specified file capabilities up to the bounding set. Due to this bug, containers which included executable programs with inheritable file capabilities allowed otherwise unprivileged users and processes to additionally gain these inheritable file capabilities up to the container's bounding set. Containers which use Linux users and groups to perform privilege separation inside the container are most directly impacted.

This bug did not affect the container security sandbox as the inheritable set never contained more capabilities than were included in the container's bounding set.

Patches

This bug has been fixed in Moby (Docker Engine) 20.10.14. Users should update to this version as soon as possible. Running containers should be stopped, deleted, and recreated for the inheritable capabilities to be reset.

This fix changes Moby (Docker Engine) behavior such that containers are started with a more typical Linux environment. Refer to capabilities(7) for a description of how capabilities work. Note that permitted file capabilities continue to allow for privileges to be raised up to the container's bounding set and that processes may add capabilities to their own inheritable set up to the container's bounding set per the rules described in the manual page. In all cases the container's bounding set provides an upper bound on the capabilities that can be assumed and provides for the container security sandbox.

Workarounds

The entrypoint of a container can be modified to use a utility like capsh(1) to drop inheritable capabilities prior to the primary process starting.

Credits

The Moby project would like to thank Andrew G. Morgan for responsibly disclosing this issue in accordance with the Moby security policy.

For more information

If you have any questions or comments about this advisory:

Open an issue Email us at security@docker.com if you think you’ve found a security bug