W narz\u0119dziu do uruchamiania izolowanych kontener\u00f3w runc, stosowanym w Dockerze i Kubernetes, znaleziono luk\u0119 CVE-2024-21626, kt\u00f3ra umo\u017cliwia dost\u0119p do systemu plik\u00f3w hosta z izolowanego kontenera. W trakcie ataku napastnik mo\u017ce nadpisa\u0107 niekt\u00f3re pliki wykonywalne w \u015brodowisku hosta i tym samym uzyska\u0107 mo\u017cliwo\u015b\u0107 wykonania swojego kodu poza kontenerem. W runtime crun i youki, kt\u00f3re u\u017cywaj\u0105 runc, oraz w LXC problem ten si\u0119 nie pojawia. Luka zosta\u0142a naprawiona w wersji runc 1.1.12. <\/p>\n
W przypadku korzystania z narz\u0119dzi Docker lub Kubernetes atak mo\u017ce zosta\u0107 przeprowadzony przez przygotowanie specjalnie skonfigurowanego obrazu kontenera, po zainstalowaniu i uruchomieniu kt\u00f3rego z kontenera mo\u017cna uzyska\u0107 dost\u0119p do zewn\u0119trznego systemu plik\u00f3w. W przypadku u\u017cycia Dockera istnieje mo\u017cliwo\u015b\u0107 wykorzystania podatno\u015bci przez specjalnie skonfigurowany Dockerfile. Podatno\u015b\u0107 mo\u017ce by\u0107 r\u00f3wnie\u017c wykorzystana w przypadku uruchomienia w kontenerze proces\u00f3w komend\u0105 «runc exec» poprzez powi\u0105zanie katalogu roboczego z przestrzeni\u0105 nazw \u015brodowiska gospodarza. <\/p>\n
Luka spowodowana jest wyciekaniem wewn\u0119trznych deskryptor\u00f3w plik\u00f3w. Przed uruchomieniem kodu w kontenerze w runc nast\u0119puje zamkni\u0119cie wszystkich deskryptor\u00f3w plik\u00f3w za pomoc\u0105 flagi O_CLOEXEC. Niemniej jednak, po p\u00f3\u017aniejszym wywo\u0142aniu funkcji setcwd() pozostaje otwarty deskryptor pliku wskazuj\u0105cy na katalog roboczy, kt\u00f3ry wci\u0105\u017c jest dost\u0119pny po uruchomieniu kontenera. Zaproponowano kilka podstawowych scenariuszy ataku na \u015brodowisko hosta, wykorzystuj\u0105c pozostaj\u0105cy deskryptor pliku. <\/p>\n
Na przyk\u0142ad atakuj\u0105cy mo\u017ce wskaza\u0107 w obrazie kontenera parametr process.cwd, kt\u00f3ry odnosi si\u0119 do «\\\/proc\\\/self\\\/fd\\\/7\\\/», co doprowadzi do powi\u0105zania z procesem pid1 w kontenerze katalogu roboczego znajduj\u0105cego si\u0119 w przestrzeni montowania \u015brodowiska gospodarza. W ten spos\u00f3b w obrazie kontenera mo\u017cna skonfigurowa\u0107 uruchomienie «\\\/proc\\\/self\\\/fd\\\/7\\\/..\\\/..\\\/..\\\/bin\\\/bash», a przez wykonanie skryptu pow\u0142oki nadpisa\u0107 zawarto\u015b\u0107 «\\\/proc\\\/self\\\/exe», kt\u00f3ra odnosi si\u0119 do gospodarskiej kopii \\\/bin\\\/bash. <\/p>\n
Inna opcja ataku pozwala na uzyskanie przez w\u0142amywacza, ograniczonego wewn\u0105trz kontenera, dost\u0119pu do katalogu \u015brodowiska gospodarza, je\u015bli w podanym kontenerze uruchamiane s\u0105 procesy z przywilejami za pomoc\u0105 komendy «runc exec» z opcj\u0105 «—cwd». Atakuj\u0105cy mo\u017ce podmieni\u0107 \u015bcie\u017ck\u0119 uruchamianego procesu na symboliczn\u0105 link\u0119 wskazuj\u0105c\u0105 na «\\\/proc\\\/self\\\/fd\\\/7\\\/» i uzyska\u0107 otwarcie «\\\/proc\\\/$exec_pid\\\/cwd» dla dost\u0119pu do systemu plik\u00f3w po stronie hosta. Atakuj\u0105cy mo\u017ce r\u00f3wnie\u017c uzyska\u0107 mo\u017cliwo\u015b\u0107 nadpisywania plik\u00f3w wykonywalnych po stronie \u015brodowiska gospodarza, przez zorganizowanie uruchomienia pliku wykonywalnego z \u015brodowiska gospodarza («\\\/proc\\\/self\\\/fd\\\/7\\\/..\\\/..\\\/..\\\/bin\\\/bash») z p\u00f3\u017aniejszym nadpisywaniem pliku «\\\/proc\\\/$pid\\\/exe», kt\u00f3ry odnosi si\u0119 do uruchomionego pliku. <\/p>\n
Ponadto w sk\u0142adnikach narz\u0119dzia Docker zidentyfikowano pi\u0119\u0107 dodatkowych podatno\u015bci: <\/p>\n