[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240903.014649-personal.smudges.long.champ-QiEEimlh1P@cyphar.com>
Date: Tue, 3 Sep 2024 12:05:05 +1000
From: Aleksa Sarai <cyphar@...har.com>
To: security-announce@...ncontainers.org, oss-security@...ts.openwall.com
Subject: CVE-2024-45310: runc can be tricked into creating empty
files/directories on host
Due to the low severity of this CVE, this security patch is being released with
NO embargo period.
[ Summary ]
runc 1.1.13 and earlier as well as 1.2.0-rc2 and earlier can be tricked into
creating empty files or directories in arbitrary locations in the host
filesystem by sharing a volume between two containers and exploiting a race
with os.MkdirAll. While this can be used to create empty files, existing
files **will not** be truncated.
An attacker must have the ability to start containers using some kind of custom
volume configuration. Containers using user namespaces are still affected, but
the scope of places an attacker can create inodes can be significantly reduced.
Sufficiently strict LSM policies (SELinux/Apparmor) can also in principle block
this attack -- we suspect the industry standard SELinux policy may restrict
this attack's scope but the exact scope of protection hasn't been analysed.
This is exploitable using runc directly as well as through Docker and
Kubernetes.
The CVSS score for this vulnerability is
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N (Low severity, 3.6).
[ Workarounds ]
Using user namespaces restricts this attack fairly significantly such that the
attacker can only create inodes in directories that the remapped root
user/group has write access to. Unless the root user is remapped to an actual
user on the host (such as with rootless containers that don't use
/etc/sub[ug]id), this in practice means that an attacker would only be able to
create inodes in world-writable directories.
A strict enough SELinux or AppArmor policy could in principle also restrict the
scope if a specific label is applied to the runc runtime, though we haven't
thoroughly tested to what extent the standard existing policies block this
attack nor what exact policies are needed to sufficiently restrict this attack.
[ Patches ]
I've attached patches that apply cleanly for runc 1.1.13 and HEAD. We have also
released runc 1.1.14 and 1.2.0-rc3 which contain these patches, so if you
upgrade there is no need to apply these patches.
* CVE-2024-45310.patch applies cleanly on top of runc HEAD[1]. If you are
backporting the patch to apply on top of 1.2.0-rc2, you will need to also
apply [2] at least.
* 1.1-*.patch apply cleanly on top of 1.1.13.
[ Credit ]
Thanks to Rodrigo Campos Catelin (@rata) and Alban Crequy (@alban) from
Microsoft for discovering and reporting this vulnerability.
[ References ]
The GitHub security advisory for this issue will be visible here[3] once it has
become public.
[1]: 346b818dad833a5ae8ab55d670b716dadd45950e at time of writing.
[2]: https://github.com/opencontainers/runc/pull/4359
[3]: https://github.com/opencontainers/runc/security/advisories/GHSA-jfvp-7x6p-h2pv
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
View attachment "1.1-0001-rootfs-fix-can-we-mount-on-top-of-proc-check.patch" of type "text/x-patch" (11016 bytes)
View attachment "1.1-0002-rootfs-consolidate-mountpoint-creation-logic.patch" of type "text/x-patch" (10983 bytes)
View attachment "1.1-0003-rootfs-try-to-scope-MkdirAll-to-stay-inside-the-.patch" of type "text/x-patch" (11514 bytes)
View attachment "CVE-2024-45310.patch" of type "text/x-patch" (11532 bytes)
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.
