Nemrég kiadták a hírt, hogy biztonsági rést azonosítottak (már szerepel a CVE-2022-31214 alatt) a Firejail alkalmazás sandbox eszközében, részletezi, hogy az észlelt hiba lehetővé teheti a helyi felhasználó számára, hogy root rendszert váltson a gazdagépen.
A Firejail a névterek mechanizmusát, az AppArmor-t és a rendszerhívás-szűrést (seccomp-bpf) használja Linuxban az elkülönítéshez, de magasabb jogosultságokat igényel az izolált kiadás konfigurálásához, amelyet a suid gyökérjelző segédprogramhoz való kötődéssel vagy a sudo-val futtatva szerez meg.
A biztonsági rést a „–join=” opció logikájának hibája okozza », Úgy tervezték, hogy egy már futó elszigetelt környezethez kapcsolódjon (hasonlóan a sandbox-környezet login parancsához) a benne futó folyamat azonosítója által meghatározott környezettel. Az indítás előtti fázisban a firejail észleli a megadott folyamat jogosultságait, és alkalmazza azokat az új folyamatra, amely a „–join” opcióval csatlakozik a környezethez.
Csatlakozás előtt, ellenőrzi, hogy a megadott folyamat fut-e a firejail környezetben. Ez az ellenőrzés kiértékeli a /run/firejail/mnt/join fájl létezését. A sebezhetőség kihasználása érdekében a támadó szimulálhat egy fiktív, nem elszigetelt firejail környezetet a mount névteret használva, majd a "--join" kapcsolóval csatlakozzon hozzá.
Ha a konfiguráció nem engedélyezi a további jogosultságok megszerzésének tiltását az új folyamatokban (prctl NO_NEW_PRIVS), a firejail egy fiktív környezethez kapcsolja a felhasználót, és megpróbálja alkalmazni az init folyamat felhasználói azonosítóinak felhasználói névtér-konfigurációját (névtér felhasználó). PID 1).
A csatlakozási függvény mögötti logika nagy része a forráskódban található az `src/firejail/join.c` fájlból. A kód kritikus részei végrehajtásra kerülnek emelt jogosultságok (érvényes UID 0). A parancsként átadott folyamat azonosítója a sor argumentumot megvizsgáljuk annak megállapítására, hogy r-etárolóedényt, és határozzon meg néhány olyan tulajdonságát, amelyek Ez vonatkozik az új belépési folyamatra is.
A fő kritériumok annak eldöntéséhez, hogy csatlakoznak-e a célfolyamathoz sikeres egy fájl jelenléte a cél mount névterében, A folyamat a /run/firejail/mnt/join fájlban található. Ezt az ellenőrzést a f`is_ready_for_join()` függvény. A fájl megnyitása a lAz `O_RDONLY|O_CLOEXEC' jelzőknek és az `fstat()' nyomkövetési eredménynek megfelel a következő követelményeknek:
– a fájlnak normál fájlnak kell lennie.
– a fájlnak a 0 felhasználói azonosítóhoz kell tartoznia (ahogyan az a kezdeti felhasználótól látható
névtér).
– a fájlnak 1 bájt méretűnek kell lennie.
Ennek eredményeként a "firejail --join"-on keresztül kapcsolt folyamat a névtérbe kerül a felhasználó eredeti felhasználói azonosítója változatlan kiváltságokkal, de egy másik rögzítési pontban, teljesen a támadó irányítása alatt.
Az eredményül kapott "csatlakozott" shell mostantól a kezdeti felhasználónál fog élni
névtér, továbbra is megtartva az eredeti normál felhasználói jogosultságokat a mount névteret a támadó irányítja. Mint
a nonewprivs konfiguráció nem került alkalmazásra, a támadó most már megteheti
futtassa a setuid-root programokat ezen a csatolási névtéren belül
A támadó különösen a setuid-root programokat hajthatja végre az általa létrehozott csatolási pont területén, lehetővé téve például, hogy módosítsa az /etc/sudoers konfigurációt vagy a PAM paramétereket a fájlhierarchiájában, és parancsokat futtasson rootként. sudo vagy segédprogramjai segítségével.
Végül érdemes megemlíteni, hogy kifejlesztettek egy funkcionális exploitot, amelyet az openSUSE, Debian, Arch, Gentoo és Fedora jelenlegi verzióin teszteltek, telepítve a firejail segédprogrammal.
A hibát a firejail 0.9.70-es verziójában javították. Biztonsági javításként beállíthatja a konfigurációt (/etc/firejail/firejail.config) "no join" és "force-nonewprivs yes" értékre.
Végül ha érdekel, hogy többet tudjon meg róla, ellenőrizheti a részleteket a következő link.