De släppte nyligen nyheten att en sårbarhet identifierades (redan listad under CVE-2022-31214) i Firejail-appens sandlådeverktyg, är det detaljerat att det upptäckta felet kan tillåta en lokal användare att bli root på värdsystemet.
Firejail använder namnutrymmesmekanismen, AppArmor och systemanropsfiltrering (seccomp-bpf) i Linux för isolering, men kräver förhöjda privilegier för att konfigurera en isolerad utgåva, som den erhåller genom att binda till suid root-flaggaverktyget eller köra med sudo.
Sårbarheten beror på ett fel i logiken för alternativet “–join=”. », designad för att ansluta till en isolerad miljö som redan körs (liknande inloggningskommandot för en sandlådemiljö) med miljön definierad av ID:t för processen som körs i den. I förlanseringsfasen upptäcker firejail privilegierna för den angivna processen och tillämpar dem på den nya processen som ansluter till miljön med alternativet "–join".
Innan du ansluter, kontrollerar om den angivna processen körs i firejail-miljön. Denna kontroll utvärderar existensen av filen /run/firejail/mnt/join. För att utnyttja sårbarheten, en angripare kan simulera en fiktiv icke-isolerad firejail-miljö använda namnutrymmet för monteringen och sedan ansluta till det med alternativet "–join".
Om konfigurationen inte aktiverar läget för att förbjuda erhållande av ytterligare privilegier i nya processer (prctl NO_NEW_PRIVS), kommer firejail att ansluta användaren till en fiktiv miljö och försöka tillämpa användarnamnutrymmets konfiguration av användaridentifierare (namnområdesanvändare) för initprocessen ( PID 1).
Det mesta av logiken bakom joinfunktionen finns i källkoden från filen `src/firejail/join.c`. Kritiska delar av koden exekveras med förhöjda privilegier (effektiv UID 0). Processens ID skickades som ett kommando linjeargumentet inspekteras för att avgöra om det är ett rbehållare och bestämma några av dess egenskaper som Det gäller även för den nya inträdesprocessen.
De viktigaste kriterierna för att besluta om att gå med i målprocessen lyckas är närvaron av en fil i mount namnutrymmet för målet, process hittas i /run/firejail/mnt/join. Denna verifiering görs på f`is_ready_for_join()`-funktionen. Filen öppnas med l`O_RDONLY|O_CLOEXEC`-flaggorna och spårningsresultatet `fstat()` bör uppfylla följande krav:
– filen måste vara en normal fil.
– filen måste ägas av användar-id 0 (som sett från den ursprungliga användaren
namnutrymme).
– filen måste vara 1 byte stor.
Som ett resultat processen kopplad via "firejail --join" kommer att hamna i namnutrymmet användarens ursprungliga användar-ID med oförändrade privilegier, men i ett annat monteringspunktsutrymme, helt kontrollerat av angriparen.
Det resulterande "joined"-skalet kommer nu att leva på den första användaren
namnutrymme, men fortfarande behåller de ursprungliga normala användarrättigheterna monteringsnamnområdet kommer att vara det som kontrolleras av angriparen. Som
nonewprivs-konfigurationen har inte tillämpats, angriparen kan nu
kör setuid-root-program inom detta mount namnutrymme
I synnerhet kan en angripare köra setuid-root-program i utrymmet för monteringspunkten den skapade, vilket gör att den till exempel kan ändra /etc/sudoers-konfiguration eller PAM-parametrar i sin filhierarki och få möjlighet att köra kommandon som root använder sudo eller dess verktyg.
Slutligen är det värt att nämna att en funktionell exploatering har utvecklats, testad på nuvarande versioner av openSUSE, Debian, Arch, Gentoo och Fedora med Firejail-verktyget installerat.
Problemet åtgärdades i firejail version 0.9.70. Som en säkerhetskorrigering kan du ställa in konfigurationen (/etc/firejail/firejail.config) till "no join" och "force-nonewprivs yes".
Slutligen om du är intresserad av att veta mer om detkan du kontrollera detaljerna i följande länk.