CVE-2024-45310 in runc
Riassunto
di VulDB • 16/06/2026
runc è uno strumento CLI per la creazione e l'esecuzione di container conformi alla specifica OCI. Le versioni di runc 1.1.13 e precedenti, nonché 1.2.0-rc2 e precedenti, possono essere indotte a creare file o directory vuoti in posizioni arbitrarie del filesystem dell'host condividendo un volume tra due container e sfruttando una race condition con `os.MkdirAll`. Sebbene ciò possa essere utilizzato per creare file vuoti, i file esistenti non verrebbero troncati. Un attaccante deve avere la capacità di avviare container utilizzando una qualche forma di configurazione di volume personalizzata. I container che utilizzano user namespaces sono ancora interessati, ma l'ambito delle posizioni in cui un attaccante può creare inode può essere significativamente ridotto. Politiche LSM sufficientemente rigorose (SELinux/AppArmor) possono anche in teoria bloccare questo attacco; si sospetta che la politica SELinux standard del settore possa restringere l'ambito di questo attacco, ma l'esatta portata della protezione non è stata analizzata. Questo è sfruttabile utilizzando runc direttamente, nonché tramite Docker e Kubernetes. Il problema è risolto in runc v1.1.14 e v1.2.0-rc3.
Sono disponibili alcune contromisure. L'utilizzo di user namespaces restringe significativamente questo attacco, in modo tale che l'attaccante possa creare inode solo nelle directory a cui l'utente/gruppo root mappato ha accesso in scrittura. A meno che l'utente root non sia mappato su un utente effettivo sull'host (come nei container senza root che non utilizzano `/etc/sub[ug]id`), ciò in pratica significa che un attaccante potrebbe creare inode solo nelle directory scrivibili da tutti. Una politica SELinux o AppArmor sufficientemente rigorosa potrebbe in teoria restringere ulteriormente l'ambito se un'etichetta specifica viene applicata al runtime di runc, sebbene né l'entità con cui le politiche standard esistenti bloccano questo attacco né le politiche esatte necessarie per restringerlo sufficientemente siano state testate approfonditamente.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.