(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/>
Last updated 24 July 2024
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.
"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
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
Last updated 24 July 2024