(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/>
signature.asc
Description: PGP signature
