[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20240904.164536-sane.sobs.rich.isotope-eZfAeE5YI4N4@cyphar.com>
Date: Thu, 5 Sep 2024 03:04:49 +1000
From: Aleksa Sarai <cyphar@...har.com>
To: mjo@...o.mi.org
Cc: oss-security@...ts.openwall.com, security-announce@...ncontainers.org
Subject: Re: CVE-2024-45310: runc can be tricked into creating empty
files/directories on host
(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/>
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
