{"id":104360,"date":"2022-06-12T09:36:50","date_gmt":"2022-06-12T07:36:50","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-firejail-pozvolyayushhaya-poluchit-root-dostup-v-sisteme"},"modified":"2022-06-12T09:36:50","modified_gmt":"2022-06-12T07:36:50","slug":"uyazvimost-v-firejail-pozvolyayushhaya-poluchit-root-dostup-v-sisteme","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/news\/uyazvimost-v-firejail-pozvolyayushhaya-poluchit-root-dostup-v-sisteme","title":{"rendered":"Vulnerability in firejail that allows obtaining root access in the system.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
W narz\u0119dziu do izolowanego uruchamiania aplikacji Firejail zidentyfikowano luk\u0119 (CVE-2022-31214), kt\u00f3ra pozwala lokalnemu u\u017cytkownikowi uzyska\u0107 uprawnienia roota w g\u0142\u00f3wnym systemie. W Internecie dost\u0119pny jest dzia\u0142aj\u0105cy exploit, przetestowany w najnowszych wersjach openSUSE, Debian, Arch, Gentoo i Fedora z zainstalowanym narz\u0119dziem firejail. Problem zosta\u0142 rozwi\u0105zany w wydaniu firejail 0.9.70. Mo\u017cliwo\u015bci\u0105 obej\u015bcia zabezpiecze\u0144 jest ustawienie w konfiguracji (\\\/etc\\\/firejail\\\/firejail.config) opcji \u201ejoin no\u201d oraz \u201eforce-nonewprivs yes\u201d. <\/p>\n
Firejail wykorzystuje mechanizm przestrzeni nazw (namespaces), AppArmor oraz filtrowanie wywo\u0142a\u0144 systemowych (seccomp-bpf) w systemie Linux do izolacji, ale do konfiguracji izolowanego uruchamiania wymaga podwy\u017cszonych uprawnie\u0144, kt\u00f3re uzyskuje poprzez powi\u0105zanie z flag\u0105 suid root lub uruchomienie za pomoc\u0105 sudo. Luka jest wynikiem b\u0142\u0119du w logice dzia\u0142ania opcji \u201e--join=\u201d, s\u0142u\u017c\u0105cej do do\u0142\u0105czania do ju\u017c dzia\u0142aj\u0105cego izolowanego \u015brodowiska (odpowiednik polecenia login dla \u015brodowiska sandbox) z okre\u015bleniem \u015brodowiska na podstawie dzia\u0142aj\u0105cego w nim identyfikatora procesu. Na etapie przed zresetowaniem uprawnie\u0144 firejail okre\u015bla uprawnienia wskazanego procesu i stosuje je do nowego procesu, do\u0142\u0105czanego do \u015brodowiska za pomoc\u0105 opcji \u201e--join\u201d. <\/p>\n
Przed do\u0142\u0105czeniem sprawdzane jest, czy wskazany proces dzia\u0142a w \u015brodowisku firejail. Ta kontrola ocenia obecno\u015b\u0107 pliku \\\/run\\\/firejail\\\/mnt\\\/join. Aby wykorzysta\u0107 luk\u0119, atakuj\u0105cy mo\u017ce zasymulowa\u0107 fikcyjne, nieizolowane \u015brodowisko firejail, korzystaj\u0105c z przestrzeni nazw montowania (mount namespace), a nast\u0119pnie po\u0142\u0105czy\u0107 si\u0119 z nim za pomoc\u0105 opcji \u201e--join\u201d. Je\u015bli w ustawieniach nie jest aktywowany tryb zakazu uzyskiwania dodatkowych uprawnie\u0144 w nowych procesach (prctl NO_NEW_PRIVS), firejail po\u0142\u0105czy u\u017cytkownika z fikcyjnym \u015brodowiskiem i spr\u00f3buje zastosowa\u0107 ustawienia przestrzeni nazw identyfikator\u00f3w u\u017cytkownik\u00f3w (user namespace) procesu init (PID 1). <\/p>\n
W rezultacie proces po\u0142\u0105czony przez «firejail —join» znajdzie si\u0119 w pierwotnej przestrzeni nazw identyfikator\u00f3w u\u017cytkownik\u00f3w z niezmienionymi uprawnieniami, ale w innej przestrzeni punkt\u00f3w montowania, w pe\u0142ni kontrolowanej przez atakuj\u0105cego. W tym przypadku atakuj\u0105cy mo\u017ce uruchamia\u0107 programy setuid-root w utworzonej przez siebie przestrzeni punkt\u00f3w montowania, co pozwala na przyk\u0142ad na zmian\u0119 ustawie\u0144 \\\/etc\\\/sudoers lub parametr\u00f3w PAM w swojej hierarchii plik\u00f3w i uzyskanie mo\u017cliwo\u015bci wykonywania polece\u0144 z uprawnieniami roota za pomoc\u0105 narz\u0119dzi sudo lub su. \n \u0179r\u00f3d\u0142o: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"