De udgav for nylig nyheden om, at en sårbarhed blev identificeret (allerede opført under CVE-2022-31214) i Firejail-appens sandkasseværktøj, er det detaljeret, at den opdagede fejl kunne tillade en lokal bruger at blive root på værtssystemet.
Firejail bruger navnerumsmekanismen, AppArmor og systemopkaldsfiltrering (seccomp-bpf) i Linux til isolering, men kræver forhøjede privilegier for at konfigurere en isoleret udgivelse, som den opnår ved at binde til suid root flag-værktøjet eller køre med sudo.
Sårbarheden skyldes en fejl i logikken i "–join="-indstillingen », designet til at oprette forbindelse til et isoleret miljø, der allerede kører (svarende til login-kommandoen for et sandkassemiljø) med miljøet defineret af ID'et for den proces, der kører i det. I præ-lanceringsfasen registrerer firejail privilegierne for den specificerede proces og anvender dem på den nye proces, der forbinder miljøet med "–join" muligheden.
Før tilslutning, kontrollerer, om den angivne proces kører i firejail-miljøet. Denne kontrol evaluerer eksistensen af filen /run/firejail/mnt/join. For at udnytte sårbarheden, en angriber kan simulere et fiktivt ikke-isoleret firejail-miljø ved at bruge mount-navnerummet og derefter oprette forbindelse til det ved at bruge "--join"-indstillingen.
Hvis konfigurationen ikke aktiverer tilstanden til at forbyde opnåelse af yderligere privilegier i nye processer (prctl NO_NEW_PRIVS), vil firejail forbinde brugeren til et fiktivt miljø og forsøge at anvende brugernavneområdets konfiguration af brugeridentifikatorer (navneområdebruger) i init-processen ( PID 1).
Det meste af logikken bag join-funktionen er i kildekoden fra filen `src/firejail/join.c`. Kritiske dele af koden udføres med forhøjede rettigheder (effektiv UID 0). ID'et for processen blev sendt som en kommando linjeargumentet inspiceres for at afgøre, om det er en rbeholder og bestemme nogle af dens egenskaber, der Det gælder også for den nye tiltrædelsesproces.
De vigtigste kriterier for at beslutte, om man vil deltage i målprocessen lykkes er tilstedeværelsen af en fil i mount-navneområdet for målet, proces fundet i /run/firejail/mnt/join. Denne verifikation udføres på fFunktionen `er_klar_til_join()`. Filen åbnes med l`O_RDONLY|O_CLOEXEC`-flag og sporingsresultatet `fstat()' skal opfylde følgende krav:
– filen skal være en normal fil.
– filen skal ejes af brugerid 0 (som set fra den oprindelige bruger
navneområde).
– filen skal være 1 byte stor.
Som et resultat processen forbundet via "firejail --join" vil ende i navnerummet brugerens originale bruger-id med uændrede privilegier, men i et andet monteringspunktrum, fuldstændig styret af angriberen.
Den resulterende "joined" shell vil nu leve på den oprindelige bruger
navneområde, men stadig bevarer de oprindelige normale brugerrettigheder Mount navneområdet vil være det, der kontrolleres af angriberen. Som
nonewprivs-konfigurationen er ikke blevet anvendt, det kan angriberen nu
kør setuid-root-programmer inden for dette mount-navneområde
Især kan en angriber køre setuid-root-programmer i rummet af det monteringspunkt, den oprettede, hvilket giver den mulighed for for eksempel at ændre /etc/sudoers-konfiguration eller PAM-parametre i sit filhierarki og få mulighed for at køre kommandoer som root ved at bruge sudo eller dets hjælpeprogrammer.
Til sidst er det værd at nævne, at en funktionel udnyttelse er blevet udviklet, testet på nuværende versioner af openSUSE, Debian, Arch, Gentoo og Fedora med firejail-værktøjet installeret.
Problemet blev rettet i firejail version 0.9.70. Som en sikkerhedsrettelse kan du indstille konfigurationen (/etc/firejail/firejail.config) til "no join" og "force-nonewprivs yes".
Endelig hvis du er interesseret i at vide mere om det, kan du kontrollere detaljerne i følgende link.