Bug 2309336 (CVE-2024-45310)

Summary: CVE-2024-45310 runc: runc can be tricked into creating empty files/directories on host
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: asdas, bmontgom, dpaolell, eparis, jburrell, jdelft, jupierce, lgarciaa, mbiarnes, mijjapur, nstielau, prodsec-dev, security-response-team, sidsharm, sponnaga, talessio, vlaad, ximhan, yuxzhu
Target Milestone: ---Keywords: Security
Target Release: ---Flags: mijjapur: needinfo? (prodsec-dev)
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
A vulnerability was found in runc. A malicious attacker may create 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.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2309404    
Bug Blocks:    

Description OSIDB Bzimport 2024-09-03 02:42:19 UTC
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.