I værktøjet til isoleret kørsel af applikationer, Firejail, er der opdaget en sårbarhed (CVE-2022-31214), som gør det muligt for en lokal bruger at opnå root-rettigheder på det primære system. Der er en fungerende exploit tilgængelig offentligt, som er testet i de nyeste versioner af openSUSE, Debian, Arch, Gentoo og Fedora, der har Firejail installeret. Problemet er blevet løst i udgivelsen af Firejail 0.9.70. Som en midlertidig beskyttelsesmetode kan man indstille parametre i konfigurationen (\/etc\/firejail\/firejail.config) til "join no" og "force-nonewprivs yes".
Firejail bruger namespaces, AppArmor og systemopkaldsfiltrering (seccomp-bpf) i Linux til isolering, men kræver forhøjede privilegier for at konfigurere isoleret kørsel, som man opnår via tilknytning til værktøjet med suid root-flaget eller ved hjælp af sudo. Sårbarheden er forårsaget af en fejl i logikken i indstillingen "—join=", der er designet til at tilslutte sig et allerede kørende isoleret miljø (analogt med login-kommandoen for sandbox-miljøet) ved at bestemme miljøet ud fra det kørende proces-ID. Før privilegierne tilbagekaldes, vurderer Firejail privilegierne for den angivne proces og anvender dem på den nye proces, der tilsluttes miljøet ved hjælp af "—join"-indstillingen.
Før tilslutningen kontrolleres det, om den angivne proces kører i Firejail-miljøet. Denne kontrol vurderer, om filen \/run\/firejail\/mnt\/join eksisterer. For at udnytte sårbarheden kan en angriber simulere et falskt, ikke-isoleret Firejail-miljø ved at bruge mount namespace, hvorefter de kan tilslutte sig dette ved hjælp af "—join"-indstillingen. Hvis der ikke er aktiveret en indstilling til at forhindre modtagelse af ekstra privilegier i nye processer (prctl NO_NEW_PRIVS), vil Firejail tilslutte brugeren til det falske miljø og forsøge at anvende indstillingerne for user namespace fra init-processen (PID 1).
Som resultat vil den proces, der tilsluttes via «firejail —join», befinder sig i brugerens oprindelige namespace med uændrede rettigheder, men i et andet monteringspunkt, som er helt kontrolleret af angriberen. Angriberen kan også udføre setuid-root programmer i det monterede rum, hvilket eksempelvis gør det muligt at ændre indstillingerne i /etc/sudoers eller PAM-parametre i sin egen filhierarki og dermed få mulighed for at udføre kommandoer med root-rettigheder ved hjælp af sudo eller su.
Kilde: opennet.ru
