Det ble nylig annonsert at en sårbarhet (allerede katalogisert under CVE-2022-31214) ble identifisert i Firejail-applikasjonssandboksverktøyet , og det ble beskrevet at den oppdagede feilen kunne tillate en lokal bruker å bli root på vertssystemet.
Firejail bruker navneromsmekanismen, AppArmor og systemanropsfiltrering (seccomp-bpf) i Linux for isolasjon, men krever forhøyede rettigheter for å konfigurere en isolert utgivelse, som den oppnår ved å binde til suid-rotflaggverktøyet eller kjøre med sudo.
Sårbarheten stammer fra en feil i logikken til `--join=<PID>`-alternativet, som er utformet for å koble til et allerede kjørende isolert miljø (ligner på login-kommandoen for en sandkasse) ved å definere miljøet med ID-en til prosessen som kjører i det. I førlanseringsfasen oppdager Firejail rettighetene til den angitte prosessen og bruker dem på den nye prosessen som blir med i miljøet med `--join`-alternativet.
Før tilkobling kontrolleres det om den angitte prosessen kjører i Firejail-miljøet. Denne sjekken evaluerer eksistensen av /run/firejail/mnt/join-filen. For å utnytte sårbarheten kan en angriper simulere et ikke-isolert, fiktivt Firejail-miljø ved hjelp av mount-navnerommet og deretter koble til det ved hjelp av alternativet "--join".
Hvis konfigurasjonen ikke aktiverer modusen for å forby innhenting av tilleggsprivilegier i nye prosesser (prctl NO_NEW_PRIVS), vil firejail koble brukeren til et fiktivt miljø og prøve å bruke brukernavnekonfigurasjonen til brukeridentifikatorer (navneområdebruker) for initprosessen ( PID 1).
Mesteparten av logikken bak join-funksjonen finnes i kildekoden til filen `src/firejail/join.c`. Kritiske deler av koden kjøres med forhøyede rettigheter (effektiv UID 0). Prosess-ID-en som sendes som kommandolinjeargument inspiseres for å avgjøre om det er et fartøy og for å bestemme noen av dets egenskaper, som også brukes på den nye join-prosessen.
Det primære kriteriet for å avgjøre om det er vellykket å bli med i målprosessen, er tilstedeværelsen av en fil i målprosessens monteringsnavneområde, som ligger på /run/firejail/mnt/join. Denne sjekken utføres ved hjelp av funksjonen `is_ready_for_join()`. Filen åpnes ved hjelp av flaggene `O_RDONLY|O_CLOEXEC`, og sporingsutdataene `fstat()` må oppfylle følgende krav:
– filen må være en normal fil.
– filen må eies av bruker-id 0 (sett fra den opprinnelige brukeren
navneområde).
– filen må være 1 byte stor.
Som et resultat vil prosessen som er koblet til via "firejail --join" ende opp i brukerens opprinnelige bruker-ID- navnerom med uendrede rettigheter, men i et annet monteringspunktområde, fullstendig kontrollert av angriperen.
Det resulterende "joined"-skallet vil nå leve på den første brukeren
navneområde, men fortsatt beholder de opprinnelige normale brukerrettighetene mount navneområdet vil være det som kontrolleres av angriperen. Som
nonewprivs-konfigurasjonen har ikke blitt brukt, kan angriperen nå
kjør setuid-root-programmer innenfor dette mount-navnerommet
Spesielt kan en angriper kjøre setuid-root-programmer i området til monteringspunktet den opprettet, slik at den for eksempel kan endre /etc/sudoers-konfigurasjon eller PAM-parametere i filhierarkiet og få muligheten til å kjøre kommandoer som root ved å bruke sudo eller dets verktøy.
Til slutt er det verdt å nevne at en funksjonell utnyttelse har blitt utviklet, testet på gjeldende versjoner av openSUSE, Debian, Arch, Gentoo og Fedora med firejail-verktøyet installert.
Problemet ble løst i firejail versjon 0.9.70. Som en sikkerhetsfiks kan du sette konfigurasjonen (/etc/firejail/firejail.config) til "no join" og "force-nonewprivs yes".
Til slutt, hvis du er interessert i å lære mer om dette , kan du finne detaljene på følgende lenke.