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/>