Ei au anunțat recent vestea că a fost identificată o vulnerabilitate (listat deja sub CVE-2022-31214) în instrumentul de sandboxing al aplicației Firejail, este detaliat că defectul detectat ar putea permite unui utilizator local să devină root pe sistemul gazdă.
Firejail folosește mecanismul de spațiu de nume, AppArmor și filtrarea apelurilor de sistem (seccomp-bpf) pe Linux pentru izolare, dar necesită privilegii ridicate pentru a configura o lansare izolată, pe care o obțineți prin conectarea la utilitarul suid sau root flag.
Vulnerabilitatea se datorează unei erori în logica opțiunii „–join=". », conceput pentru a se conecta la un mediu izolat care rulează deja (similar cu comanda de conectare pentru un mediu sandbox) cu mediul definit de ID-ul procesului care rulează în el. În faza de pre-lansare, firejail detectează privilegiile procesului specificat și le aplică noului proces care se alătură mediului cu opțiunea „–join”.
Înainte de conectare, verifică dacă procesul specificat rulează în mediul firejail. Această verificare evaluează existența fișierului /run/firejail/mnt/join. Pentru a exploata vulnerabilitatea, un atacator poate simula un mediu firejail fictiv neizolat folosind spațiul de nume de montare și apoi conectarea la acesta folosind opțiunea „–join”.
Dacă configurația nu permite modul de a interzice obținerea de privilegii suplimentare în procesele noi (prctl NO_NEW_PRIVS), firejail va conecta utilizatorul la un mediu inactiv și va încerca să aplice setările spațiului de nume de utilizator ale ID-urilor utilizatorului (nume de utilizator al spațiului de nume) ale procesului init. (PID 1).
Cea mai mare parte a logicii din spatele funcției de unire se află în codul sursă din fișierul `src/firejail/join.c`. Secțiunile critice ale codului sunt executate cu privilegii ridicate (UID efectiv 0). ID-ul procesului a fost transmis ca o comandă argumentul de linie este inspectat pentru a determina dacă este un recipient şi determina unele dintre proprietăţile sale care Se aplică și procesului de intrare nouă.
Principalul criteriu pentru a decide dacă să se alăture procesului țintă succes este prezența unui fișier în spațiul de nume de montare al țintei, proces găsit în /run/firejail/mnt/join. Această verificare se efectuează în fungerea `is_ready_for_join()`. Fișierul este deschis folosind lca steaguri `O_RDONLY|O_CLOEXEC` și rezultatul urmăririi `fstat()` îndeplinesc următoarele cerințe:
– fișierul trebuie să fie un fișier normal.
– fișierul trebuie să fie deținut de ID-ul utilizatorului 0 (după cum se vede de la utilizatorul inițial
spațiu de nume).
– fișierul trebuie să aibă o dimensiune de 1 octet.
Ca urmare, procesul conectat prin „firejail –join” se va termina în spațiul de nume ID-ul de utilizator original al utilizatorului cu privilegii neschimbate, dar într-un spațiu diferit al punctului de montare, complet controlat de atacator.
Shell-ul „unit” rezultat va trăi acum pe utilizatorul inițial
namespace, păstrând totuși privilegiile originale de utilizator normal spațiul de nume de montare va fi cel controlat de atacator. Dat fiind
configurația nonnewprivs nu a fost aplicată, atacatorul poate acum
rulați programe setuid-root în acest spațiu de nume de montare
În special, un atacator poate rula programe setuid-root în spațiul punctului de montare pe care l-a creat, permițând, de exemplu, să modifice setările /etc/sudoers sau parametrii PAM din ierarhia de fișiere și să câștige capacitatea de a executa comenzi ca root folosind sudo sau utilitățile sale. .
În cele din urmă, este de menționat că a fost dezvoltat un exploit funcțional, testat pe versiunile curente de openSUSE, Debian, Arch, Gentoo și Fedora cu utilitarul firejail instalat.
Problema a fost rezolvată în versiunea Firejail 0.9.70. Ca soluție de securitate, puteți seta configurația (/etc/firejail/firejail.config) la „do not join” și „force-nonewprivs yes”.
În cele din urmă dacă sunteți interesat să aflați mai multe despre asta, puteți verifica detaliile în următorul link.